Patent Description:
Mobile network operators are often faced with the challenge of updating their SIM cards in the field to deploy fixes or new applications. The current standard for this is called Over-The-Air (OTA) and it usually requires that the subscription plan supports Short Message Service (SMS). With the advent of <NUM> technologies, a new form of OTA has emerged: HTTP OTA. This is described for example in "Global Platform Card Specification Version <NUM>, Amendment B Version <NUM>"; ETSI TS <NUM><NUM>: "Smart Cards; Secured packet structure for UICC based applications"; and ETSI TS <NUM><NUM>: "Smart cards; Remote APDU structure for UICC based applications".

HTTP OTA is a technology which enables the delivery of remote management commands to the SIM card over an IP network instead of using the predecessor technology, SMS OTA.

In parallel to the advent of <NUM> technologies, there has been an emergence of autonomous connected devices which has caught the name of Internet-of-things (IoT). Numerous mobile loT devices are networked nowadays using SIM-enabled communications modules (e.g. a HSPDA modem). Document <CIT> is relevant in the field of OTA updates.

The inventor has recognised that many manufacturers of SIM-enabled communication modules chose not to implement the necessary support for HTTP OTA through implementation of Bearer Independent Protocol (BIP) in the communication module. This is due to various reasons including increased cost and effort for development and test of the communication module. On the other hand, the support for HTTP OTA through BIP was implemented quite rapidly in the new UICC cards by SIM vendors.

Currently, support for BIP inside communication modules, is only available in some high-end phones and in communication modules which can host SIM cards of type eUICC in MFF2 form factor. Consequently, most communication modules which interface with the removable SIM formats (mini SIM, micro SIM and nano SIM), do not support HTTP OTA. Furthermore, in many deployments of IOT projects, the only available communication bearer is an IP network.

In order to cater for this lack of support for HTTP OTA, embodiments of the present disclosure implement a software agent which can help to securely channel the OTA commands to the SIM card found inside a legacy communication module by taking over the HTTP part and using the hosted SIM (UICC, eUICC, iUICC or SoftSIM) as a secure element to establish a secure communication channel. The invention is defined in the independent claims <NUM>, <NUM> and <NUM>.

According to one aspect of the present disclosure there is provided a method of deriving a shared key for use in communicating with a network entity, wherein the method is performed by an agent on a host device and comprises: requesting a SIM identifier of a subscriber identity module (SIM) on the host device from a communication module of the host device; receiving the SIM identifier from the communication module and deriving an agent identifier from the SIM identifier; transmitting the agent identifier and the SIM identifier over a network to the network entity; receiving, via said network, a random value from the network entity; supplying the random value to the communication module to initiate a SIM authentication procedure, and in reply receive an authentication response from the communication module; and deriving the shared key from the authentication response.

According to another aspect of the present disclosure there is provided a method of updating a subscriber identity module,SIM, on a host device, wherein the method is performed by an agent on the host device and comprises: deriving a pre-shared key , said deriving comprising: requesting a SIM identifier of the SIM via a communication module of the host device; receiving the SIM identifier from the SIM via the communication module and deriving an agent identifier from the SIM identifier; transmitting the agent identifier and the SIM identifier over a network to a SIM update server; receiving, via said network, a random value from the SIM update server; supplying the random value to the SIM via the communication module to initiate a SIM authentication procedure, and in reply receive an authentication response from the SIM via the communication module; and deriving the pre-shared key from the authentication response; transmitting an update request message over said network to the SIM update server, wherein the update request message comprises said agent identifier and is encrypted prior to transmission using the pre-shared key; receiving an update response message, via said network, from the SIM update server, wherein the update response message comprises update data and is encrypted using the pre-shared key; following decryption of the update response message using the derived pre-shared key, transmitting the update data to the communication module for relaying to the SIM for execution to update the SIM.

The authentication response may comprise a signed response and a cipher key.

Deriving the pre-shared key from the authentication response may comprise using at least one of the signed response and the cipher key to derive the pre-shared key.

Deriving the pre-shared key from the authentication response may comprise using the random value to derive the pre-shared key.

Deriving the pre-shared key from the authentication response may comprise concatenating the cipher key with itself to generate a concatenated result and applying a bitwise XOR operation on the concatenated result and the random value to derive the pre-shared key.

The update data may be encrypted with a symmetric cryptographic key stored by the SIM.

The update request message may comprise the SIM identifier.

The method may further comprise: in response to transmitting the update data to the communication module: receiving an execution result from the SIM via the communications module; and transmitting a further update request message over said network to the SIM update server, the update request message conveying the execution result, wherein the update request message is encrypted prior to transmission using the pre-shared key.

An Attention (AT) Command may be used for at least one of: said requesting a SIM identifier of the SIM from a communication module of the host device; said supplying the random value to the communication module to initiate a SIM authentication procedure; and said transmitting the update data to the communication module.

An application programming interface provided by the communication module may be used for at least one of: said requesting a SIM identifier of the SIM from a communication module of the host device; said supplying the random value to the communication module to initiate a SIM authentication procedure; and said transmitting the update data to the communication module.

