Managing Secure Element

Abstract

A method for transmitting configuration data for a secure element is provided. The configuration data is generated in a secure element manager, and the method includes: protecting the configuration data using a set of over-the-air (OTA) keys associated with the secure element; and transmitting the configuration data using a second interface to a second server, the second server being configured to transmit the configuration data via a non-SMS communication channel. A communication network corresponding to the method is also provided. A method for receiving configuration data for a secure element at a host device is also provided. The method includes: receiving the configuration data using a data function for receiving the configuration data via a non-SMS communication channel; processing the configuration data using a SIM application toolkit; and forwarding the processed configuration data to the secure element. A host device according to the method is also provided.

Description

Technical Field

[0001] The present invention relates to telecommunications and, in particular, to transmitting and receiving configuration data for secure elements. Background Art

[0002] A host device including a universal integrated circuit card (UICC) or an embedded universal integrated circuit card (eUICC) can be used to provide communication services through the mobile network infrastructure of a mobile network operator (MNO) or a mobile virtual network operator (MVNO), or to provide other suitable services to the host device including the UICC or eUICC. To provide such services, the network operator can provide content such as configuration data such as the International Mobile Subscriber Identity (IMSI) to the UICC or eUICC. This content can be managed and updated via over-the-air (OTA) methods. OTA technology can be used to communicate with and manage the UICC or eUICC without physically connecting to the card.

[0003] OTA-based methods may use an OTA platform that utilizes Remote Application Management (RAM) and / or Remote File Management (RFM) protocols, and may use short message service (SMS) or push notification services to manage the UICC or eUICC. Therefore, network operators resorting to OTA-based methods may face high implementation costs due to the associated infrastructure.

[0004] Furthermore, the OTA-based approach only works when the UICC or eUICC is attached to a network, in particular to an operator's network, that is, the host device including the UICC or eUICC has network coverage.

[0005] Therefore, it is desirable to provide an alternative to the traditional OTA-based approach to performing UICC or eUICC content management and updates. Summary of the Invention

[0006] According to a first aspect of the present disclosure, there is provided a method for transmitting configuration data of a secure element for reception by a host device comprising the secure element, the configuration data being generated in a secure element manager in a cellular communication network, the secure element manager comprising:

[0007] a first interface to a first server for transmitting configuration data to the host device via a Short Message Service (SMS) communication channel; and

[0008] a second interface to a second server, the second server being configured to transmit configuration data to the host device via a non-SMS communication channel, the non-SMS communication channel being protected using an encryption key associated with the secure element using an encryption protocol, the method comprising:

[0009] protecting the configuration data using a set of one or more over-the-air (OTA) keys associated with the secure element to generate configuration data for the secure element; and

[0010] The configuration data is transmitted using the second interface.

[0011] This can allow configuration data for a secure element (e.g., IMSI or other configuration data) to be transferred to the secure element even in situations where the secure element and the host device do not have cellular coverage as would typically be provided by an OTA server. In this way, when a host device is unable to receive an SMS message including the configuration data for the secure element, the host device can receive the configuration data over a secure communication channel over an alternative bearer such as Wi-Fi.

[0012] According to a second aspect of the present disclosure, there is provided a method for receiving configuration data of a secure element from a cellular communication network at a host device, the host device comprising:

[0013] the security element;

[0014] a first data function for receiving configuration data from the cellular network via an SMS communication channel; and

[0015] a second data function for receiving configuration data from the cellular network via a non-SMS communication channel, the non-SMS communication channel being protected using an encryption key associated with the secure element using an encryption protocol, the method comprising:

[0016] receiving configuration data using the second interface;

[0017] processing the configuration data using a Subscriber Identity Module Application Toolkit (SAT); and

[0018] The processed configuration data is forwarded to the secure element.

[0019] In this way, configuration data can be received by a host device for a secure element and forwarded to the secure element for processing, even in situations where the host device does not have cellular network coverage and / or the secure element does not generally support receiving configuration data over an alternative bearer such as Wi-Fi.

[0020] According to a third aspect of the present invention, there is provided a cellular communication network for transmitting configuration data of a secure element to a host device including the secure element, the network comprising:

[0021] a first server configured to transmit configuration data to the host device via an SMS communication channel; and

[0022] a second server for transmitting configuration data to the host device via a non-SMS communication channel, the non-SMS communication channel being protected using an encryption key associated with the secure element using an encryption protocol,

