Patent Description:
Recently, mobile devices configured to employ electronic subscriber profiles for communicating on mobile networks have emerged. Such mobile devices are typically equipped with smart cards containing electronic/embedded Secure Elements (SE), such as electronic/embedded universal integrated circuit cards (eUICCs), smartSD, or smart microSD, to name a few.

A secure element is a tamper resistant element, TRE, that provides a secure memory and execution environment within a smart card/device in which application code and application data can be securely stored and administered. The secure element ensures that access to the data stored on the card is provided only when authorized.

A secure element designed to be used in telecommunication products, such as mobile devices, is configured to store one or more electronic subscriber profiles, in particular electronic/embedded subscriber identification module (eSIM) profiles, that may allow mobile devices to connect to one or more mobile networks. A subscriber profile (e.g., eSIM profile) may be generated by a mobile network operator (MNO) and may be downloaded to a mobile network device. The subscriber profile may then be installed on the secure element of the mobile device and used for communication over a corresponding mobile network by the mobile device.

<FIG> shows a simplified representation of the architecture of a remote eSIM provisioning system as described in SGP. <NUM> RSP Technical Specification, Version <NUM>, issued by the GSM Association (in the following referred to as GSMA RSP <NUM>). The eSIM provisioning system <NUM> is organized around several elements: the SM-DP+ (Subscription Manager - Data Preparation and Secure Routing, <NUM>), the SM-DS (Subscription Manager - Discovery Server, <NUM>), the LPA (Local Profile Assistance, <NUM>) and the eUICC, <NUM>, the latter being part of a mobile device <NUM>, of an end user <NUM>.

The SM-DP+ <NUM> is responsible for the creation, download, remote management (enable, disable, update, delete) and the protection of subscriber profiles provided by the MNO <NUM>. In particular, the SM-DP+ <NUM> may be configured to provide a profile in a Bound Profile Package, and enable the Bound Profile Package to be securely transmitted.

The LPA (Local Profile Assistant, <NUM>) is a set of functions in the device <NUM> responsible for providing the capability to download (encrypted) profiles to the eUICC/TRE/SE <NUM>. It also presents the local management end user interface to the end user <NUM> so they can manage the status of profiles on the eUICC/TRE/SE <NUM>. The SM-DS <NUM> provides means for the SM-DP+ <NUM> to communicate with the eUICC/TRE/SE <NUM>.

Historically, the native implementation or the operating system of a TRE could not be updated once the TRE was deployed in the field, and hence, did not vary once the TRE has surpassed the production phase. This means that if any problem is found that is related to the software within it (new attacks or vulnerabilities, new updates on sector specification, the expected life cycle of the devices using it), the only possible action is to change the whole TRE. This makes it particularly difficult to keep up to date with the market needs in terms of production (with software updates after production being impossible), especially when the production is bound to be executed within a certified environment in the factory.

The GSMA remote provisioning architecture, depicted in <FIG>, provides a platform for implementing a procedure to load profiles onto a secure element (SE) or Tamper Resistant Element (TRE), which however allows merely for implementing a change in the data stored in the SE/TRE but not in the basic software present in the SE/TRE. The procedure requires several exchanges between the TRE and the server before it can prepare the Bound Profile Package used for the load, which might not be optimal for a broadcast deploy of a new piece of software. This scheme also lacks extra layers of protection which might be required for the deployment of critical data such as a new operating system.

<CIT> describes an eUICC profile management method and apparatus. When an operating system of an eUICC needs to be updated, an LPA sets an operating system update flag, and obtains and stores metadata of a first profile. A profile server generates a second profile based on the operating system update flag, generates metadata of the second profile. The LPA configures the metadata of the second profile based on the metadata of the first profile, and activates the second profile based on the configured metadata of the second profile, so that after completing upgrade of the operating system of the eUICC, a user can normally use an operator service without configuring a profile again, thereby simplifying a configuration process of the profile, and improving intention of the user to update the operating system of the eUICC and user experience.