Deriving an agent identifier from the SIM identifier may comprise appending a prefix to the SIM identifier.

The deriving a pre-shared key may be triggered based on one of: (i) detecting a user input on the host device; (ii) receiving a session initiation message, via said network, from the SIM update server; and (iii) detecting an expiry of a predetermined time interval.

The SIM identifier may be one of: (i) an International Mobile Subscriber Identity associated with the SIM, (ii) an Integrated Circuit Card Identifier associated with the SIM, and (iii) a Mobile Station International Subscriber Directory Number associated with the SIM.

According to another aspect of the present disclosure there is provided a computer program product, the computer program product comprising code embodied on a non-transient computer-readable medium and configured so as when executed on a processor of the host device to perform the methods described herein.

According to another aspect of the present disclosure there is provided a device with a processor, said processor coupled to a communications module that is coupled to a subscriber identity module, SIM, associated with the device, the processor configured to: request a SIM identifier of the SIM via the communication module; receive the SIM identifier from the SIM via the communication module and derive an agent identifier from the SIM identifier; transmit the agent identifier and the SIM identifier over a network to a SIM update server; receive, via said network, a random value from the SIM update server; supply the random value to the SIM via the communication module to initiate a SIM authentication procedure, and in reply receive an authentication response from the SIM via the communication module; derive a pre-shared key from the authentication response; transmit an update request message over said network to the SIM update server, wherein the update request message comprises said agent identifier and is encrypted prior to transmission using the pre-shared key; receive an update response message, via said network, from the SIM update server, wherein the update response message comprises update data and is encrypted with the pre-shared key; following decryption of the update response message using the derived pre-shared key, transmit the update data to the communication module for relaying to the SIM for execution to update the SIM.

According to another aspect of the present disclosure there is provided a device with a processor, said processor coupled to a communications module that is coupled to a subscriber identity module (SIM) associated with the device, the processor configured to: request a SIM identifier of the SIM from the communication module; receive the SIM identifier from the communication module and derive an agent identifier from the SIM identifier; transmit the agent identifier and the SIM identifier over a network to the network entity; receiving, via said network, a random value from the network entity; supply the random value to the communication module to initiate a SIM authentication procedure, and in reply receive an authentication response from the communication module; and derive a shared key from the authentication response.

According to another aspect of the present disclosure there is provided a method of updating a subscriber identity module, SIM, on a host device, wherein the method is performed by a SIM update server and comprises: deriving a pre-shared key, said deriving comprising: receiving, from an agent on a host device, an agent identifier and a SIM identifier of the SIM transmitted from the host device over a network; generating a random value; supplying the random value and the SIM identifier of the SIM to an authentication entity, and in reply receive an authentication response from the authentication entity; and deriving the pre-shared key from the authentication response; storing the pre-shared key in association with the agent identifier in memory; transmitting the random value to the agent over the network receiving an update request message, via said network, from the agent on the host device, wherein the update request message comprises said agent identifier and is encrypted prior to transmission using the pre-shared key; and following decryption of the update request message using the pre-shared key; transmitting an update response message, via said network, to the host device, wherein the update response message comprises update data and is encrypted with the pre-shared key;.

According to another aspect of the present disclosure there is provided a computer program product for updating a subscriber identity module (SIM) on a host device, the computer program product comprising code embodied on a non-transient computer-readable medium and configured so as when executed on a processor of a network entity (SIM update server) to perform the methods described herein.

According to another aspect of the present disclosure there is provided a SIM update server for updating a subscriber identity module, SIM, on a host device, the SIM update server comprising at least one processor configured to: receive, from an agent on a host device, an agent identifier transmitted from the host device over a network; generate a random value; supply the random value and a SIM identifier of the SIM to an authentication entity, and in reply receive an authentication response from the authentication entity; derive a pre-shared key from the authentication response; store the pre-shared key in association with the agent identifier in memory coupled to the SIM update server; receive an update request message, via said network, from the agent on the host device, the update request message comprising said agent identifier and is encrypted prior to transmission using the pre-shared key; and following decryption of the update request message using the pre-shared key, transmit an update response message, via said network, to the host device, wherein the update response message comprises update data and is encrypted with the pre-shared key.

The SIM update server may comprise multiple processors for updating the SIM on the host device, with the multiple processors distributed over a plurality of coupled elements (e.g. servers) in communication with one another (e.g. in a cloud architecture) in a manner known to those skilled in the art.

The processor may be configured to derive the pre-shared key from the authentication response by using at least one of the signed response and the cipher key.

The processor may be configured to derive the pre-shared key by additionally using the random value.

The processor may be configured to derive the pre-shared key from the authentication response by concatenating the cipher key with itself to generate a concatenated result and applying a bitwise XOR operation on the concatenated result and the random value to derive the pre-shared key.

The update data may be encrypted with a symmetric cryptographic key stored in said memory.