[0023] wherein the cellular communications network is configured to:

[0024] protecting the configuration data using a set of one or more OTA keys associated with the secure element to generate configuration data for the secure element; and

[0025] The configuration data is transmitted using the second server.

[0026] According to a fourth aspect of the present invention, a host device is provided, the host device comprising:

[0027] security element;

[0028] a first data function for receiving configuration data for the secure element from a cellular network via an SMS communication channel; and

[0029] a second data function for receiving configuration data for the secure element from the cellular network over a non-SMS communication channel, the non-SMS communication channel being protected using an encryption key associated with the secure element using an encryption protocol,

[0030] wherein the host device is configured to:

[0031] receiving configuration data using the second interface;

[0032] Processing the configuration data using the SAT; and

[0033] The processed configuration data is forwarded to the secure element.

[0034] According to a fifth embodiment, there is provided a method of transmitting configuration data of a secure element for reception by a host device comprising the secure element, the configuration data being generated in a secure element manager in a cellular communication network, the method comprising:

[0035] generating configuration data for the secure element using a set of one or more over-the-air (OTA) keys associated with the secure element to protect the configuration data; and

[0036] The configuration data is transmitted via a communication channel secured using an encryption key associated with the secure element in addition to the one or more OTA keys.

[0037] According to a sixth embodiment, there is provided a method of receiving configuration data of a secure element from a cellular communication network, the method comprising:

[0038] receiving configuration data via a communication channel protected using an encryption key associated with the secure element in addition to one or more OTA keys associated with the secure element, the configuration data being protected using the set of one or more OTA keys;

[0039] The configuration data is forwarded to the secure element.

[0040] Further features and advantages of the present disclosure will become apparent from the following description of preferred embodiments, given by way of example only, with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] The following drawings are for illustration purposes and are given by way of example only. Embodiments will be understood from the following detailed description with reference to the accompanying drawings, in which:

[0042] Figure 1 is a schematic diagram illustrating elements of a cellular communication network and a host device according to an example;

[0043] Figure 2 is a flowchart illustrating a method according to an example;

[0044] Figure 3 is a schematic diagram illustrating elements of a cellular communication network and a host device involved in an encryption protocol according to an example;

[0045] Figure 4 is a flowchart illustrating a method according to an example; and

[0046] Figure 5 is a schematic diagram illustrating elements of a cellular communication network and a host device according to an example. DETAILED DESCRIPTION

[0047] Certain examples described herein provide methods for transmitting configuration data to a secure element. The secure element may be a UICC or an eUICC. The configuration data may be received by a host device including the secure element, processed, and forwarded to the secure element. The secure element may then process the configuration data and / or use the configuration data to configure the secure element, for example, by updating a configuration file of the secure element. In this context, the host device may be any suitable computing device including a secure element such as a UICC or an eUICC. In some examples, the host device includes a mobile computing device and / or a desktop computing device. In other examples, the host device includes any computing device or object with network connectivity. For example, appliances, autonomous vehicles, and other devices that can connect to a mobile network. The host device may include at least one processor and at least one memory. The at least one memory may include a combination of volatile and non-volatile memory. Instructions may be stored on at least one of the memories that, when executed by the at least one processor, cause the processor to perform the methods described herein. The host device may include mobile or stationary consumer devices, machines, and / or objects in the context of IoT and M2M.

[0048] Configuration data can be transmitted over a secure communication channel between the carrier network and the host device. The secure communication channel can be operable even when the host device does not have a cellular connection to the network. The secure communication channel can be protected using an encryption key associated with a secure element.

[0049] Figure 1 is a schematic diagram illustrating an example cellular communication network 100 and a host device 150. Cellular communication network 100 may also be referred to as a carrier network. Cellular communication network 100 may be used to transmit configuration data for a secure element to host device 150 including the secure element. The configuration data may include data that may be used to configure the secure element. In some examples, the configuration data includes data for updating firmware and / or software included in the secure element. In other examples, the configuration data may be used to configure the secure element so that the secure element can be used to connect to network 100 or other networks to provide communication services to host device 150.

[0050] The cellular communication network 100 includes a first server 110. The first server 110 is configured to transmit configuration data to the host device 150 via a short message service communication channel, such as Figure 1 The first server 110 may be referred to as an OTA server. The functionality of the OTA server is described in detail in International Patent Application Publication No. WO2011 / 036484A2, the disclosure of which is hereby incorporated by reference.