<CIT> describes a firmware update system, comprising a loader module, an update agent, a secure loader manager, an update package reference, a setting service and a memory manager. The system facilitates the download of update packages and subsequent update of firmware/ software in mobile handsets. The secure loader manager may populate the update package reference with the appropriate information and flags, employing the setting service, after the successful download and verification of an update package. An update driver may be employed by the mobile handset to communicate information about a downloaded update package to the update agent for subsequent firmware update.

<CIT> describes a method of managing an object which is represented by a first instance of a class. The first instance is stored in a secure element comprising an initial operating system. The method comprises a step of updating the initial operating system to generate an updated operating system, a step of creating a metadata uniquely associated with the object, said metadata being permanently stored in the secure element and comprising a value of a parameter of said class which has been used to create said first instance. The method comprises a step of reinstantiating the object by generating an updated instance of the class in the updated operating system by using said value to set said parameter of the class, said updated instance representing the object. The reinstantiating step is automatically triggered by the step of updating the initial operating system.

<CIT> describes a device facilitating countersigning updates for multi-chip devices. The device includes at least one processor configured to receive, from a collocated chip, a data item and a software update, the data item being signed using a private key corresponding to a primary entity associated with the collocated chip and the data item comprising an authentication code generated using a symmetric key corresponding to a secondary entity associated with the software update. At least one processor is further configured to verify the data item using a public key associated with the primary entity. At least one processor is further configured to verify the software update based at least in part on the authentication code and using the symmetric key corresponding to the primary entity. At least one processor is further configured to install the software update when both the data item and the software update are verified, otherwise discard the software update.

<NPL>" describes a data structure for profile packages for eUICCs and the creation of a protected Bound Profile Package from an unprotected Profile Package for delivery to an eUICC by an SM-DP+.

It is therefore desirable to provide a solution for updating an operating system on a secure element, which addresses the above-mentioned drawbacks.

The present invention addresses the above object by the subject-matter covered by the independent claims.

According to a first aspect of the present invention, there is provided a method for downloading an operating system onto a secure element, the secure element comprising an update agent, which is configured to perform steps as follow. The update agent receives from an external device an installation package for installing an operating system onto the secure element. The update agent requests control of the secure element and loads the operating system received with the installation package into the secure element, after which control of the secure element is transferred to the operating system.

The proposed method provides an efficient and secure solution for loading trusted software, in particular an operating system, onto a secure element once the production of the secure element is finished. By equipping the update agent with the capability to control the secure element, the update agent is for some time in charge of the secure element, which does not have an own files system. This allows for an efficient and secure loading, updating, and replacing of software within the secure element.

According to the present invention, the installation package comprises a header part and a data-carrying part, wherein the header part comprises an initialize secure channel signature, and the data-carrying part comprises a plurality of image segments, wherein a sequence of consecutive image segments comprises a manifest, a manifest signature, and an image of the operating system to be loaded onto the secure element.

According to the present invention, receiving the installation package comprises receiving a first part of the installation package comprising the header and a first sequence of the plurality of image segments, the first sequence carrying the manifest signature and the manifest. The update agent is further configured, after it has received the first part of the installation package, to verify the initialize secure channel signature and the manifest signature comprised in the header, using a first key, in particular an Elliptical Curve Digital Signature, ECDSA, key, stored in the update agent.

This provides the update agent with a control mechanism to ensure both the trustworthiness of the installation package as well as of the transmission channel.

In some embodiments of the present invention, requesting control of the secure element comprises sending by the update agent to the external device a request to perform a system reset.

Preferably, after the system reset an initial operating system contained within the secure element is deleted, and control of the secure element is assumed by the update agent.

In some embodiments of the present invention, loading the operating system comprises receiving after the system reset the complete installation package from the external device, the complete installation package comprising the plurality of image segments, wherein the plurality of image segments carries the manifest, the manifest signature and the image of the operating system, each image segment being protected with a pair of image protection keys. After receiving the installation package, the update agent verifies integrity of the installation package, extracts the operating system from the corresponding image segments, and stores the operating system into a memory of the secure element.

Preferably, the image protection keys are established between the external device and the secure element through a key agreement process and used to implement a protection scheme based on a SCP03t algorithm, to ensure integrity of the installation package.