The skilled person will appreciate that processor control code to implement the above-described methods, devices, and network entities may run, for example, on a general purpose computer, a mobile computing or communications device, or on a digital signal processor (DSP) or across multiple processors. The code may be provided on a non-transitory physical data carrier such as a disk, CD- or DVD-ROM, programmed memory such as non-volatile memory (e.g. Flash) or read-only memory (Firmware). Code (and/or data) to implement embodiments of the invention may comprise source, object or executable code in a conventional programming language (interpreted or compiled) such as C, or assembly code, or code for a hardware description language. As the skilled person will appreciate such code and/or data may be distributed between a plurality of coupled components in communication with one another.

The skilled person will similarly understand that where references are made to a server this may be to one or multiple servers; again functionality may be distributed across devices. Similarly some or all of the storage/processing functions may be provided in the cloud, which may be a public cloud or a private cloud. As used herein "cloud" means a system that may dynamically perform provisioning and provide computing resources such as a CPU, a memory, a storage, and network bandwidth, for example according to a demand on the network. The skilled person will also understand that server software may be implemented on a physical computer or computer system which is at the same time running client software.

These and other aspects will be apparent from the embodiments described in the following. The scope of the present disclosure is not intended to be limited by this summary nor to implementations that necessarily solve any or all of the disadvantages noted.

For a better understanding of the present disclosure and to show how embodiments may be put into effect, reference is made to the accompanying drawings in which:.

In this specification, the following definitions/examples will be used:.

In the standard Hypertext Transfer Protocol Over-The-Air (HTTP OTA) (see <FIG>), the Secure channel protocol <NUM> (SCP81) is implemented at the SIM and device level. It requires support for BIP in the host device (more specifically in the communication module of the host device). Support for BIP in the host device means to cater for some specific card application toolkit commands and events namely: OPEN CHANNEL, CHANNEL STATUS, CLOSE CHANNEL, SEND DATA, RECEIVE DATA and EVENT DATA AVAILABLE. This is described in ETSI TS <NUM><NUM>: "Smart Cards; Card Application Toolkit (CAT)".

<FIG> shows a flow chart of a prior art HTTP OTA message protocol <NUM>.

In a typical HTTP OTA session, in response to a communication module receiving a binary SMS message from an OTA server (step <NUM>), at steps <NUM>-<NUM> the communication module opens a Transmission Control Protocol (TCP) channel to a designated server address (the I. P address is specified in the OPEN CHANNEL command). The device in turn forwards the higher-level protocol messages (requests), received from the SIM in the form of SEND DATA commands (at step <NUM>), through the TCP channel towards the OTA server (at step <NUM>). Those higher-level messages are actually wrapped in HTTPS packets by the SIM. The OTA server processes the requests and sends back the response messages (at step <NUM>) which potentially contain Remote File Management (RFM) or Remote Application Management (RAM) commands to be executed by the SIM (at steps <NUM>-<NUM>). In turn the SIM sends execution results to the communication module which relays the executions results to the OTA server (step <NUM>) in the form of a new request until the OTA server sends an empty response (at step <NUM>). In response to processing the empty response (steps <NUM>-<NUM>), the SIM instructs the communication module to close the TCP channel (step <NUM>). The communication module then communicates with the OTA server to close the TCP channel (steps <NUM>-<NUM>) and informs the SIM of the TCP channel closure (step <NUM>).

The higher-level messages which are exchanged through the TCP channel are wrapped in HTTP packets which are themselves encapsulated in TLS protocol packets. The specific TLS protocol version used here is a called TLS Pre-Shared Key (PSK) in which a pre-shared secret key which is known by the OTA server and the SIM, is used to encrypt/decrypt the communication packets.

Referring now to <FIG>, this shows a block diagram of a system <NUM> for updating SIMs according to embodiments described herein. The system comprises an IP network <NUM> comprising conventional network elements and including a plurality of base stations 114a (of which only one is shown for illustration purposes) for communicating with host devices 102a. A host device 102a is a computing device capable of transmitting data to, and received information from, the network <NUM>. The host device 102a may take the form of, for example, a laptop computer, tablet style computer, or mobile phone (which may be referred to as a "smart phone"). In the example of <FIG>, the host device 102a is shown as a mobile device (and is thus referred to herein as a mobile station) however this is merely an example.

Each of the mobile stations 102a communicate with network <NUM> via a wireless data communication link and have an associated SIM 102b. In the illustrated example, the network <NUM> is also coupled to the Internet <NUM>.

The system <NUM> also includes a SIM update server <NUM> (otherwise referred to herein as a network entity) for updating a SIM. The SIM update server <NUM> is configured to send over-the-air (OTA) updates to the SIM and is therefore also referred to herein as an OTA server. As illustrated this is shown as a separate element but in practice this may be implemented as an additional software component running on an existing network device or server. The SIM update server <NUM> includes a processor <NUM> and memory <NUM> storing code to derive a pre-shared key, receive an update request message from a host device, and transmit update data to the host device as described in more detail later. The SIM update server <NUM> is coupled to a Home Location Register (HLR) <NUM>, otherwise referred to as a Home Subscriber Server (HSS). The HLR terminology is typically used when the mobile network <NUM> is a <NUM> or <NUM> network and the HSS terminology is typically used when the mobile network <NUM> is a <NUM> LTE network.

