Patent Description:
Wireless communication networks are typically managed by a network operator, referred to as a mobile network operator, or MNO. A wireless communication device can be registered as a subscriber to a communication network. The communication network the device subscribes to may be referred to as the device's home network.

It is often desirable for a device to be able to connect to other communication networks other than its home communication network, for example to access resources available on those networks. For clarity, these other networks may be referred to as guest networks.

Roaming is a well-known approach to enable a device to access a network other than its home network. Roaming is facilitated through the provision of roaming agreements. Roaming agreements are agreements between MNOs of different communication networks that enable subscribers of one communication network managed by a first MNO to communicate over, or access, another communication network managed by a second MNO.

<FIG> is a diagram showing an example roaming architecture for two communication networks <NUM> and <NUM>. In this example, each communication network is a long-term evolution (LTE) network. Network <NUM> is managed by a first mobile network operator MNO1, and network <NUM> is managed by a second mobile network operator MNO2. Devices <NUM> and <NUM> (also referred to user equipment (UE)) located within network <NUM> are subscribers to network <NUM>. In other words, network <NUM> is the home network for devices <NUM> and <NUM>. Devices <NUM> and <NUM> therefore include a subscriber identity module (SIM) provisioned by MNO1. The roaming agreement between MNO1 and MNO2 enables devices <NUM> and <NUM> to access guest network <NUM> using its access credentials provisioned by the mobile network operator MNO1 of the network <NUM>.

Though roaming agreements enable a device to access a guest network using a single SIM provisioned by the device's home network operator, roaming suffers from the drawback of requiring interconnects between the communication networks. Example interconnects are shown in <FIG> at <NUM>, <NUM> and <NUM>. Interconnect <NUM> is an S6a interface between a mobility management entity (MME) <NUM> of the guest network and the home subscriber server (HSS) <NUM> of the home network. Interconnect <NUM> is an S8 interface between a serving gateway (SGW) <NUM> of the guest network and a packet data network gateway (PGW) <NUM>. Interconnect <NUM> is an S9 interface between a policy and charging rules function (PCRF) <NUM> of the guest network and the PCRF <NUM> of the home network. If there are no interconnects between two communication networks, roaming cannot be implemented to enable a device to access a guest network.

Another approach to enable a device to access networks other than its home network is international mobile subscriber identity (IMSI) switching. The IMSI is used to identify the device of a communication network. It is a unique identification for the device within all wireless communication networks. IMSI switching refers to switching the IMSI for the device's home network over to a different IMSI for a second network. That is, IMSI switching requires that multiple IMSIs be stored on a single SIM. Once the IMSI has been switched the IMSI for the second network, the device is able to access that second network. IMSI switching may be controlled by a SIM application. IMSI switching can be triggered when no network coverage for the device's home network is detected. IMSI switching has the associated risk that the SIM application switches the IMSI when this is not desired (e.g., in rural spots, underground, in lifts etc.).

Another approach to enable a device to access guest networks is the use of roaming hubs. A roaming hub enables a device to access a guest network through the hub. That is, the roaming hub has a roaming agreement with the guest network. By connecting to the hub, the device can then access the guest network. Though roaming hubs do not require a roaming agreement between the device's home network and the guest network, they do still require an interconnect between the roaming hub and the guest network.

European patent application <CIT> describes storing and switching between multiple Electronic Subscriber Identity Modules (eSIM), where each eSIM is specific to a different carrier network. By loading the appropriate eSIM, the user device can authenticate itself with the selected carrier, rather than roaming. During roaming operation, the user equipment can load one or more of the previously stored eSIMs.

US patent application <CIT> describes authentication key generation for local area network communication, including: participating in communication of a message comprising a cipher suite selection type indicating cellular network compatible cipher suite; and creating cellular network compatible authentication keys according to said cipher suite selection type.

International patent application <CIT> describes systems and methods for providing authentication key agreement (AKA) with perfect forward secrecy (PFS) between a user equipment and a network.

US patent application <CIT> describes a method and an apparatus of obtaining secure registration in a multicast-broadcast-multimedia system (MBMS) using a temporary registration key (RGK).

According to the present invention there is provided a method of authenticating a device subscribed to a first wireless communication network on a second wireless communication network, as defined in claims <NUM> to <NUM> attached. The invention further provides a device adapted to perform said method, as defined in claim <NUM>.