A confidential communication mechanism can thus be set up between the external device and the update agent.

Preferably, the header further comprises a protected keys field, carrying the image protection keys.

In some embodiments of the present invention, the header of the installation package comprises further a package binding signature for authenticating the software installation package. Preferably, the package binding signature comprises a signature of the initialize secure channel field and/or the protected keys field. The update agent is configured to perform authentication of the software installation package by verifying the package binding signature using a second key, in particular an Elliptical Curve Digital Signature, ECDSA, key, stored in the update agent.

According to a second aspect of the present invention, there is provided a computer-implemented data structure for providing a software installation package, in particular an operating system installation package, to an update agent on a secure element. The data structure comprises a header part and a data-carrying part. The header part comprises an initialize secure channel field carrying information on the installation operation to be implemented and for performing key derivation at the secure element. The data-carrying part comprises a plurality of image segments, wherein a sequence of consecutive image segments comprises a manifest, a manifest signature, and an image of the software to be loaded onto the secure element. Each image segment is protected with a pair of image protection keys.

Preferably, the header part comprises a protected keys field carrying image protection keys, for encrypting the software image.

Preferably, the header part comprises a package binding signature, comprising a signature of the initialize secure channel field and/or the protected keys field, for authenticating the software installation package.

In some embodiments of the present invention, the manifest contains information on the software image to be uploaded, in particular information for authenticating the software image and/or authenticating an issuer of the image. The "software image" refers to a generic data format encapsulating a software version and cryptographic data to be used by the update agent. A software image can be an image of an operating system, but also an image of an applet or other application to be installed onto the secure element.

According to a third aspect of the present invention, there is provided an update agent in a secure element for downloading software, in particular an operating system, onto a secure element. The update agent is configured to receive through a data structure according to the second aspect an installation package for installing an operating system and to perform the method according to the first aspect. In particular, the update agent is configured to verify the installation package and request control of the secure element, load the operating system received with the installation package into the secure element, and transfer control of the secure element to the operating system.

According to the present invention, the update agent is personalized with a plurality of cryptographic keys, selected from a set comprising at least a first key, for verifying the manifest signature and the initialize secure channel signature received with the installation package, a key pair, for key agreement for processing image segments of the installation package, a second key, for verifying the package binding signature. Preferably, the first key is an Elliptical Curve Digital Signature, ECDSA, key. Preferably, the second key is an Elliptical Curve Digital Signature, ECDSA, key. Preferably, the key pair for key agreement is an Elliptical Curve Key Agreement, ECKA, key pair. The update agent is configured to carry out the method for downloading an operating system onto the secure element according to any one of the embodiments described herein.

The aspects and embodiments described herein provide an efficient and secure solution for updating software, in particular an operating system, in a secure element, and thus to keep the secure element up to date with the evolution of the market, as well as to provide patches and security and bug fixes at any point in the life cycle of the secure element.

It has to be noted that all the devices, elements, units and means described in the present application could be implemented in software or hardware elements or combination thereof. All steps which are performed by the various entities described in the present application as well as the described functionalities are intended to mean that the respective entity is adapted to or configured to perform the respective steps and functionalities.

Further aspects, features and advantages of the present invention will become apparent to those of ordinary skills in the art upon reviewing the following detailed description of preferred embodiments and variants of the present invention in conjunction with the accompanying figures.

Reference will now be made to the accompanying figures, in which.

Detailed explanations of the present invention are given below with reference to attached drawings that illustrate specific embodiment examples of the present invention. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention. It is to be understood that the various embodiments of the present invention, although different, are not necessarily mutually exclusive. For example, a particular feature, structure, or characteristic described herein in connection with one embodiment may be implemented within other embodiments without departing from the scope of the present invention. In addition, it is to be understood that the position or arrangement of individual elements within each disclosed embodiment may be modified without departing from the scope of the present invention. The following detailed description is, therefore, not to be taken in a limiting sense, and the scope of the present invention is defined only by the appended claims, appropriately interpreted, along with the full range of equivalents to which the claims are entitled. In the drawings, like numerals refer to the same or similar functionality throughout the several views.