The HLR/HSS <NUM> is a database used for the storage and management information of every subscriber that is authorized to use the network <NUM>. The HLR stores subscriber information which may include, for each subscriber, the International Mobile Subscriber Identity (IMSI), service subscription information, location information, service restrictions etc. of the subscriber. The HLR/HSS <NUM> comprises, or is coupled to, an Authentication Centre (AuC) <NUM>. The AuC <NUM> provides authentication of each subscriber. The AuC <NUM> comprises a database storing, for each subscriber, a shared key Ki for authentication of the subscriber's SIM. The AuC <NUM> may store a plurality of shared keys Ki each in associated with a respective IMSI (or other SIM identifier).

Whilst <FIG> illustrates one example system whereby the network <NUM> is a mobile (cellular) communications network, this is merely an example. For example, embodiments extend to implementing the OTA update using the methods described herein whereby a host device is coupled to the Internet or the IP network <NUM> via a WiFi link over a WiFi network. That is, in embodiments, an OTA update can be achieved through any data connection (e.g. WiFi, LAN etc.) even if the SIM 102b cannot authenticate on a cellular network (for example during roaming attempts).

<FIG> shows a block diagram of an exemplary mobile station 102a. The connections shown in <FIG> between the various components of the mobile station 102a are merely an example.

As shown in <FIG> the mobile station 102a comprises a SIM 102b. As the skilled person will be aware, a "SIM" used herein may comprise a SIM card or a so-called eSIM (a module which may be embedded in a device), or a so-called softSIM or virtual SIM (a software SIM which may be stored, for example in a module of a device such as a communication module <NUM>, and optionally downloaded over the air) or so-called secure element. The technology we describe is also applicable to SIMs other than SIM cards. Thus, a SIM may be embodied in, for example, a UICC (Universal Integrated Circuit Card), eUICC, iUICC, and so forth.

A communications module <NUM> acts as an intermediary for communications between the SIM 102b and an agent <NUM> (described in more detail below). The communications module <NUM> is a modem e.g. an HSPDA modem. In embodiments described herein, the communications module <NUM> may not support the Bearer Independent Protocol (BIP), however the agent <NUM> enables a form of HTTP OTA without requiring support for BIP in the communication module and therefore allows SIM cards inside of legacy communication modules (which do not support BIP) to be able to securely exchange RFM and RAM messages over IP networks.

The communications module <NUM> may be external to the mobile station 102a in that it is a separate unit housed in a separate casing, but which is connected or connectable to a processor <NUM> of the mobile station 102a by means of a wired or wireless connection (as well as being removable or being able to be disconnected from the mobile station 102a). For example, the communications module <NUM> may take the form of a dongle for plugging into the mobile station 102a. As a mere example the communications module may take the form of the MS2131 USB-stick by Huawei. As an alternative, the communications module <NUM> may be internal to the mobile station 102a, e.g. taking the form of a wireless module in the mobile station 102a. For example, both the communications module <NUM> and host processor <NUM> may be housed within the same casing of the mobile station 102a.

The mobile station 102a further comprises an agent <NUM> (an update handler) which is configured to communicate with the communications module <NUM>. The agent <NUM> is further configured to communicate with the OTA server <NUM> via the network <NUM>. That is, the handling of HTTP over TLS is delegated to the agent <NUM> on the mobile station 102a.

The functionality of the agent <NUM> may be implemented in code (software) stored on a memory (e.g. memory <NUM>) comprising one or more storage media, and arranged for execution on the processor <NUM> comprising one or more processing units. The code is configured so as when fetched from the memory <NUM> and executed on the processor <NUM> to perform operations in line with embodiments discussed below. An implementation of the software agent <NUM> would typically consist of a piece of code to be executed on an Operating System (OS) of the mobile station 102a. The OS (e.g. Windows™, Mac OS™ and Linux™) is executed on the processor <NUM>. The agent <NUM> can come, for example, in the form of a command line tool which can trigger a communication session. Alternatively, it is not excluded that some or all of the functionality of the agent <NUM> is implemented in dedicated hardware circuitry, or configurable hardware circuitry like an FPGA.

In one embodiment, the agent <NUM> is in the form of an agent application which is able to be downloaded by a customer onto their computing device. The agent application is then able to trigger a remote update in places where the SMS OTA is not available or in the case that the payload on SMS would require too many concatenated SMS messages (thereby increasing the risk of failure). In one example scenario, a user living in a remote area has a SIM which is not connecting to the local mobile network, the user can be directed to connect the communication module <NUM> to their computing device and download the agent application <NUM> onto their computing device. In accordance with functionality described in more detail below the agent application <NUM> is able to receive new SIM credentials as updates via a connection to the OTA server <NUM> via a WiFi internet link which can be then be used to reconfigure the SIM in order to connect to the local mobile network.