[0051] The OTA server may include an OTA gateway that converts the requests into SMS and sends them to an SMS center (SMSC), which can transmit them on-site to one or more SIM cards. The OTA server may include an SMSC or be communicatively coupled to an SMSC. The OTA server may also generate service requests indicating which cards are to be updated / modified / activated and may send these requests to the OTA gateway.

[0052] The cellular communication network 100 includes a second server 120 for transmitting configuration data to the host device via a non-SMS communication channel 125. The non-SMS communication channel 125 is protected using an encryption key associated with a secure element using an encryption protocol. The non-SMS communication channel can use any suitable bearer, such as Wi-Fi.

[0053] In an example, the second server 120 includes a rights configuration server. The rights configuration server may be arranged to transmit rights configuration data to the host device. An example of a rights configuration server is described in GSMA TS.43 VoWiFi and VoLTE Rights Configuration v2.0, published on October 4, 2018, which is hereby incorporated by reference. As described in GSMA TS.43 VoWiFi and VoLTE Rights Configuration v2.0 (referred to herein as GSMA TS.43), the rights configuration server may use an authentication mechanism such as EAP-AKA. However, other authentication methods and standards may also be used without departing from the scope of this disclosure.

[0054] exist Figure 1 In the example shown, the second server 120 is communicatively coupled to the authentication center 130, however, in other examples, the second server 120 may include the authentication center. Figure 3 Discuss the establishment of communication channels.

[0055] The cellular communication network 100 is configured to protect configuration data using a set of one or more OTA keys 145 associated with the secure element to generate configuration data for the secure element. The cellular communication network 100 may also be configured to transmit the configuration data using a second server 120. The configuration data may be transmitted by the second server 120 for receipt by the host device 150. That is, the configuration data may be sent to the host device 150 including the secure element via a communication channel 125. In this way, even if the host device does not have a cellular connection to the cellular communication network 100, the configuration data of the secure element may be transmitted to the host device 150, for example, via an OTA server, for use in configuring the secure element. This may allow the secure element configuration data to be sent to the device via an alternative channel using machine-to-machine (M2M) communication, such as via the Internet of Things (IoT), or other internet-based communication channels. In this way, the host device 150 may not be connected to the network but may still receive updated configuration information and / or profile configuration information for the secure element via an alternative channel.

[0056] exist Figure 1 In the illustrated example, the cellular communication network 100 includes a secure element manager 140. The secure element manager 140 can be communicatively coupled to the first server 110 and the second server 120 via a first interface and a second interface, respectively. The first interface and the second interface can each be implemented as any suitable combination of hardware components and software components. The secure element manager can be used to monitor and / or manage the profiles of network users. In some examples, the functions of the secure element manager 140 include monitoring the ISMI assigned to the secure element and / or generating data to be sent to the secure element, including configuration data, such as an IMSI. An example of a secure element manager 140 is described in WO2011 / 036484 A2, in which the secure element manager is referred to as an IMSI broker. However, when compared to the IMSI broker described in WO2011 / 036484 A2, the secure element 140 of the present disclosure may have additional functions.

[0057] In some examples, configuration data for a secure element can be generated at secure element manager 140. Secure element manager 140 can communicate with OTA server 110 to obtain an OTA key that can be used to protect configuration data to be sent to host device 150. The OTA key can be obtained from the OTA server and used by the secure element to ensure that the configuration data used to configure and / or modify the secure element is received from an authorized source. This can prevent a network that is not authorized to configure the secure element from configuring the secure element.

[0058] Cellular communication network 100 may also be configured to transmit configuration data using a second server. This may include, for example, secure element manager 140 forwarding the configuration data to first server 120 using a first interface for transmission by second server 120. Second server 120 may transmit the configuration data via a non-SMS communication channel for receipt by host device 150.

[0059] Figure 1 Also shown is a host device 150. Host device 150 includes a secure element 160. The secure element may be a UICC or an eUICC. Secure element 160 may include a set of one or more OTA keys 145. OTA keys 145 may be known to network 100; for example, OTA keys 145 may be pre-established between network 100 and secure element 160. OTA keys 145 may be updated, for example, via a suitable OTA method to maintain security.