The present disclosure is directed to an approach for enabling a device subscribed to a first wireless communication network to access a second wireless communication network that does not have any physical connections and/or roaming agreements with the first network. To do this, a set of one or more network keys for the second network are derived from a set of one or more network keys of the first network. Each of the network keys for the first network may uniquely identify the device within that network. The derived set of network keys for the second network are then communicated to the device. A first copy of the derived network keys is stored on the device's identification module (e.g. SIM), and a second copy of the derived network keys is stored in a secure area of the device (e.g. a secure element). The device then authenticates itself on the second communication network using the network keys stored in the secure area of the device. Following the initial authentication, a copy of the network keys is communicated from the secure area of the device to a node within the second communication network for use in subsequent attachment procedures. The network keys for the second network may be stored against an identifier for the device, such as its IMSI. The copy of the network keys stored in the secure area are then deleted, leaving the copy stored in the identification module as the sole copy stored on the device. This remaining copy of the network keys for the second network are used for subsequent attachment procedures to the second network. As will be explained in more detail below, this approach enables a device with a single SIM to access a guest network without a roaming agreement with the home subscriber network. It also enables the device to access the guest network without the requirement of explicitly sharing the same key information between the two networks, thus avoiding compromising security requirements.

Examples of authenticating a device on a non-home subscriber network will now be described with reference to <FIG>. These examples will describe the authentication and attachment of a device in the context of long term evolution (LTE) networks. It is to be understood that this is for the purposes of illustration only, and that the following techniques, approaches and examples can be applied within different types of wireless communication networks.

<FIG> shows a first wireless communication network <NUM> and a second wireless communication network <NUM>. Network <NUM> is managed by a first mobile network operator MNO1. Network <NUM> is managed by a second mobile network operator MNO2. There are no roaming agreements between networks <NUM> and <NUM>, thus there are no interconnects or interfaces between the two networks. Neither are there any other physical connections between the two networks. For the purpose of illustration, network <NUM> is taken to be a public network, and network <NUM> is taken to be a private network. Generally speaking, a public network is one which is open for general use, and a private network is one that can only be accessed by select devices set by the owner (e.g. the mobile network operator) of the network.

Networks <NUM> and <NUM> are in this example both LTE networks. The network <NUM> comprises a user equipment (UE) <NUM> and <NUM>, an eNodeB <NUM>, and an evolved network core (EPC) <NUM>. The EPC connects to an external packet data network <NUM>, which in the example illustrated here is the internet.

UEs may be any suitable type of device capable of participating in wireless communications. A UE could be, for example, a mobile phone, smartphone, laptop, PC, tablet, etc. In the example shown here, UE <NUM> is a mobile device, and UE <NUM> is a laptop. A UE may be referred to interchangeably herein as a device.

UEs <NUM> and <NUM> are subscribers to network <NUM> (i.e. network <NUM> is the home network for UEs <NUM> and <NUM>). Consequently, UEs <NUM> and <NUM> are shown as including a SIM provisioned by the MNO1.

<FIG> shows an example architectural layout of various components of a UE. For the purpose of illustration, <FIG> shows the components of UE <NUM>, though other UEs may have similar components.

The UE <NUM> comprises a wireless chipset <NUM>, processor <NUM>, memory <NUM>, a universal subscriber identity module (USIM) <NUM>, and USIM interface <NUM> and a secure storage area <NUM>. These components are connected by interconnect circuitry <NUM>, which may for example be a bus.

The wireless chipset <NUM> may manage the transmission and reception of wireless messages from and to the UE <NUM>. Processor <NUM> may operate to perform general processing functions for the UE <NUM>. Memory <NUM> stores data for the UE <NUM>. Though only a single memory block is shown in <FIG>, it will be appreciated that memory block <NUM> may correspond to one or more separate blocks of memory of the same or different types. For example, the UE <NUM> may include one or more blocks of RAM and/or one or more blocks of ROM.

The USIM <NUM> is an example of an identification module. It stores identification information for the device along with a set of one or more network keys for the device's home network <NUM>. The identification information stored on the USIM <NUM> may be the device's IMSI. The set of one or more network keys may identify and authenticate the device <NUM> within the home network <NUM>. The set of one or more network keys stored within the USIM <NUM> may uniquely identify the device <NUM> within the communication network <NUM>. That is, each of the set of one or more network keys may be unique to the device <NUM> within the communication network <NUM>. In this particular example, the set of network keys includes an authentication key K and a unique operator code Opc. The authentication key K is unique to the device. It is assigned by the network operator (in this example, MNO1), and is used for authenticating the device on the network. The authentication key K is also stored within the network <NUM>, typically in the HSS <NUM> or in an authentication centre (AuC) (not shown in <FIG>). The authentication key K may also be referred to as a USIM Individual key (e.g. as in 3GPP TS <NUM>); a permanent key (e.g. as referred to in 3GPP TS <NUM>); or a long-term secret key shared between the USIM and AuC (e.g. as referred to in 3GPP TS <NUM>).