The agent <NUM> is configured to communicate with the OTA server <NUM> using a communications interface <NUM> of the mobile station 102a. The communications interface <NUM> may comprise a wireless transceiver to enable communications between the agent <NUM> and the network <NUM>.

The mobile station 102a may further comprise a display <NUM> such as a screen or touch screen. The mobile station 102a may comprise at least one input device <NUM> for receiving user inputs from a user of the mobile station 102a e.g. a keypad, a microphone, a camera, and touch screen; and/or at least one output device <NUM> e.g. a speaker.

<FIG> shows a block diagram of an exemplary SIM card of a SIM 102b. The SIM card comprises a processor <NUM> coupled to working memory <NUM>, a non-volatile data store <NUM>, such as EEPROM, and permanent program memory <NUM> such as ROM. The SIM card also has an interface <NUM> to receive power and to accept commands from and provide responses to the communications module <NUM>. The permanent program memory <NUM> may store network/device interface code, an operating system for example comprising Java Card, and typically though not essentially a Sim Application Toolkit (STK). The non-volatile data store <NUM> typically stores user phone directory information, settings data, software patches and the like. The non-volatile data store <NUM> may store the shared key Ki and the IMSI associated with the SIM102b. The authentication key Ki is "shared" in that it is stored by both the SIM 102b and the AuC <NUM>. Typically, the IMSI is publicly accessible whereas the shared key Ki is stored in protected manner.

Further code to perform SIM operations described below with reference to <FIG> and <FIG> may reside in permanent program memory <NUM> but alternatively it could partly or wholly be stored in non-volatile data store <NUM>.

As previously described, although <FIG> shows SIM 102b as a SIM card its functions could equally be implemented as an eSIM or a softSIM.

We now turn to <FIG> which illustrates a process <NUM> of a procedure to derive a pre-shared key (PSK). The pre-shared key (PSK) is a cryptographic key and the process <NUM> is carried out at the beginning of a communication session so that both the mobile station 102a and OTA server <NUM> mutually derive the pre-shared key for use in encrypting communications between the mobile station 102a and OTA server <NUM>. That is, the agent <NUM> and OTA server <NUM> share the key (PSK) that they have mutually derived.

At step <NUM> the agent <NUM> transmits a request for an identifier of the SIM 102b to the communication module <NUM>. As shown in <FIG>, the requested SIM identifier may be the IMSI associated with SIM 102b or the ICCID, MSISDN or any other identifier associated with SIM 102b that would be known to persons skilled in the art.

Step <NUM> may be achieved, for example, by the agent <NUM> sending an ATtention (AT) Command to a serial interface of the communication module <NUM>. An "AT Command" is a known message format for serial communication with modems defined in 3GPP TS <NUM>. For instance, the "AT+CIMI" command can be used at step <NUM> to retrieve the identifier of the SIM 102b.

An alternative way that step <NUM> can be achieved is by using an Application Programming Interface (API) provided by the communication module <NUM> such that the agent <NUM> can transmit an API call to the communication module <NUM> to request the SIM identifier.

Step <NUM> may be triggered by a user of the mobile station 102a providing an input via an input device <NUM> of the mobile station 102a (e.g. by making a selection in a graphical user interface displayed on the display <NUM>). Alternatively, or additionally, a mobile network operator (MNO) may trigger the communication session by transmitting a session initiation message from the OTA server to the mobile station 102a over the network <NUM>. In this embodiment, the agent <NUM> should be programmed to support the necessary triggers, such as SMS processing or some form of network service. Alternatively, or additionally, step <NUM> may be triggered based on the agent <NUM> detecting the expiry of a predetermined time interval (e.g. by monitoring an internal timer) such that the process <NUM> is performed on a periodic basis.

In response to receiving the request from the agent <NUM>, the communication module <NUM> requests the SIM identifier from the SIM 102b at step <NUM>. This may be performed by executing standard application protocol data unit (ADPU) commands.

At step <NUM> the SIM 102b provides the requested SIM identifier to the communication module <NUM>, the communication module <NUM> then returns the SIM identifier to the agent <NUM> at step <NUM>.

In response to receiving the SIM identifier, the agent <NUM> is configured to generate an agent identifier from the SIM identifier. The agent identifier is a unique string that identifies the agent <NUM>. In one example, the agent <NUM> derives the agent identifier by appending the prefix "agent" to the SIM identifier. It will be appreciated that this is merely an example to illustrate the concept and alternative methods to derive the agent identifier using the SIM identifier may be used.

At step <NUM> the agent <NUM> transmits the agent identifier and the SIM identifier to the OTA server <NUM> over the network <NUM>. At step <NUM> the agent may trigger an API on the IP network <NUM> (e.g. a Web API), with the agent identifier as a parameter. This API is offered through a secure channel, e.g. HTTPS. The transmission of the agent identifier to the OTA server <NUM> at step <NUM> acts to request a challenge, described in more detail below.