[0060] Host device 150 may include a first data function for receiving configuration data for a secure element from a cellular network (e.g., cellular network 100) via an SMS communication channel. The SMS communication channel may be established between an OTA server (e.g., server 110) and host device 150. Host device 150 may also include a second data function for receiving configuration data for a secure element from cellular network 100 via a non-SMS communication channel, the non-SMS communication channel being protected using an encryption key associated with the secure element using an encryption protocol. The second data function may, for example, receive configuration data from a second server 120. Second server 120 may be configured to communicate with host device 150 via an Internet Protocol communication channel, such as WiFi. Other examples of suitable bearers for communication channel 125 include Bluetooth, near field communication (NFC), infrared, or any other suitable bearer. The first data function and the second data function of the host device 150 may include separate hardware components for receiving data, however, in some implementations, the first data function and the second data function may be virtualized or software-based data functions that interact with at least some shared hardware in the host device 150 for receiving data via a suitable bearer.

[0061] Figure 1 The exemplary host device 150 shown includes a client module 170. The client module 170 can be configured to establish a communication channel 125 with the second server 120. The host device 150 can also include an inbound message queue 180, as will be discussed later with respect to more specific examples of the present disclosure. The inbound message queue 180 can be part of the client module 170. The host device 150 includes a SAT module 190 that can be used to process received configuration data.

[0062] Host device 150 can be configured to receive configuration data using a second data function. This can include receiving the configuration data in packets at client module 170. In some examples, client module 170 can form at least a part of the second data function. The configuration data can be forwarded from client module 170 to inbound message queue 180. In some examples, inbound message queue 180 can also be considered part of the second data function.

[0063] The host device 150 is configured to process the configuration data using the SAT 190. The SAT 190 can be used to package the received configuration data into a SIM toolkit packet for processing by the secure element 160. In this way, the secure element 160 does not need to be configured to process data received via an alternative bearer (e.g., via the communication channel 125). This can achieve interoperability with a secure element that does not have the ability to process data packaged and delivered via the communication channel 125 (e.g., a non-SMS communication channel). This ensures interoperability between the first server 120 and the host device (including the secure element) receiving the configuration data, regardless of the operating system functionality of the secure element. The host device 150 can then be configured to forward the processed configuration data to the secure element 160.

[0064] Figure 2 1 is a flow chart illustrating a method 200 for transmitting configuration data of a secure element for reception by a host device including a secure element. The configuration data is generated in a secure element manager 140 in a cellular communication network 100. The secure element manager 140 includes a first interface to a first server 110 for transmitting the configuration data to a host device 150 via an SMS communication channel. The secure element manager 140 includes a second interface to a second server 120 for transmitting the configuration data to the host device via a non-SMS communication channel 125, the non-SMS communication channel 125 being protected using an encryption key associated with a secure element 160 using an encryption key protocol.

[0065] At block 210, method 200 includes protecting configuration data using a set of one or more OTA keys 145 associated with a secure element 160 to generate configuration data for the secure element 160. The OTA keys 145 are used to perform cryptographic checksums and / or may be used as digital signatures to ensure that any configuration data used to configure the secure element is received from an authorized network.

[0066] At block 220 , the method includes transmitting the configuration data using the second interface. In this manner, the configuration data may be sent via a non-SMS communication channel for receipt by the host device 150 , such that the configuration data may still be provided to the secure element even when the host device does not have cellular coverage.

[0067] In some examples, the first server 110 includes an OTA gateway for sending SMS communications to an SMS center for transmission via an SMS communication channel. The configuration data may be in an application protocol data unit (APDU) format. This allows the configuration data to be implemented on the secure element 160 after the host device 150 receives the configuration data. The configuration data in APDU format can be transmitted in packets using the second server 120 (e.g., using packet switching). The configuration data can be packaged in a suitable transport wrapper before being transmitted by the second server 120. In some examples, the configuration data can be packaged in a suitable transport wrapper before being transmitted using the second interface. In other examples, the configuration data can be packaged in a suitable transport wrapper at the second server 120 before being transmitted.

[0068] As mentioned above about Figure 1 As discussed, the second server 120 may comprise a rights configuration server. The rights configuration server may be arranged to transmit rights configuration data to the host device using a non-SMS communication channel.