<FIG> shows a software update security scheme to provide a software image (e.g., OS image) for the update according to an embodiment. The scheme to provide the software image for the update adapts the general scheme known from GSMA RSP <NUM> to the architecture of <FIG>.

The diagram in <FIG> illustrates the various formats a profile package (i.e., a Bound Installation Profile) will take from its generation to being downloaded onto the secure element via the update agent. In particular, the Bound Installation Profile is created in several stages I to V beginning with the software image by performing several operations such as prepending and segmentation.

In the first stage I, the image <NUM>, provided by an image issuer, is prepended with a manifest <NUM> and a manifest signature <NUM>. The manifest <NUM> contains information pertaining to the new software image to be uploaded and ensures the image is acceptable and the issuer is trusted. The resulted block contains clear data that is not encrypted yet.

In stage II, the SM-DP+ <NUM> may generate, from the package obtained in stage I, an unprotected image package containing a sequence of profile element TLVs (Tag Length Values) TLV1,. , TLVn, <NUM>. Preferably, the structure of the TLVs is in accordance with the SIMalliance eUICC Profile Package: Interoperable Format Technical Specification V2.

In stage III, the SM-DP+ <NUM> may generate from the unprotected package profile, a protected package profile, by applying TLV encryption and MACing. These operations may preferably follow the scheme described in GSMA "Remote Provisioning of Embedded UICC Technical specification" V3. Preferably, TLV encryption is done by applying a private profile protection key PK-ENC, generated by the SM-DP+ <NUM>. The resulting data block is split into segments <NUM> to X, <NUM>.

In stage IV the SM-DP+ <NUM> may generate a Bound Installation Profile package <NUM>, by linking or binding the protected image package obtained in stage III to a particular eSIM/eUICC. This is done via a key agreement between the eSIM and the SM-DP+.

Finally, in stage V the Bound Installation Profile package <NUM>, with header part <NUM> and data-carrying part <NUM>, is segmented into blocks, and delivered to the update agent <NUM> on the eSIM or secure element <NUM>. Preferably, the segments are sent via STORE DATA commands.

The above described process can be aimed to a set of targets (Broadcast) or to a specific target (Unicast), the only difference being the keys used for the process and the Remote Operation ID used in key derivation.

Table <NUM> shows the structure of a Bound Installation Package, obtained by the scheme of <FIG> described above. The table comprises TLV entries comprising a tag (T), a length (L), and a value field (Value Description).

This part, with Tag or Data Group Identifier DGI 'BF51' is optional. It consists of a signature of the Initialize Secure Channel and the Protection Keys (if present) TLVs. Signed using the update agent's secrete key,SK. ECDSA and verified by its pair, a public key PK. Allow for the protection of the authentication part of the package.

This part, with Tag or Data Group Identifier DGI BF23 defines a procedure used by the SM-DP+ to open a new Remote SIM Provisioning Session with the target eSIM and contains information for a set of session keys derivation. These keys might be used to secure the Protected Keys or, if these are not present, the sequence of image segments <NUM>.

The procedure is an adaptation of the operation with the same name in [GSMA_RSP] section <NUM>. <NUM>, with notable differences.

The Initialize Secure Channel Procedure is defined by the structure in Table <NUM>.

Tag 'A2' contains the Image Protection Keys, which are the keys used to encrypt the software or OS image. If not present, the Image Protection Keys are equal to the derived session key set in the Initialize Secure Channel. If present, the Session Keys Template is a SCP03t secured (using the session key for encryption derived from the key agreement in Initialize Secure Channel) tag <NUM> TLV with the structure depicted in Table <NUM>.

Tag 'A3' contains the Manifest Signature <NUM>, the Manifest <NUM>, and the image <NUM> to be loaded divided in several segments. Each segment <NUM> comprises a TLV with tag <NUM> and is protected using SCP03t as defined in GSMA RSP <NUM>, using either the session keys derived in the key agreement.