In response to receiving the agent identifier, at step <NUM> the OTA server generates a random value (RAND), which may for example be <NUM> bits in length, otherwise referred to herein as a "challenge" and transmits the challenge (RAND) and the SIM identifier to the AuC <NUM>.

The AuC <NUM> retrieves the shared key Ki stored in association with the SIM identifier and generates a signed response (SRES) using a first authentication algorithm (e.g. A3 encryption algorithm) that takes the shared key Ki and challenge (RAND) as inputs, and a cipher key (Kc) using a second authentication algorithm (e.g. A8 encryption algorithm) that also takes the shared key Ki and challenge (RAND) as inputs.

At step <NUM> the OTA server <NUM> receives the signed response (SRES) and the cipher key (Kc) from the HLR/HSS <NUM>.

At step <NUM>, the OTA server <NUM> derives a pre-shared key (PSK), which may be <NUM> bits in length, using at least one of the signed response (SRES) and the cipher key (Kc). Optionally the challenge (RAND) may additionally be used to derive the pre-shared key (PSK). One example of how the pre-shared key (PSK) may be derived is by concatenating the cipher key (Kc) with itself and then applying a bitwise XOR operation of the result with the challenge (RAND) as follows: <MAT>.

It will be appreciated that this is merely an example to illustrate the concept and alternative methods to derive the pre-shared key (PSK) may be used.

The pre-shared key (PSK) can be temporary in nature, meaning that it can be forgotten after a communication session between the mobile station 102a and the OTA server <NUM> has taken place with it.

Once the OTA server <NUM> has derived the pre-shared key (PSK) it associates the pre-shared key (PSK) with the agent identifier received at step <NUM> and stores the associated pre-shared key (PSK) and agent identifier in internal memory on the OTA server <NUM> (it will be appreciated that the associated pre-shared key (PSK) and agent identifier may alternatively be stored in memory that is external to the OTA server <NUM>). This enables the OTA server <NUM> to know that it is to use the pre-shared key (PSK) for encryption of communications to the agent <NUM> on mobile station 102a.

At step <NUM> the OTA server <NUM> transmits the challenge (RAND) over the network <NUM> to the agent <NUM> on mobile station 102a.

At step <NUM>, the agent <NUM> supplies the random value to the communication module <NUM> to initiate a SIM authentication procedure, and in reply receives an authentication response from the communication module <NUM> (at step <NUM>) as described in more detail below.

At step <NUM>, the agent <NUM> may transmit an AT command to the communication module <NUM>. In particular, the challenge (RAND) may be used as seed by the agent <NUM> to invoke a command in the SIM (AUTHENTICATE command) with this random value as a parameter. One way to invoke the AUTHENTICATE APDU at the SIM level is to use the AT+CSIM command and collect the response APDU from the AT+CSIM response (step <NUM>) to the AT command. An alternative way that step <NUM> can be achieved is by using an API provided by the communication module <NUM> such that the agent <NUM> can transmit an API call to the communication module <NUM> to initiate the SIM authentication procedure.

During the SIM authentication procedure, the communication module <NUM> supplies the challenge (RAND) to the SIM 102b at step <NUM> e.g. by executing the Authenticate APDU command received at step <NUM>.

At step <NUM>, the SIM 102b retrieves the shared key Ki from the non-volatile data store <NUM> and generates a signed response (SRES) using a first authentication algorithm (e.g. A3 encryption algorithm) that takes the shared key Ki and challenge (RAND) as inputs, and a cipher key (Kc) using a second authentication algorithm (e.g. A8 encryption algorithm) that also takes the shared key Ki and challenge (RAND) as inputs. The SIM 102b supplies the signed response (SRES) and cipher key (Kc) to the communication module <NUM>.

At step <NUM>, the communication module <NUM> supplies the signed response (SRES) and cipher key (Kc) to the agent <NUM> in an authentication response.

At step <NUM>, the agent <NUM> derives the pre-shared key (PSK) in the same manner as in step <NUM> (implemented by the OTA server).

Thus at the end of the process <NUM> both the agent <NUM> and OTA server <NUM> have derived the TLS encryption key (PSK). The pre-shared key (PSK) is used to encrypt/decrypt the communication packets transmitted between the agent <NUM> and OTA server <NUM> as described in more detail below with reference to <FIG>.

<FIG> illustrates a process <NUM> of a SIM update procedure which is performed once the pre-shared key derivation procedure <NUM> has completed.

Prior to step <NUM>, the agent <NUM> opens a TLS channel with the OTA server <NUM>. The opening of a TLS channel is referred to in the art as a "TLS Handshake" and is described in RFC <NUM>. During the TLS Handshake a series of messages are exchanged between the agent <NUM> and the OTA server <NUM>. These messages are known in the art and therefore are not described in detail herein. During the TLS Handshake procedure, the agent <NUM> informs the OTA server <NUM> of the key (the pre-shared key (PSK)) to be used for encrypting/decrypting the communication packets transmitted between the agent <NUM> and OTA server <NUM>. In particular, the agent <NUM> transmits a message (e.g. a "Client Key Exchange" message), including the agent identifier as the "PSK identity", to the OTA server <NUM>. In response, the OTA server <NUM> queries its associated memory <NUM> using the agent identifier and retrieves the pre-shared key (PSK) stored in association with the agent identifier.