[0069] Figure 3 Some of the elements involved in establishing a communication channel 125 using an encryption protocol are shown schematically. Figure 3 A cellular communication network 100 is shown including a second server 120 communicatively coupled to an authentication center 130. In some examples, the second server 120 may include a rights configuration server as described above. The second server may also include the authentication center 130. In some examples, the encryption protocol may include EAP-AKA authentication, as further described in "Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA) RFC 4187," published by the Internet Engineering Task Force (IETF) in January 2006, the disclosure of which is hereby incorporated by reference. The authentication center 130 includes an encryption key 300 associated with a secure element. The encryption key 300 may be pre-agreed between the cellular communication network 300 and the secure element 160. Figure 3 Also shown is a host device 150, which includes a secure element 160 and a client module 170, wherein the secure element 160 includes an encryption key 300. The encryption key 300 can be used to establish a secure communication channel between the cellular communication network 100 and the host device 150. Certificate exchange can be performed between the authentication center 130 by the second server 120 communicating with the client module 170 included in the host device 150.

[0070] Returning to the above method 200, the method 200 may further include: using the second server 120 to receive a read receipt indicating that the configuration data has been received by the host device 150. In this way, if the host device 150 does not successfully receive the configuration data, the cellular communication network 100 may retransmit the configuration data.

[0071] Cellular communication network 100 may also be configured to perform a check of available settings that can be used to configure secure element 160. Method 200 may include identifying information stored in cellular communication network 100 for configuring a secure element, and using the identified information to generate configuration data. For example, secure element manager 140 may identify information such as an IMSI, available software, and / or firmware for secure element 160. Secure element manager 140 may then generate configuration data for secure element 160 based on the identified information.

[0072] Checking for configuration data may be triggered by host device 150 and / or secure element 160. For example, method 200 may include receiving, via a second server, a request for configuration data from host device 150. Identifying information stored in cellular communication network 100 may be performed in response to the request for configuration data.

[0073] Figure 4 A flow chart of a method 400 for receiving configuration data for a secure element 160 from a cellular communication network 100 at a host device 150 is shown. The host device 150 includes a first data function, a second data function, and a secure element. The first data function is configured to receive configuration data from the cellular network 100 via an SMS communication channel. The second data function is configured to receive configuration data from the cellular network 100 via a non-SMS communication channel, the non-SMS communication channel being protected using an encryption key 300 associated with the secure element 160 using an encryption protocol.

[0074] At block 410, method 400 includes receiving configuration data using a second data function. The second data function may include any suitable combination of hardware and software. In some examples, the second data function shares at least some hardware and / or software with the first interface data function. The second data function may include, for example, a receiving antenna, a client module 170, an inbound message queue 180, or any other suitable hardware or software component. Receiving the configuration data using the second data function may include receiving the configuration data using the client module 170 and queuing the configuration data at the inbound message queue 180.

[0075] At block 420, method 400 includes processing the configuration data using SAT 190. Processing the configuration data using SAT 190 may allow secure element 160 to process the configuration data regardless of the ability of the secure element's 160 operating system to support communication using non-SMS communication protocols for transmitting OTA messages and configuration data. This enables interoperability between an authorized configuration server transmitting the data and a host device receiving the transmitted configuration data.

[0076] Processing the configuration data may include setting an origination address for the configuration data corresponding to cellular communication network 100. In the event that the configuration data is received in packets, host device 150 may queue the packets at inbound message queue 180. Processing of the configuration data may be performed before or concurrently with the queuing of the configuration data at inbound message queue 180.

[0077] At block 430, method 400 includes forwarding the processed configuration data to secure element 160. For example, method 400 may include forwarding the configuration data in the SIM toolkit packet to secure element 160. This may be performed using any suitable means for communicating between the host device 150 operating system and secure element 160. Alternatively, media located on a baseband assembly of host device 150 may be used to forward the configuration data to secure element 160. In other examples, media located on secure element 160 itself may be used.

[0078] In this way, configuration data can be delivered to secure element 160 via a non-SMS communication channel protected using an encryption protocol, such that host device 150 can receive configuration data even when the host device lacks cellular connectivity or when the host device is roaming and cannot successfully connect to a network, as may be the case in a low coverage area.

[0079] In some examples, the configuration data is in APDU format. This is a format suitable for processing by the security element 160 and similarly implementing the instructions indicated therein. In some examples, the processed configuration data is further processed by the security element using a remote file management applet. This allows the security element to reconfigure itself based on the configuration data. Being able to process configuration data in this way can provide interoperability between the security element and the cellular operator network that transmits the configuration, as described herein.