or the Image Protection Keys if present in the Bound Package. The content secured in a segment is an Unprotected Package, comprising the entries depicted in Table <NUM>.

If the length of the content is not consistent with the provided size, the record is a pattern record, where the content must be written as many times as necessary until the specified size is met. The first segment/s shall contain the manifest <NUM>. The manifest <NUM> ensures the image is acceptable and the issuer is trusted.

The update agent <NUM> may receive an installation packages with the above-described structure, extract the operating system from the data-carrying part and download the operating system onto the secure element.

For being able to process an installation package with the above-described structure, the update agent may be personalized with a plurality of cryptographic keys. Examples of such keys may be:.

The external entity <NUM> providing the installation package may dispose of the respective corresponding keys:.

A method for downloading an operating system onto a secure element according to an embodiment will be described in the following with reference to <FIG>.

<FIG> shows a general flow chart of the method. <FIG> show further steps of the method of <FIG> according to preferred embodiments.

<FIG> shows a sequence diagram for implementing the method on the system architecture of <FIG> according to an embodiment.

With reference to <FIG>, an installation package <NUM> for installing an operating system onto the secure element <NUM>, is received at the update agent <NUM> in a first step S1. The installation package is sent from an entity external to the secure element, such as an image server <NUM> or an external device <NUM>. The external device <NUM> may describe an entity which is in control and communicates with the SE <NUM>. It can be a mobile terminal, or whatever device it is that the SE is mounted on.

The update agent <NUM> is the entity within the secure element <NUM> (separated from the OS) in charge of receiving the installation package and performing the software update. The update agent is loaded onto the secure element or TRE together with an (initial) Operative System (OS, <NUM> in <FIG>), during the factory production of the secure element <NUM>. Initially, the OS <NUM> is assumed to be in control, meaning it is the OS which is executed when the TRE <NUM> boots.

Thus, the update agent, upon receiving the installation package containing the new operating system, requests in step S2 control of the secure element to be transferred from the initial operating system to the update agent <NUM>. Being in control of the secure element, which does not have a file system at all, the update agent may then load in step S3 the new operating system into the secure element. After the new operating system has been loaded in the secure element, the update agent transfers in step S4 the control to the new operating system.

The above-described method may be implemented by the update agent <NUM> in two phases, as depicted in <FIG>.

In phase I, the update agent <NUM> receives in step S11 (which is a sub-step of step S1, c. , <FIG>) a first part of the installation package until and including the segment containing the manifest <NUM>. That is, the update agent receives the header part <NUM> and initials segments of the data-carrying part <NUM>, up to the segment comprising the manifest <NUM>.

In a sub-step S13 (c. , <FIG>) of step S1, the update agent verifies the signature <NUM> of the manifest, to ensure that the image is acceptable and the issuer is trusted. Preferably, the update agent uses a first key stored in the update agent for verifying the manifest. The first key may be an Elliptical Curve Digital Signature, ECDSA, key, stored in the update agent.

The update agent may in addition verify the initialize secure channel signature <NUM> also by using the first key (step S14 in <FIG>).

Optionally, the update agent may authenticate the installation package in a step S12, performed after receiving the first part of the installation package, by verifying the package binding signature using a second key, in particular an Elliptical Curve Digital Signature, ECDSA, key, stored in the update agent <NUM>.

After the signatures have been verified, the update agent requests control of the secure element (step S2 in <FIG>). This may be implemented by steps S21 to S23 in <FIG>.

With reference to <FIG>, the update agent indicates to the external device that a reset is required, to switch control from the initial operating system to the update agent, step S21. A reset is performed in step S22, through which the update agent <NUM> assumes control of the secure element <NUM>. Upon assuming control of the secure element, the update agent <NUM> may delete the initial operating system <NUM>.

With above sub-steps S11, S12, S13, S21, S22, S23 phase I in <FIG> is completed.

Phase II in <FIG> begins after the restart has been performed, and may be implemented as depicted by the steps of <FIG> and <FIG>.