The host device 102a may comprise a TLS/PSK software module. The agent <NUM> may comprise the TLS/PSK software module (part of the functionality of the agent <NUM>) or alternatively the TLS/PSK software module may be a separate module to the agent <NUM> and comprise program code sored in memory <NUM> that performs specified tasks when executed on processor <NUM>.

The agent <NUM> supplies the derived PSK to the TLS/PSK software module. The TLS/PSK software module is configured to derive session keys from the PSK that are used by the TLS/PSK software module of agent <NUM> for the encryption of data transmitted from the agent <NUM> to the OTA server <NUM>, and the decryption of data sent to the agent from the OTA server <NUM>. The TLS/PSK module on the host device 102a is responsible for decrypting the HTTP messages and handing them over to the agent <NUM>.

The operation of the TLS/PSK software module is known to persons skilled in the art and is documented in RFC <NUM> and in RFC <NUM>. Generally, the TLS/PSK software module derives a "pre-master secret" from the PSK (this is described in RFC <NUM> - Section <NUM>). The pre-master secret is encrypted and exchanged in the TLS handshake. The "pre-master secret" is used to derive a "master secret" (this is described in RFC <NUM> - Section <NUM>). The TLS/PSK software module passes the master key and other pieces of data from the handshake into a pseudo-random function (PRF) to generate the session keys (this is described in RFC <NUM> - Sections <NUM> and <NUM>).

The session keys comprise a "client write encryption key" used by the TLS/PSK software module of agent <NUM> for the encryption of data transmitted from the agent <NUM> to the OTA server <NUM> (and used by the the TLS/PSK software module of the OTA server <NUM> to decrypt data), and a "server write encryption key" used by the TLS/PSK software module of the OTA server <NUM> for the encryption of data transmitted from the OTA server <NUM> to the agent <NUM> (and used by the TLS/PSK software module of agent <NUM> to decrypt data). It will be appreciated from the above that these session keys are derived from the PSK.

The OTA server <NUM> may also comprise a TLS/PSK software module which is configured to derive the session keys in the same manner as the agent <NUM> described above.

At step <NUM>, the agent <NUM> transmits an update request message to the OTA server <NUM> via the TLS channel. The update request message comprises the agent identifier (generated by the agent <NUM> in procedure <NUM>) and may additionally comprise the SIM identifier associated with the SIM 102b. The update request message is encrypted using the pre-shared key (PSK) derived during procedure <NUM>. That is, the update request message is encrypted by the TLS/PSK software module of agent <NUM> with the session key (client write encryption key) that is derived from the PSK.

As shown in <FIG>, the update request message may be sent as a first HTTP request comprising the agent identifier as a parameter (conformingly to the SCP81 protocol). That is, the messages which are exchanged through the TLS channel may be wrapped in HTTP packets which are themselves encapsulated in TLS protocol packets.

In response to receiving the update request message, the OTA server <NUM> decrypts the update request message using the pre-shared key (PSK). That is, the TLS/PSK software module of the OTA server <NUM> decrypts the update request message with the session key (client write encryption key) that is derived from the PSK.

At step <NUM>, the OTA server <NUM> transmits an update response message to the agent <NUM> over the TLS channel. The update response message is encrypted using the pre-shared key (PSK) prior to transmission. That is, the update response message is encrypted by the TLS/PSK software module of the OTA server <NUM> with the session key (server write encryption key) that is derived from the PSK.

The update response message comprises update data. The update data may be stored in memory <NUM> and may be associated with the SIM 102b i.e. be pre-designated as being for delivery to the SIM 102b. The update data may comprise at least one envelope APDU. The at least one envelope APDU may comprise RFM and/or RAM commands to be executed by SIM 102b. The at least one envelope APDU is encrypted by the OTA server <NUM> using a symmetric OTA key and thus forms Secure Envelope APDU(s). The symmetric OTA key is installed on the SIM 102b at manufacture and provisioned on the OTA server <NUM>. The symmetric OTA key may correspond to the Ciphering Key Identifier (Klc) specified in standard ETSI TS <NUM><NUM>.

<FIG> illustrates an update response message <NUM>. As shown in <FIG>, the update response message <NUM> is encrypted using the session key (server write encryption key) <NUM> that is derived from the PSK. The update response message <NUM> comprises update data <NUM> which is encrypted by the OTA server <NUM> using a symmetric OTA key <NUM>.

Referring back to the process <NUM> shown in <FIG>, upon receiving the update response message the update response message is decrypted using the pre-shared key derived during procedure <NUM>. That is, the TLS/PSK software module of agent <NUM> decrypts the update response message with the session key (server write encryption key) that is derived from the PSK.