The unique operator code Opc is derived from a network-operator-specific code Op and the unique authentication key K. As such, the code Opc is also unique to the device <NUM>. The code Opc is also used to identify and authenticate the device <NUM> on the home network <NUM>. Thus, in summary, each of the set of network keys stored within the USIM <NUM> uniquely identifies the device <NUM> within its home network <NUM>, and is used to identify and authenticate the device within the home network <NUM>.

Other device identification information stored in the USIM <NUM> may include the mobile station international subscriber directory number (MSISDN); and the international mobile equipment identity (IMEI) number. This device identification information may be stored in the USIM data store <NUM>. The data store <NUM> may have a hierarchical memory structure. For example, the data store <NUM> may be arranged into a hierarchical file system that includes a master file (MF), one or more dedicated files (DF) and one or more elementary files (EF). The one or more DFs sit below the MF; i.e. they are subordinate files to the MF. The EFs sit below the DFs. One or more EFs may sit below each DF. In general, the EFs store the data for a SIM. Thus, the MSISDN and the IMEI may be stored in EFs. It will be appreciated that the USIM <NUM> will include other EFs not detailed here.

The set of one or more network keys may be stored in a secure region of memory in the USIM <NUM> (not shown in <FIG>). The secure region of memory may be encrypted. The secure region of memory may be a protected region of memory. It may be tamperproof from external entities (i.e., entities external of the USIM, such as other components of the device <NUM> including the USIM interface <NUM>). Thus, the secure region of memory may be an externally unreadable region of memory. That is, the network keys might be non-retrievable from the region of memory in which they are stored by applications and components external to the USIM <NUM>. The secure region may be accessible (e.g. readable) by the USIM application <NUM>. The USIM application <NUM> may for example access the network keys in the secure region to create session keys during an attachment procedure.

The USIM <NUM> also includes a USIM application <NUM>, which can run on the SIM to perform the various functions provided by the USIM <NUM>.

The USIM <NUM> may run on, or form part of, a universal integrated circuit card (UICC) smartcard (not shown in <FIG> for clarity). The UICC smartcard may be embedded within the device <NUM> (i.e. fixed within the device). Alternatively, the UICC smartcard may be insertable into device <NUM> but capable of being removed from the device <NUM>. In other words, the UICC may be removable.

The USIM <NUM> is connected to the other components of the UE <NUM> through the USIM interface <NUM>. The USIM interface <NUM> can control how data stored on the USIM <NUM> (except within the secure region of memory) may be retrieved from the USIM <NUM>. In other words, the USIM interface <NUM> controls access to the data stored on the USIM <NUM>.

The secure storage area <NUM> is used for securely storing confidential information. The secure storage area <NUM> may be tamper-resistant. It may be a fully encrypted storage area (i.e. it may store data in an encrypted format). The secure storage area <NUM> may store data to a higher level of security (e.g. to a higher level of encryption, or to a higher level of inaccessibility or tamper-resistance) than the USIM <NUM> (including the secure region of memory in the USIM <NUM>). Thus, data stored in the secure storage area <NUM> may be more trusted to a third party - such as a communication network node - than data stored in the USIM <NUM>.

The secure storage area <NUM> may be a secure element. The storage area <NUM> may form part of the UICC. That is, the storage area may be a defined area of the UICC that is non-accessible to the remaining components of the UICC (including the USIM <NUM>). Alternatively, secure storage area <NUM> may be a separate component to the UICC, for example it may be a hardware component such as a chip. If a separate component to the UICC, the storage area <NUM> may be embedded within the device <NUM>.

It will be appreciated that a UE may include additional components to those shown in <FIG>, and that only a selection of components have been illustrated and described for the purposes of clarity.

Referring back to <FIG>, the eNodeB <NUM> is an example of a base station and operates to connect the UEs to the EPC <NUM>.