In particular, the update agent may receive (S31 in <FIG>) the installation package again from the external device. This time, however, the complete installation package <NUM> is received, comprising the plurality of image segments <NUM>, wherein the plurality of image segments carries the manifest <NUM>, the manifest signature <NUM> and the (new) image <NUM> of the operating system. Each image segment may be protected with a pair of image protection keys <NUM>.

In step S32, the update agent <NUM> verifies integrity of the installation package. A set of keys may be used to establish integrity of the installation package. Preferably, the set of keys (e.g., a multicast key pair) is established between the external device <NUM> and the secure element <NUM> through a key agreement process and may be used to implement a protection scheme based on a SCP03t algorithm, to ensure integrity of the installation package <NUM>. To be able to process the installation package, the update agent is personalized with this key pair, as will be described later.

After verifying integrity of the installation package, the update agent <NUM> extracts in step S33 the operating system from the corresponding image segments <NUM>, and stores the (new or updated) operating system into a memory of the secure element in step S34.

After successfully completing the operating system download, the update agent <NUM> transfers control of the secure element <NUM> to the operating system, step S4 in <FIG>. The control transfer may be implemented by the steps S41 to S43 illustrated in <FIG>.

With reference to <FIG>, the update agent <NUM>, indicates to the external device that the download was completed, step <NUM>. A reset may be necessary, step S42, for the control of the secure element to be transferred to the newly installed operating system. Phase II in <FIG> is therewith completed.

In the above exemplified embodiments of <FIG> for implementing the method for downloading an operating system of <FIG>, the update agent receives from the external device the installation package segment by segment, wherein in phase I of <FIG>, the first segments of the installation package are received up to and including the manifest. After the update agent proceeds and accepts the manifest, the system is restarted, and during phase II the update agent receives the complete installation package, and extracts the operating system contained therein.

In an alternative implementation embodiment of the method in <FIG>, the update agent may receive the complete installation package during phase I, store it in a local memory, and process the installation package segment by segment until and including the segment containing the manifest. In this case, step S11 of <FIG> may be slightly different, requesting the update agent to process the installation package until the manifest segment is reached. The remaining steps S12 to S14 may remain unchanged. After the system reset, during which the update agent assumes control of the secure element, there is no need for the external device to send the entire installation package anymore, as the update agent has already received it. Step S31 in <FIG> may become obsolete. All the remaining steps and sub-steps illustrated in connection with the first implementation embodiment may be performed in the same way within the alternative implementation.

The aspects and embodiments described herein provide an efficient and secure solution for updating software, in particular an operating system, on a secure element at any time point after production of the secure element, and thus to keep the secure element up to date with the evolution of the market, as well as to provide patches and security and bug fixes at any point in the life cycle of the secure element.

Claim 1:
A method for downloading an operating system onto a secure element, the secure element (<NUM>) comprising an update agent (<NUM>), the method comprising the steps performed by the update agent:
- receiving (S1) from an external device (<NUM>; <NUM>) an installation package (<NUM>) for installing an operating system onto the secure element (<NUM>);
- requesting (S2) control of the secure element (<NUM>);
- loading (S3) the operating system received with the installation package into the secure element (<NUM>); and
- transferring (S4) control of the secure element (<NUM>) to the operating system;
wherein the installation package comprises a header part (<NUM>) and a data-carrying part (<NUM>), wherein the header part (<NUM>) comprises an initialize secure channel signature (<NUM>), and the data-carrying part (<NUM>) comprises a plurality of image segments (<NUM>), wherein a sequence of consecutive image segments comprises a manifest (<NUM>), a manifest signature (<NUM>), and an image (<NUM>) of the operating system to be loaded onto the secure element (<NUM>);
wherein receiving (S1) the installation package (<NUM>) comprises receiving (S11) a first part of the installation package comprising the header (<NUM>) and a first sequence of the plurality of image segments, the first sequence comprising the manifest signature (<NUM>) and the manifest (<NUM>); and wherein the method further comprises verifying (S12) the installation package by verifying the initialize secure channel signature (<NUM>) and the manifest signature (<NUM>) using a first key, in particular an Elliptical Curve Digital Signature, ECDSA, key, stored in the update agent (<NUM>).