[0080] As discussed above, the host device may initiate the process of transferring configuration data. For example, method 400 may include querying the network for available configuration data using a second data function. Secure element 160 may request host device 150 to open an HTTP channel to a server (e.g., second server 120) on cellular communication network 100. An HTTP request may then be sent to check for available content on cellular communication network 100.

[0081] When configuration data is received at the secure element, the configuration data can be processed using a set of one or more OTA keys 145 associated with the secure element. The set of OTA keys 145 corresponds to the OTA keys 145 that can be used to protect the configuration data. In this way, the secure element 160 is less susceptible to implementing configuration data from an unsecure or fraudulent source.

[0082] In some examples, the method may include generating proof of receipt of the configuration data and transmitting the proof of receipt to the cellular communication network 100 using the second data function. In the case where the configuration data is forwarded to the secure element 160 with an origination address set, once all configuration data has been received, a synchronization callback to the cellular communication network may be performed, and proof of receipt addressed to the previously set origination address may be generated and transmitted.

[0083] Figure 5 A simplified diagram of the elements involved in generating and transmitting a proof of receipt is schematically shown. After the configuration data is successfully received at the safety element 160, a proof of receipt is generated. The proof of receipt can be generated and transmitted to the cellular communication network using a second data function on the host device, for example, via a non-SMS communication channel. The safety element 160 can generate an SMS message queued at the SMS queue 500. The proof of receipt in the form of an SMS message can be forwarded to the outbound message queue 510 before being transmitted so as to be received by the cellular network. In the case where the proof of receipt is generated in the form of an SMS message, the proof of receipt can be processed so that it can be sent via a non-SMS communication channel. This allows the safety element 160 to provide proof of receipt even if the safety element 160 is not operable to generate and / or use a non-SMS communication channel to transmit a message.

[0084] In an example, a method for transmitting configuration data of a security element for reception by a host device including a security element is provided. As described above, the configuration data is generated in a security element manager in a cellular communication network. The method comprises: using a set of one or more over-the-air (OTA) keys associated with the security element to protect the configuration data to generate the configuration data of the security element. The method further comprises: transmitting the configuration data through a communication channel protected by an encryption key associated with the security element in addition to the one or more OTA keys. As discussed above, a secure communication channel can be established between an authority configuration server and a host device. In some examples, the configuration data can be in APDU format. The secure communication channel can be protected using Extensible Authentication Protocol Authentication and Key Agreement (EAP-AKA) as described above.

[0085] In an example, a method for receiving configuration data for a secure element from a cellular communication network is provided. The method includes receiving the configuration data via a communication channel protected by an encryption key associated with the secure element in addition to one or more OTA keys associated with the secure element, the configuration data being protected using a set of the one or more OTA keys. The method also includes forwarding the configuration data to the secure element. In some examples, the configuration data may be in APDU format. This may allow the data to be processed by the secure element. In some examples, the communication channel is protected using EAP-AKA, as described above.

[0086] The above embodiments should be understood as illustrative examples of the present disclosure. Additional embodiments are contemplated. It should be understood that any feature described with respect to any one embodiment may be used alone or in combination with other features described, and may also be used in combination with one or more features of any other embodiment or any combination of any other embodiments. Furthermore, equivalents and modifications not described above may also be employed without departing from the scope of the present disclosure as defined in the appended claims.

Claims

1. A method of transmitting configuration data associated with a cellular communication network to a host device including a secure element, the method comprising: receiving, by a secure element manager in the cellular communication network, from a first server in the cellular communication network, one or more over-the-air (OTA) keys associated with the secure element, the keys usable by the secure element to authorize a source of the configuration data, wherein the first server is configured to maintain the OTA keys and to send the configuration data to the host device using OTA-based short message service (SMS) communication; protecting, by the secure element manager, the configuration data using the received one or more over-the-air (OTA) keys associated with the secure element to generate OTA protected configuration data for the secure element, thereby providing a first layer of encryption of the configuration data; Providing, by the secure element manager, the generated OTA security configuration data to a second server in the cellular communication network; establishing, by the second server, a non-SMS communication channel with the host device and encrypting the received OTA protected configuration data using one or more encryption keys associated with the secure element and different from the one or more OTA keys, thereby providing multi-layered encrypted configuration data; and The multi-layer encrypted configuration data is transmitted by the second server to the host device using the non-SMS communication channel.