The EPC <NUM> comprises a number of components. In the example shown, these are: a mobility management entity (MME) <NUM>; a serving gateway (SGW) <NUM>; a packet data network gateway (PGW) <NUM>; a policy charging and rules function (PCRF) unit <NUM> and a home subscriber server (HSS) <NUM>. Each of these components may be referred to herein as nodes.

Network <NUM> comprises UEs <NUM> and <NUM>, an eNodeB <NUM>, and an evolved network core (EPC) <NUM>. The EPC <NUM> connects to an external packet data network <NUM>, which in the example illustrated here is a private network.

UEs <NUM> and <NUM> are subscribers to network <NUM> (i.e. network <NUM> is the home network for UEs <NUM> and <NUM>). Consequently, UEs <NUM> and <NUM> are shown as including a SIM provisioned by the MNO2.

EPC <NUM> includes an HSS <NUM>, an MME <NUM>, an SGW <NUM>, a PCRF <NUM> and a PGW <NUM>.

A brief overview of the components within the EPC will now be described. It will be appreciated that this overview applies equivalently to the components of EPC <NUM> and <NUM>.

The MME operates to process the signalling between the UEs and the EPC. The MME also operates to select an SGW for a UE during an initial attachment, and to select a PGW.

The SGW is responsible for controlling handovers of the UE to neighbouring eNodeBs. The SGW may also retain information on the bearers when a UE is an idle state. It can buffer downlink data while the MME operates to re-establish a bearer. The SGW also functions as a router between the eNodeB and the PGW.

The PGW operates to provide connectivity between the UE and the external PDN. It is the point of entry to or exit from the LTE network of data packets for the UE.

The HSS contains subscription data for users of the network. It may store information about the PDN's a UE can connect to. The HSS may also store the identity of the MME to which the UE is currently attached, or registered.

The PCRF performs policy control and decision making. It can provide QoS authorisation for UE's participating in communication sessions and manage data flows in accordance with a user's subscription profile.

Network <NUM> further comprises a key management unit (KMU) <NUM>. The key management unit <NUM> operates to generate a UE's network keys for the network <NUM>. This will be explained in more detail below. In the example illustrated in <FIG>, the key management unit <NUM> is included within a subscription management system (SuMS) <NUM>. The SuMS may be a server.

The SuMS <NUM> is communicatively coupled to the HSS <NUM>. The SuMS <NUM> and HSS <NUM> may be connected by a secure communication link. That communication link could be a wired and/or wireless link. The SuMS <NUM> (and hence the key management unit <NUM>) are shown as being external to the EPC <NUM>. In other implementations, the SuMS <NUM> and KMU <NUM> may be included within the EPC <NUM>.

In other implementations, the key management unit <NUM> (and potentially also the SuMS <NUM>) could be included within the HSS <NUM>. In other words, the key management unit <NUM> could form part of the HSS <NUM>. In this case, the key management unit <NUM> may be separated from the storage and repository functionality of the HSS <NUM>. For example, repositories within the HSS <NUM> may be accessed by the key management unit <NUM> through an API.

An approach to enable a device comprising only a single SIM to connect to a communication network other than its home network will now be described with reference to the flowchart shown in <FIG>. For the purposes of this explanation, the device in question will be taken to be UE <NUM>. To recall, UE <NUM> has as its home network the network <NUM>, and in accordance with the approach described herein will connect to network <NUM>, which has neither a roaming agreement nor physical connections with network <NUM>. Network <NUM> may therefore be referred to as a guest network, or visiting network.

At step <NUM>, a user of device <NUM> requests a set of one or more network keys for the network <NUM>. Because in this example the network <NUM> is a private network, the set of network keys for this network may be referred to interchangeably as private network keys.

A user may request the private network keys by providing a node within the device <NUM>'s home network <NUM> with information identifying the device <NUM> and information identifying the network <NUM>. The node within the network <NUM> may be the subscription management system <NUM>. The information identifying the device <NUM> may include one or more of: <NUM>) the device's IMSI; <NUM>) the device's MSISDN; and <NUM>) the device's IMEI. This information may be retrieved from the device's USIM <NUM>. The information identifying the network <NUM> may include the network name for the network <NUM>, for example the public land mobile network (PLMN) name.

The identification information for the device <NUM> and network <NUM> may be provided to the subscription management system <NUM> in a variety of ways. In some examples, the information may be communicated to the subscription management system <NUM> from the device <NUM>. In other examples, a user of the device may provide the information through a secure portal, for example a secure webpage.