At step <NUM>, the agent <NUM> supplies the encrypted update data to the communication module <NUM>. At step <NUM>, the agent <NUM> may transmit an AT command to the communication module <NUM> to supply the encrypted update data to the communication module <NUM>. In particular, the AT+CSIM command may be used. An alternative way that step <NUM> can be achieved is by using an API provided by the communication module <NUM> such that the agent <NUM> can transmit an API call to the communication module <NUM> to supply the encrypted update data to the communication module <NUM>.

At step <NUM>, the communication module <NUM> supplies the encrypted update data to the SIM 102b.

In response to receiving the encrypted update data, the SIM 102b decrypts the encrypted update data using the symmetric OTA key <NUM> and at step <NUM> executes the update data to update the SIM 102b. The update performed on the SIM 102b based on the received update data may comprise installing new data onto the SIM 102b (e.g. installing a new application such as a Javacard applet), updating data previously installed on the SIM 102b, and/or modifying parameter values stored on the SIM 102b.

At step <NUM>, results of the execution of the update data are transmitted from the SIM 102b to the communication module <NUM>. At step <NUM>, the communication module <NUM> relays the execution results to the agent <NUM>.

At step <NUM>, the agent <NUM> transmits a further update request message over the network <NUM> to the OTA server <NUM>, the update request message conveys the results of the execution of the update data. As noted above, the update request message is encrypted using the pre-shared key (PSK) prior to transmission. That is, the update request message is encrypted with the session key (client write encryption key) that is derived from the PSK.

In response to receiving the further update request message from the agent <NUM>, the OTA server <NUM> is configured to determine if there is further update data to be sent to the agent <NUM>.

If there is further update data to be sent to the agent <NUM>, the process <NUM> proceeds back to step <NUM> (in the process <NUM>) where a further update response message is transmitted to the agent <NUM> over the TLS channel.

Collecting data (e.g. reading SIM parameters) may be performed in the process <NUM>. In particular, a first update response message transmitted by the OTA server <NUM> at step <NUM> may comprise a read command which is relayed to the SIM 102b for execution and thus the further update request message returned to the OTA server <NUM> at step <NUM> may comprise data read results (e.g. SIM parameter values). The data read results may be used by the OTA server <NUM> in determining update data to be transmitted in a further update response message transmitted by the OTA server <NUM> to the agent <NUM> when the process <NUM> loops backs to step <NUM>.

If there is no further update data to be sent to the agent <NUM>, the process <NUM> proceeds to step <NUM> where a message is transmitted from the OTA server <NUM> to the agent <NUM> indicating that there is no further update data. The message transmitted at step <NUM> may be a blank HTTP response (e.g. HTTP response code <NUM>).

Upon receiving the message indicating that there is no further update data, the communication session can be successfully terminated.

It can be seen from the processes <NUM> and <NUM> described above that the agent <NUM> provides support for an HTTP OTA mechanism in legacy SIM-enabled communication modules (even in <NUM> modules), and provides HTTP OTA without the need for SMS support on the host device 102a.

The APDUs can potentially be examined using a SIM communication logging device (tracer) inspecting the mobile station 102a. Therefore to address this, as noted above, the update data APDUs are wrapped in Secure Envelope APDUs, in the same way as in SMS OTA protocol (SCP80). The SMS OTA keys are only known by the OTA server <NUM> and the SIM 102b and therefore the RFM/RAM messages are protected from end to end to provide secure transmission of the update data to the SIM 102b. Moreover, since the endpoint of the HTTPS Tunnel is the agent <NUM> instead of the SIM 102b, the APDUs are considered to be provided externally for execution and therefore would not be executed successfully without a proper authorization system. The fact of wrapping inside of secure envelopes provides for this required authorization.

The communication protocol with the OTA Server <NUM> described above with reference to <FIG> and <FIG> differs from the SCP <NUM> protocol (described above) in that the handling of HTTP over TLS is delegated to the software agent <NUM> on the host device 102a and the SIM 102b is used as secure element to derive the TLS encryption key (PSK).

In embodiments described herein, the time taken for an OTA update can be reduced because the host hardware (e.g. processing and/or memory resources) on the mobile station 102a is typically more resource rich compared to SIM hardware. For example, to process HTTPS messages is computationally intensive and the hardware available on the host device provides faster processing of these communications.

Claim 1:
A method performed by an agent (<NUM>) on a device (102a), the method comprising:
receiving a random value from a server (<NUM>) over a network (<NUM>);
transmitting the random value to a subscriber identity module (102b), SIM, on the device via a communication module;
receiving a signed response from the SIM via the communication module wherein the signed response is generated using the random value, and receiving a cipher key from the SIM; deriving a pre-shared key using at least one of the signed response and the cipher key;
receiving a message over the network from the server, wherein the message is encrypted using the pre-shared key;
decrypting the message using the derived pre-shared key; and
transmitting data included in the decrypted message to the SIM via the communication module.