2. The method of claim 1, wherein the first server comprises an OTA gateway for sending SMS communications to an SMS center for transmission over an SMS communication channel.

3. A method according to claim 1 or claim 2, wherein the configuration data is in Application Protocol Data Unit (APDU) format.

4. A method according to claim 1 or claim 2, wherein the second server comprises a rights configuration server arranged to transmit authorisation configuration data to the host device using the non-SMS communication channel.

5. The method according to claim 1 or claim 2, comprising: A read receipt is received by the second server indicating that the configuration data has been received by the host device.

6. The method according to claim 1 or claim 2, wherein the method comprises: Information stored in the cellular communication network for configuring the secure element is identified, and wherein the configuration data is generated using the identified information.

7. The method according to claim 6, wherein the method comprises: A request for configuration data is received from the host device by the second server, and identifying information stored in the cellular communication network for configuring the secure element is performed in response to the request for configuration data.

8. A method of receiving configuration data by a host device including a secure element operatively connected to a subscriber identity module application toolkit (SAT), the method comprising: receiving the configuration data from the cellular communication network via a non-SMS communication channel between the host device and the cellular communication network, the non-SMS communication channel being protected by a cryptographic protocol using one or more cryptographic keys associated with the secure element, wherein the configuration data is multi-layered encrypted data, including: a first encryption layer obtained by using one or more over-the-air (OTA) keys associated with the secure element and usable by the secure element to authorize a source of the configuration data, thereby producing OTA-protected configuration data; and a second encryption layer obtained by encrypting the generated OTA protected configuration data using one or more encryption keys associated with the secure element and different from the one or more OTA keys; processing the received configuration data using the SAT to decode it into OTA protected configuration data using the one or more encryption keys; and The OTA protected configuration data is forwarded to the secure element for further decoding using the one or more OTA keys to authorize the source of the configuration data.

9. The method of claim 8, wherein the configuration data is in APDU format.

10. The method of claim 8 or claim 9, wherein the processed configuration data is further processed by the secure element using a remote file management applet.

11. The method according to claim 8 or claim 9, wherein the method comprises: Use queries the network for available configuration data.

12. The method according to claim 8 or claim 9, wherein the method comprises: Proof of receipt of the configuration data is generated and transmitted to the cellular communication network using a second data function.

13. A cellular communication network for transmitting configuration data to a host device including a secure element, the network comprising a secure element manager operatively connected to a first server and a second server, wherein: The first server is configured to maintain over-the-air (OTA) keys and transmit configuration data to the host device via an SMS communication channel; the secure element manager being configured to receive one or more OTA keys associated with the secure element from the first server, encrypt the configuration data using the one or more OTA keys to generate OTA-protected configuration data for the secure element, and provide the generated OTA-protected configuration data to the second server; The second server is configured to: establishing a non-SMS communication channel with the host device; receiving the OTA protected configuration data from the secure element manager; encrypting the received OTA protected configuration data using one or more encryption keys associated with the secure element, thereby providing a second encryption layer and generating multi-layered encrypted configuration data, wherein the one or more encryption keys are different from the one or more OTA keys; and The resulting multi-layer encrypted configuration data is transmitted to the host device via the non-SMS communication channel.

14. A cellular communication network according to claim 13, wherein the second server comprises a rights configuration server arranged to transmit rights configuration data to the host device.

15. A host device comprising: A secure element operatively connected to a subscriber identity module application toolkit (SAT), wherein The host device is configured to receive configuration data for the secure element from a cellular network via a non-SMS communication channel, The received configuration data is multi-layer encrypted configuration data, having: a first encryption layer provided using one or more over-the-air (OTA) keys associated with the secure element and usable by the secure element to authorize the source of the configuration data, thereby generating OTA-protected configuration data, and a second encryption layer provided by encrypting the provided OTA protected configuration data using one or more encryption keys associated with the secure element, and wherein the one or more OTA keys are different from the one or more encryption keys; the SAT being configured to process the received multi-layer encrypted configuration data to decode the second encryption layer into OTA protected configuration data using the one or more encryption keys, and forward the resulting OTA protected configuration data to the secure element; and The secure element is configured to use the one or more OTA keys to decode OTA-protected configuration data received from the SAT, thereby authorizing a source of the configuration data.

Images