At step <NUM>, the user's/device's records are accessed and the private keys are generated for the device.

Step <NUM> may be performed by the key management unit <NUM> of the home network <NUM>. The KMU <NUM> can generate the private network keys from the device's set of one or more network keys for the home communication network <NUM>. In other words, the network keys for the private network <NUM> are generated from the network keys of the home network <NUM>.

Each private network key may be generated from a respective home network key. Each private network key may be generated by implementing a mathematical algorithm which receives as its input a home network key. The level of complexity of the mathematical algorithm used to generate the private keys may be implementation specific. In some examples, each private key may be generated by multiplying a respective home network key by a random number. As another example, a hashing function may be implemented to generate a hash value from a home network key. The generated hash value may be the private network key. In other examples, a series of mathematical functions may be applied to a home network key to generate a private network key. Each private network key may be of the same bitlength (i.e. contain the same number of bits) as the home network key from which it was generated.

As described above, the device's network keys for the home network <NUM> are stored in an externally unreadable portion of memory within the USIM <NUM>. However, a copy of the device's home network keys may also be stored within the HSS <NUM>. In particular, a profile for device <NUM> may be stored within the HSS <NUM> that includes the device's home network keys.

The KMU <NUM> retrieves the device's home network keys from the HSS <NUM> over the secure communication link connecting the KMU <NUM> and HSS <NUM>. In implementations in which the KMU <NUM> forms part of the HSS <NUM>, the device <NUM>'s profile may be stored within a repository in the HSS <NUM> separate from the KMU <NUM>. The KMU <NUM> may then access the repository through an API to retrieve the device <NUM>'s home network keys.

The KMU <NUM> may retrieve the device's home network keys using the identification information for the device <NUM> received at step <NUM>. For example, the KMU <NUM> may identify and access the device's stored profile using the information identifying the device <NUM> received at step <NUM> to retrieve the home network keys. Once the home network keys for the device <NUM> have been retrieved, the KMU <NUM> can derive the private network keys for the device <NUM>. This approach therefore enables the private network keys to be generated without requiring the home network keys to be shared externally of the network <NUM>.

In the present example, the device's home network keys include the authentication key K and the operator code Opc. The private network keys generated for device <NUM> from these home network keys are denoted herein as pK and pOpc. The private key pK is generated from the home network key K, and the private key pOpc is generated from the home network key Opc. The key pK may be referred to as the private network authentication key, and the key kOpc may be referred to as the private operator code key.

At step <NUM>, the generated private keys are communicated to the device <NUM> from a node in the communication network <NUM>. Following the present example, the private network keys may be communicated from the KMU <NUM> to the device <NUM>. At step <NUM>, the device's private network keys are stored in the USIM <NUM> and within the secure storage area <NUM> of the device <NUM>. That is, two copies of the private network keys are stored on the device <NUM>: a first copy within the device's USIM <NUM>, and a second copy within the device's secure storage area <NUM>.

The two copies of the private network keys may be communicated to the device <NUM> separately to each other. In other words, the private network keys may be communicated to the device's USIM <NUM>, and separately to the device's secure storage area <NUM>. The private network keys may be communicated using a suitable communication protocol, such as over-the-air (OTA).

The KMU <NUM> may communicate additional information for the network <NUM> to the device <NUM> at step <NUM>. This information may include information identifying the network <NUM>, and/or information identifying the device <NUM> within the network <NUM>. The information identifying the network <NUM> may include a home public land mobile network (HPLMN) code for the network <NUM> (which may be denoted pHPLMN). This network code may the combination of the mobile country code (MCC) and mobile network code (MNC); i.e. it may be the MCC-MNC code, which uniquely identifies the network operator of network <NUM>, MNO2. The information identifying the device <NUM> within the network <NUM> may be an identification code for the device <NUM>. It may be the IMSI for the device <NUM> within the network <NUM>, which is denoted pIMSI. The pIMSI for device <NUM> may differ than the IMSI for the device <NUM> (i.e. the identity code for the device <NUM> within its home network <NUM> may be different than its identity code within the guest network <NUM>). This is because there is no roaming agreement between networks <NUM> and <NUM>. The information identifying the network <NUM> and the information identifying device <NUM> within network <NUM> may be stored within the USIM <NUM>, for example within the data store <NUM>.

Thus, in summary, following step <NUM> the device <NUM> has stored the following information:.

Following step <NUM>, the USIM <NUM> may be said to have a dual SIM identity: a first SIM identity for the home network <NUM>, and a second SIM identity for the network <NUM>. That is, the USIM <NUM> may have stored thereon two SIM profiles: a first profile for the home network <NUM>, and a second profile for the network <NUM>. The network keys for the home network <NUM> may be stored in the first profile (and so form part of the first SIM identity), and the private network keys for the network <NUM> may be stored in the second profile (and so form part of the second SIM identity).

Storage of the private network keys and additional identification information for the communication network <NUM> within the USIM <NUM> may be facilitated by the provision of additional storage fields within the USIM <NUM>. For example, compared to conventional USIMs, USIM <NUM> may include additional elementary file (EF) fields to store the requisite information. These additional EFs may be stored within memory in the USIM <NUM>, such as the data store <NUM>. The USIM <NUM> may include a first additional EF for storing the private network keys pK and pOpc (this EF being denoted herein as EFpKeys); a second additional EF for storing the network code pHPLMN identifying network <NUM> (this EF being denoted herein as EFpHPLMN); and a third additional EF for storing the identification code pIMSI for the device within the network <NUM> (this EF being denoted herein as EFpIMSI).

The USIM <NUM> may additionally store a flag that indicates the device <NUM> is permitted to access the network <NUM> (subject to authentication, which will be described below). In the context of the current example, this flag may be referred to as a pEPC flag. The flag may indicate that the USIM <NUM> has a dual SIM identity. That is, the flag may indicate that the USIM <NUM> includes a SIM identity (i.e. a SIM profile) for the network <NUM>. This flag may also be stored within an additional EF field. This EF may be denoted herein as EFpEPC.

Thus, in accordance with the examples described herein, the USIM <NUM> may include four additional EF fields compared to conventional USIMs.

At step <NUM> the device <NUM> is authenticated on and attaches to the network <NUM> using the private network keys stored in the secure storage area <NUM> on the device.

<FIG> shows a call-flow illustrating how the device <NUM> is first authenticated onto and attaches to the network <NUM> using the private network keys stored in the secure storage area <NUM> of the device. The first attachment of the device to the network <NUM> following derivation of the network keys for the network <NUM> may be referred to as the primary attachment.

At step <NUM> (denoted <NUM>), the device <NUM> communicates a first attach request message to the eNodeB <NUM> of the network <NUM> to request primary attachment. This attach request message includes the pEPC flag indicating the device's USIM <NUM> includes a SIM profile for the network <NUM>. The attach request message may additionally include the identification information for the network <NUM> (e.g. the pHPLMN) and identification information for the device <NUM> within the network <NUM> (e.g. the pIMSI).

At step <NUM> (denoted <NUM>), an authentication process is initiated by the network <NUM> in response to receiving the attach request message. As part of this process, the HSS <NUM> is accessed to determine whether private network keys are stored against an identifier for the device <NUM> (e.g. the device's pIMSI).

Before the primary attachment of device <NUM> to the network <NUM>, no network keys for the network <NUM> are stored against the device's identifier within network <NUM>. In other words, the primary attachment is initiated by the device <NUM> at a time when the network <NUM> has no network keys stored against the device's identifier.

At step <NUM> (denoted <NUM>), the HSS <NUM> initiates a primary attachment process in response to determining that no private network keys for the network <NUM> are stored against the device's identifier. As part of this step, the HSS <NUM> communicates an 'initiate attachment' message to the device <NUM>.

At step <NUM> (denoted <NUM>), the device <NUM> communicates a second attach request message to request attachment to the network <NUM>. The device communicates the second attach request message in response to receiving the 'initiate attachment' message from the HSS <NUM>. The second attach request message is communicated to the eNodeB <NUM>.

The second attach request message includes a copy of the network keys for the network <NUM> from the device's secure storage area <NUM>. That is, a copy of the private network keys stored.

in the device's secure storage area <NUM> are included within the second attach request message.

At step <NUM> the eNodeB <NUM>, in response to receiving the second attach request message from the device <NUM>, communicates the second attach request message to the MME <NUM> (denoted by <NUM>).

At step <NUM>, the network keys from the secure storage area <NUM> are used to authenticate the device <NUM> (denoted by <NUM>). The authentication of the device <NUM> using these network keys may be performed by the MME <NUM>. The MME <NUM> may determine that this authentication is a one-time authentication using the network keys stored in the device's secure storage area <NUM>. That is, the MME <NUM> may authenticate the device <NUM> using the private network keys stored in the secure area <NUM> despite there being no copy of these keys stored in the HSS <NUM>. In other words, the one-time authentication is performed at a time when there are no private network keys stored against the device's identifier within the network <NUM>. This is possible due to the high level of security of the secure area <NUM>; this one-time authentication is performed using the network keys stored in the secure area <NUM> and not those stored in the USIM <NUM> due to the higher level of security of the area <NUM> compared to the USIM <NUM>.

The MME <NUM> may determine that it is to perform this one-time authentication from information included within the first or second attach request messages sent from the device <NUM>. For example, the MME <NUM> may determine it is to perform the one-time authentication from the flag pEPC and/or in response to receiving the private network keys from the device's secure area <NUM>.

Following completion of step <NUM>, the device <NUM> is authenticated on and attached to the network <NUM>. Thus, to summarise steps <NUM> to <NUM> of the call flow:.

Following authentication of the device <NUM> on the network <NUM>, at step <NUM> a node of the network <NUM> (in this example the HSS <NUM>) initiates a request for the device <NUM> to communicate a copy of its private network keys from the secure area <NUM> and to delete the copy of the network keys stored in the secure area <NUM>. The network keys sent from the secure area <NUM> will be used for subsequent attachments of the device <NUM> to the network <NUM>. The HSS <NUM> may initiate this request by sending a request message to the device <NUM> (shown in <FIG> at <NUM>). Request message <NUM> is sent after authentication of device <NUM> is complete.

At step <NUM> the device <NUM>, in response to receiving the request message <NUM>, communicates a copy of the private network keys from its secure area <NUM> to the node that communicated the request message <NUM> (the HSS <NUM>, in this example). This is shown at <NUM>. The device <NUM> may send the copies of the network keys from its secure area <NUM> in secure messages. The messages may be encrypted, for example. The messages may be sent according to the OTA protocol; i.e. the messages may be OTA messages. To enhance security, the device <NUM> may communicate each private network key to the HSS <NUM> in a separate message; i.e. only a single key is included in each message. Thus, in this example, the device <NUM> may communicate a first (potentially encrypted) message containing the private network key pK, and a second (potentially encrypted) message containing the private network key pOpc.

At step <NUM>, the device <NUM> deletes the copy of the private network keys from its secure area <NUM>. The device performs this action in response to receiving request message <NUM>. Following step <NUM>, only a single copy of the private network keys is stored on the device <NUM> (those on the USIM <NUM>).

At step <NUM>, the HSS <NUM> stores the device's private network keys received from the secure area <NUM>. The HSS <NUM> stores these private network keys against an identifier for the device <NUM>. In this example, that identifier is the pIMSI identification code that identifies the device <NUM> within the network <NUM>.

It is to be appreciated that the numbering of steps <NUM> and <NUM> does not imply a strict temporal order of these steps: step <NUM> may be performed before or after step <NUM>.

At step <NUM> the HSS <NUM> initiates the detachment of the device <NUM> from the network <NUM>. This permits the device <NUM> to subsequently attach to the network <NUM> using a more conventional attachment procedure. The HSS <NUM> may initiate the detachment of the device from the network <NUM> by communicating a detach request message <NUM>. The HSS <NUM> initiates the detachment of the device from network <NUM> at some time after the device's private network keys have been received and stored (i.e. after the completion of step <NUM>).

The above examples describe how the device's private network keys stored in the secure area <NUM> are used to authenticate the device <NUM> on the network <NUM> as part of performing a primary attachment of the device <NUM> to the network <NUM>.

Subsequent attachments of the device <NUM> to the network <NUM> (i.e. attachments following the primary attachment) are performed using the device's private network keys stored in the USIM <NUM>.

<FIG> shows a call flow illustrating a subsequent attachment of the device <NUM> to the network <NUM>. A subsequent attachment is one that is performed after the primary attachment is complete. Subsequent attachments are performed at a time when copies of the network keys for network <NUM> are stored against the device's identifier within the network <NUM>.

Device <NUM> may initiate the subsequent attachment in response to receiving a broadcast message from the network <NUM>. The broadcast message may advertise the network <NUM>. In this example, the broadcast message is an SIB1 message. Compared to conventional SIB1 messages, the SIB1 message broadcasted by the network <NUM> contains additional data fields that identify the network <NUM>. These additional data fields include a first data field indicating the network <NUM> is a private network, and a second data field indicating the identity of the network <NUM> (e.g. the network operator for network <NUM>). The use of these additional fields to identify the network <NUM> enables the device <NUM> to prioritise the network <NUM> over other networks when in a state in which it is searching for a network to connect to.

Thus the device <NUM>, in response to receiving an SIB1 broadcast message from the network <NUM>, determines the network's identity.

At step <NUM>, the device <NUM> initiates a subsequent attachment by communicating an attach request message <NUM> to the network <NUM> in response to receiving the broadcast message.

The attach request message <NUM> is communicated to the eNodeB <NUM>. The attach request message <NUM> includes the flag pEPC indicating the device <NUM> has a dual identity SIM (i.e. indicating that the device's USIM <NUM> includes a SIM profile for the network <NUM>). It may further include identification information for the network <NUM> (e.g. the pHPLMN code) and identification information for the device <NUM> within the network <NUM> (e.g. the pIMSI code).

At step <NUM>, the eNodeB <NUM> communicates the attach request to the MME <NUM> in message <NUM>.

The MME <NUM> then authenticates with the device <NUM> (illustrated at <NUM>). This authentication process may follow the process outlined for the attach procedure in 3GPP TS <NUM>. This process may include the MME <NUM> issuing an authentication challenge based on the network keys stored against the device's identifier in the HSS <NUM> (i.e. the network keys stored in the HSS <NUM> at step <NUM> of <FIG>). In contrast to the conventional authentication to the home network <NUM>, the device <NUM> will respond to the MME <NUM> authentication challenge using the network keys for the network <NUM> stored in EFpkeys in the USIM <NUM> instead of the network keys for the home network <NUM>.

Following authentication of the device <NUM>, a session is created as denoted generally at <NUM> to complete attachment of the device <NUM> to the network <NUM> as outlined for the attach procedure in 3GPP TS <NUM>. The call flow may then continue in accordance with the attach procedure outlined in 3GPP TS <NUM>.

Thus, to summarise the subsequent attachment of the device <NUM> to the network <NUM>:.

The above-described approaches for primary and subsequent authentications and attachments to a non-home network may provide several advantages. The approaches enable a device that includes only a single SIM to access two networks that do not have roaming agreements and/or physical connections between them. It retains the security advantages of using a SIM for network authentication without requiring a user to physically swap SIMs when connection to a different network is required. The approaches can also avoid compromising security requirements by avoiding the need to explicitly share key information between the two networks.

In the examples described above, network <NUM> was a private network. The private network may be of any suitable size. For example, it may be composed of one or more small cells, or it may be composed of one or more macrocells. In other examples, the network <NUM> may not be a private network but could be some other public network that is not the device's home network.

The above examples have been illustrated in the context of LTE networks. Consequently, the device's SIM has been described as a USIM. In other examples, one or both of the networks <NUM> and <NUM> may be a different type of network, such as a GSM or UMTS network. The device's SIM need not be a USIM, but could be a SIM card. The term 'SIM' has been used herein to refer generally to these different types of SIM.

Though some of the steps above have been described as being performed by particular nodes of the network, it will be appreciated that the steps could be performed by any suitable network node. For example, each step described above as being performed by an HSS may be performed by an authentication centre (AuC).

Claim 1:
A method of authenticating a device (<NUM>) subscribed to a first wireless communication network (<NUM>) on a second wireless communication network (<NUM>), the method comprising:
deriving (<NUM>) at a node (<NUM>) within the first wireless communication network (<NUM>) a set of one or more network keys for the second wireless communication network (<NUM>) from one or more network keys of the first wireless communication network (<NUM>) that uniquely identify the device within the first wireless communication network;
communicating (<NUM>) the derived set of one or more network keys to the device (<NUM>);
storing (<NUM>) a first copy of the derived set of one or more network keys within an identification module (<NUM>) at the device (<NUM>) and a second copy of the derived set of one or more network keys within a secure area (<NUM>) of the device (<NUM>);
authenticating (<NUM>) the device on the second wireless communication network (<NUM>) using the second copy of the derived set of one or more network keys stored in the secure area (<NUM>) of the device (<NUM>);
communicating (<NUM>) a copy of the set of one or more derived network keys from the secure area of the device to a node of the second wireless communication network for use in subsequent attachments of the device to the second wireless communication network, then deleting the second copy of the set of one or more derived network keys from the secure area of the device; and
attaching (<NUM>) the device to the second wireless communication network using the first copy of the derived set of one or more network keys stored in the identification module of the device.