Update Agent Download Scheme

The method allows secure elements to update their operating systems efficiently and securely, addressing the challenge of post-manufacture updates by using an update agent to control and load new software, ensuring continuous security and functionality.

JP7785814B2Active Publication Date: 2025-12-15GIESECKE PLUS DEFRIENT MOBILE SECURITY GERMANY GMBH
View PDF 5 Cites 0 Cited by

Patent Information

Application Number
JP2023579106
Authority / Receiving Office
JP · JP
Patent Type
Patents
Current Assignee / Owner
Priority Date
2021-06-30
Filing Date
2022-06-29
Publication Date
2025-12-15
Estimated Expiration
2042-06-29

AI Technical Summary

Technical Problem

Existing secure elements in mobile devices lack the ability to update their operating systems post-manufacture, making it difficult to address software issues such as vulnerabilities or new specifications, especially in certified environments.

Method used

A method and data structure for downloading an operating system to a secure element using an update agent that verifies and controls the secure element, ensuring secure and efficient loading, updating, and replacement of software.

Benefits of technology

Enables secure and efficient updating of the operating system within secure elements, keeping them up to date with market evolutions and providing patches and security fixes throughout their lifecycle.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 0007785814000005
    Figure 0007785814000005
  • Figure 0007785814000006
    Figure 0007785814000006
  • Figure 0007785814000007
    Figure 0007785814000007
Patent Text Reader

Abstract

It provides an efficient and secure solution for keeping secure elements up to date with market evolution, as well as for providing patches, security and bug fixes at any point in the lifecycle of the secure element. The present invention relates to a method, a data structure and an update agent for implementing a scheme for downloading an operating system image to a secure element. The update agent receives an installation package from an external device for installing an operating system on the secure element. The update agent requests control of the secure element and loads the operating system received with the installation package onto the secure element, after which control of the secure element is transferred to the operating system.
Need to check novelty before this filing date? Find Prior Art

Description

[Technical Field]

[0001] The present invention relates to updating software such as operating systems on secure elements, and more particularly to methods, data structures, and update agents for implementing a scheme for downloading operating system images to secure elements. [Background technology]

[0002] Background of the Invention In recent years, mobile devices have emerged that are configured to employ electronic subscriber profiles for communicating over mobile networks, and such mobile devices typically include a smart card that includes an electronic / embedded secure element (SE), such as an electronic / embedded universal integrated circuit card (eUICC), smartSD, or smart microSD, to name a few.

[0003] A Secure Element is a tamper resistant element (TRE) that provides a secure memory and execution environment within a smart card / device where application code and data can be securely stored and managed. The Secure Element ensures that access to data stored on the card is only provided when authorized.

[0004] Secure elements designed for use in telecommunications products such as mobile devices are configured to store one or more electronic subscriber profiles, in particular electronic / embedded subscriber identification module (eSIM) profiles, that may enable the mobile device to connect to one or more mobile networks. The subscriber profiles (e.g., eSIM profiles) may be generated by a mobile network operator (MNO) and downloaded to the mobile network device. The subscriber profiles may then be installed in the secure element of the mobile device and used for communication by the mobile device over the corresponding mobile networks.

[0005] Figure 1 shows a simplified diagram of the architecture of a remote eSIM provisioning system as described in the SGP.22 RSP Technical Specification Version 2.0 (hereafter referred to as GSMA RSP22) published by the GSM Association. The eSIM provisioning system 1 is organised around several elements: SM-DP+ (Subscription Manager - Data Preparation and Secure Routing 11), SM-DS (Subscription Manager - Discovery Server 14), LPA (Local Profile Assistance 25) and eUICC 10, the latter being part of the mobile device 20 of the end user 13.

[0006] The SM-DP+11 is responsible for creating, downloading, remotely managing (enabling, disabling, updating, deleting) and protecting subscriber profiles provided by the MNO 12. In particular, the SM-DP+11 may be configured to provide profiles in Bound Profile Packages and to enable the Bound Profile Packages to be transmitted securely.

[0007] The LPA (Local Profile Assistant 25) is the set of functions in the device 20 responsible for providing the capability to download (encrypted) profiles to the eUICC / TRE / SE 10. It also presents a local management end user interface to the end user 13 so that the end user 13 can manage the status of profiles on the eUICC / TRE / SE 10. The SM-DS 14 provides the means for the SM-DP+ 11 to communicate with the eUICC / TRE / SE 10.

[0008] Traditionally, the native implementation or operating system of a TRE could not be updated once the TRE was deployed in the field, and therefore did not change once the TRE went beyond the production stage. This meant that if a problem related to the software inside it was found (a new attack or vulnerability, a new update to the sector specification, the expected lifecycle of a device using it), the only possible action was to change the entire TRE. This made it particularly difficult to keep up with market needs from a production perspective (since post-production software updates were not possible), especially when production had to be performed in a certified environment in a factory.

[0009] The GSMA Remote Provisioning architecture shown in Figure 1 provides a platform for implementing a procedure for loading profiles into a Secure Element (SE) or a Tamper-Resistant Element (TRE), but it only allows for implementing changes to data stored in the SE / TRE, not the underlying software residing in the SE / TRE. This procedure requires several interactions between the TRE and the server before it can prepare the bound profile package used for loading, which may not be optimal for broadcast deployments of new software. Also, this scheme lacks an additional layer of protection that may be required for the deployment of critical data such as a new operating system.

[0010] It is therefore desirable to provide a solution for updating the operating system on a secure element that addresses the above-mentioned drawbacks. Summary of the Invention [Problem to be solved by the invention]

[0011] Summary of the Invention The present invention addresses the above objectives by means of the subject matter covered by the independent claims. Preferred embodiments of the invention are defined in the dependent claims. [Means for solving the problem]

[0012] According to a first aspect of the present invention, there is provided a method for downloading an operating system to a secure element, the secure element including an update agent configured to perform the following steps: the update agent receives an installation package from an external device for installing the operating system on the secure element, the update agent requests control of the secure element, loads the operating system received with the installation package onto the secure element, and thereafter transfers control of the secure element to the operating system.

[0013] The proposed method provides an efficient and secure solution for loading trusted software, in particular an operating system, into a secure element once its manufacture is complete. By giving the update agent the ability to control the secure element, the update agent is entrusted with the secure element, which does not have its own file system for the time being. This allows for efficient and secure loading, updating and replacement of software within the secure element.

[0014] In some embodiments of the present invention, the installation package includes a header portion and a data carrier portion, the header portion including an initialize secure channel signature, and the data carrier portion including multiple image segments, the sequence of consecutive image segments including a manifest, a manifest signature, and an image of an operating system to be loaded into the secure element.

[0015] In some embodiments of the present invention, receiving the installation package includes receiving a first portion of the installation package including a header and a first sequence of image segments, the first sequence carrying a manifest signature and a manifest. After receiving the first portion of the installation package, the update agent is further configured to verify the secure channel initialization signature and the manifest signature included in the header using a first key, in particular an Elliptical Curve Digital Signature (ECDSA) key, stored in the update agent.

[0016] This provides an update agent with a control mechanism that ensures both the reliability of the installation package and the reliability of the transmission channel.

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

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

[0019] In some embodiments of the present invention, loading the operating system includes receiving, after a system reset, a complete installation package from an external device, the complete installation package including multiple image segments, the multiple image segments carrying a manifest, a manifest signature, and an image of the operating system, each image segment protected with an image protection key pair. After receiving the installation package, the update agent verifies the integrity of the installation package, extracts the operating system from the corresponding image segment, and stores the operating system in the memory of the secure element.

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

[0021] In this way, a covert communication mechanism can be set up between the external device and the update agent.

[0022] Preferably, the header further includes a protected key field that carries the image protection key.

[0023] In some embodiments of the present invention, the header of the installation package further includes a package binding signature for authenticating the software installation package. Preferably, the package binding signature includes a signature of an initialize secure channel field and / or a protected key 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 Elliptic Curve Digital Signature Algorithm (ECDSA) key, stored in the update agent.

[0024] According to a second aspect of the present invention, there is provided a computer-implemented data structure for providing a software installation package, particularly an operating system installation package, to an update agent on a secure element. The data structure includes a header portion and a data carrier portion. The header portion includes a secure channel initialization field that carries information about an installation operation to be performed and information for performing key derivation on the secure element. The data carrier portion includes a plurality of image segments, a sequence of consecutive image segments including a manifest, a manifest signature, and an image of the software to be loaded onto the secure element.

[0025] Preferably, the header portion includes a protected key field that carries an image protection key for encrypting the software image.

[0026] Preferably, the header portion includes a package binding signature, which includes a signature of the secure channel initialization field and / or the protected key field, for authenticating the software installation package.

[0027] In some embodiments of the invention, the manifest contains information about the software image to be uploaded, in particular information for authenticating the software image and / or information for authenticating the publisher of the image. "Software image" refers to a generic data format that encapsulates software versions and cryptographic data used by update agents. The software image can be an image of an operating system, but can also be an image of an applet or other application to be installed on the secure element.

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

[0029] In some embodiments of the present invention, the update agent is personalized with multiple cryptographic keys selected from a set including at least a first key for verifying a manifest signature and a secure channel initialization signature received with the installation package, a key pair for key agreement for processing image segments of the installation package, and a second key for verifying a package binding signature. Preferably, the first key is an Elliptic Curve Digital Signature (ECDSA) key. Preferably, the second key is an Elliptic Curve Digital Signature (ECDSA) key. Preferably, the key pair for key agreement is an Elliptical Curve Key Agreement (ECKA) key pair.

[0030] The aspects and embodiments described herein provide an efficient and secure solution for updating software, particularly the operating system, within a secure element, thereby keeping the secure element up to date with market evolutions and providing patches, security and bug fixes at any point in the lifecycle of the secure element.

[0031] It should be noted that all devices, elements, units, and means described in this application may be implemented with software elements or hardware elements or a combination thereof. All steps performed by various entities described in this application, and the described functionality, are intended to mean that the respective entities are adapted or configured to perform the respective steps and functionality.

[0032] Further aspects, features, and advantages of the present invention will become apparent to those skilled in the art upon review of the following detailed description of preferred embodiments and variations of the invention in conjunction with the accompanying figures. [Brief explanation of the drawings]

[0033] BRIEF DESCRIPTION OF THE DRAWINGS [Figure 1] A simplified diagram of the GSMA remote provisioning system architecture is shown. [Figure 2] 1 illustrates an architecture of a remote eSIM provisioning system according to an embodiment of the present invention. [Figure 3] 1 shows a flowchart of a method for downloading an operating system to a secure element according to an embodiment. [Figure 4] 4 illustrates a further step of the method of FIG. 3 according to a preferred embodiment. [Figure 5] 4 illustrates a further step of the method of FIG. 3 according to a preferred embodiment. [Figure 6] 4 illustrates a further step of the method of FIG. 3 according to a preferred embodiment. [Figure 7] 4 illustrates a further step of the method of FIG. 3 according to a preferred embodiment. [Figure 8] 3 shows a sequence diagram for implementing a method for downloading an operating system onto the system architecture of FIG. 2 according to one embodiment. [Figure 9] 1 illustrates a security scheme for performing software / OS updates, according to one embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0034] Detailed Description A detailed description of the present invention follows, with reference to the accompanying drawings that illustrate specific exemplary embodiments of the invention. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention. It should be understood that 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 invention. In addition, it should be understood that the location or arrangement of individual elements within each disclosed embodiment may be modified without departing from the scope of the invention. Therefore, the following detailed description is not to be taken in a limiting sense, and the scope of the present invention is defined solely by the appended claims, appropriately interpreted, along with the full range of equivalents to which such claims are entitled. In the drawings, like numerals refer to the same or similar features throughout the several views.

[0035] Figure 9 illustrates a software update security scheme for providing software images (e.g., OS images) for updates, according to one embodiment. The scheme for providing software images for updates is an adaptation of the general scheme known from GSMA RSP22 to the architecture of Figure 2.

[0036] The diagram in Figure 9 shows the different formats that a profile package (i.e., a Bound Installation Profile) can take from the time it is generated until it is downloaded to the secure element via an update agent. In particular, the Bound Installation Profile is created in several stages I to V starting from the software image by performing several operations such as prepend and segmentation.

[0037] In the first phase I, an image 501 provided by an image publisher is prepended with a manifest 502 and a manifest signature 501. The manifest 502 contains information related to the new software image being uploaded and ensures that the image is acceptable and that the publisher is trustworthy. The resulting block contains plaintext data that has not yet been encrypted.

[0038] In Phase II, the SM-DP+ 11 may generate an unprotected image package containing a sequence of profile element TLVs (Tag Length Values) TLV1, ..., TLVn (510) from the package obtained in Phase I. Preferably, the structure of the TLVs complies with the SIMalliance eUICC Profile Package (Interoperable Format Technical Specification V2.0).

[0039] In Phase III, the SM-DP+11 may generate a protected package profile from the unprotected package profile by applying TLV encryption and MACing. These operations may preferably follow the scheme described in the GSMA "Remote Provisioning of Embedded UICC Technical Specification" V3.1. Preferably, the TLV encryption is performed by applying a private profile protection key PK-ENC generated by the SM-DP+11. The resulting data block is divided into segments 1 to X (521).

[0040] In phase IV, the SM-DP+ 11 can create a bound installation profile package 500 by linking or binding the protected image package obtained in phase III to a specific eSIM / eUICC. This is done by sharing a key between the eSIM and the SM-DP+.

[0041] Finally, in stage V, the bound installation profile package 500, comprising the header portion 530 and the data carrying portion 520, is segmented into blocks and sent to the update agent 110 on the eSIM or secure element 100. Preferably, the segments are sent via a STORE DATA command.

[0042] The above process can be targeted to a set of targets (broadcast) or to a specific target (unicast), the only difference being the key used for the process and the remote operation ID used to derive the key.

[0043] Table 1 shows the structure of the bound installation package obtained by the scheme in Figure 9. This table contains TLV entries that include a tag (T), length (L), and value field (value description).

[0044] [Table 1]

[0045] The table entries include: a) Bound Package Signature (Figure 9, Package Binding Signature 531) This part, which has the tag or Data Group Identifier DGI (BF51), is optional. It consists of a signature of the Secure Channel Initialization and Protection Key (if present) TLV. It is signed using the update agent's private key SK.ISSUER.ECDSA and verified by its counterpart public key PK. It allows protection of the authentication part of the package. b) Secure Channel Initialization (Figure 9, 532) This part, bearing the tag or data group identifier DGI "BF23", defines the procedure used by the SM-DP+ to open a new remote SIM provisioning session with the target eSIM and contains information for the derivation of a set of session keys that can be used to protect the protected key or, if no protected key exists, the sequence of image segments 541.

[0046] This procedure is an adaptation of the operation of the same name in [GSMA_RSP] section 5.5.1, with the notable difference (i) SharedInfo for key derivation (defined in [GSMA_RSP] Annex G) uses a remote operation ID (broadcast or unicast) instead of an EID; (ii) In this scheme, assuming that the key used for key sharing (SK.EUICC.ECKA) is fixed, the transaction ID is stored and used to avoid replay attacks; (iii) The transaction ID is reset when SK.EUICC.ECKA is updated; (iv) The signature of tag 5F37 shall be performed using the private key SK.ISSUER.ECKA of the update agent and shall be verified pairwise.

[0047] The secure channel initialization procedure is defined by the structure in Table 2.

[0048] [Table 2]

[0049] c) Protected Key (Figure 9, 533) Tag "AT" contains the image protection key, which is the key used to encrypt the software or OS image. If not present, the image protection key is equal to the derived session key set at secure channel initialization. If present, the session key template is an SCP03t assurance (uses session key for encryption derived from key agreement at secure channel initialization) tag 87 TLV with the structure shown in Table 3.

[0050] [Table 3]

[0051] d) Sequence of image segments (Fig. 9, 521) Tag "A3" contains a manifest signature 503, a manifest 502, and an image 501 that is split into segments and loaded. Each segment 521 contains a TLV with tag 86 and is protected using SCP03t as defined in GSMA RSP22 using either a session key derived from a key agreement or an image protection key if present in the bound package. The content protected in a segment is an unprotected package containing the entries shown in Table 4.

[0052] [Table 4]

[0053] If the content length does not match the provided size, this record is a pattern record and the content must be written as many times as necessary until the specified size is met. The first segment or segments shall contain a manifest 502. The manifest 502 ensures that the image is acceptable and that the publisher is trustworthy.

[0054] The update agent 110 is able to receive the installation package having the above structure, extract the operating system from the data carrier portion, and download the operating system to the secure element.

[0055] To be able to process installation packages with the above structure, the update agent can be personalized with several cryptographic keys. Examples of such keys include: - A first key for verifying the manifest signature and the secure channel initialization signature received with the installation package. This first key may be an Elliptic Curve Digital Signature (ECDSA) key PK.KEY.EC-DSA. - A key pair, preferably a multicast key pair, for key agreement for processing the image segments of the installation package. This key pair may be an Elliptic Curve Key Agreement (ECKA) key pair SK_MC.EUICC.ECKA. - A second key for verifying the package binding signature, preferably an Elliptic Curve Digital Signature Algorithm (ECDSA) key PK.OWN.ECDSA.

[0056] The external entity 200 providing the installation package can revoke each of the following corresponding keys: - otSK.ISSUER.ECKA and otPK.ISSUER.ECKA: This is a one-time key pair used to calculate the session key. - SK.ISSUER.ECDSA: This is the key used to sign the manifest (i.e., generate a manifest signature), sign the secure channel initialization (i.e., generate a secure channel initialization signature), and sign the image (i.e., generate an image signature).

[0057] A method for downloading an operating system to a secure element according to an embodiment will now be described with reference to Figures 3 to 8 .

[0058] Figure 3 shows a general flow chart of the method, and Figures 4 to 7 show further steps of the method of Figure 3 according to a preferred embodiment.

[0059] FIG. 8 shows a sequence diagram for implementing the method on the system architecture of FIG. 2 according to one embodiment.

[0060] 3, in a first step S1, an installation package 500 for installing an operating system on the secure element 100 is received by the update agent 110. The installation package is sent from an entity external to the secure element, such as an image server 300 or an external device 200. The external device 200 may represent an entity that controls and communicates with the SE 100. It may be a mobile terminal or any device on which an SE is installed.

[0061] The update agent 110 is an entity within the secure element 100 (separate from the OS) that is responsible for receiving the installation package and performing the software update. The update agent is loaded into the secure element or TRE together with the (initial) operating system (OS, 130 in Figure 2) during factory production of the secure element 100. Initially, the OS 130 is assumed to be in control, meaning that it is the OS that runs when the TRE 100 boots up.

[0062] Thus, when the update agent receives an installation package containing a new operating system, it requests in step S2 that control of the secure element be transferred from the initial operating system to the update agent 110. By taking control of the secure element, which does not have any file system, the update agent is able to load the new operating system into the secure element in step S3. After the new operating system has been loaded into the secure element, the update agent transfers control to the new operating system in step S4.

[0063] The above method may be implemented by update agent 110 in two phases, as shown in FIG.

[0064] In Phase I, update agent 110 receives, in step S11 (which is a substep of step S1, see FIG. 4), the first part of the installation package up to (and including) the segment containing manifest 502. That is, the update agent receives header portion 530 and initially signs the segments of data carrier portion 520 up to and including the segment containing manifest 502.

[0065] In substep S13 of step S1 (see FIG. 4), the update agent verifies the signature 503 of the manifest to ensure that the image is acceptable and the publisher is trustworthy. Preferably, the update agent uses a first key stored in the update agent to verify the manifest. The first key may be an Elliptic Curve Digital Signature Algorithm (ECDSA) key stored in the update agent.

[0066] The update agent can further verify the secure channel initialization signature 532 by using the first key (step S14 in FIG. 4).

[0067] Optionally, in step S12, which is performed after receiving the first part of the installation package, the update agent can authenticate the installation package by verifying the package binding signature using a second key, in particular an Elliptic Curve Digital Signature Algorithm (ECDSA) key, stored in the update agent 110.

[0068] After the signature is verified, the update agent requests control of the secure element (step S2 in FIG. 3), which can be implemented by steps S21 to S23 in FIG.

[0069] 5, 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). The reset is performed in step S22, through which the update agent 110 assumes control of the secure element 100. Once it has assumed control of the secure element, the update agent 100 can remove the initial operating system 130.

[0070] The above sub-steps S11, S12, S13, S21, S22, and S23 complete Phase I of FIG.

[0071] Phase II of FIG. 8 begins after a reboot has been performed and may be performed as shown by the steps of FIGS.

[0072] In particular, the update agent may again receive an installation package from an external device (S31 in FIG. 6), but this time a complete installation package 500 is received, including multiple image segments 521, which carry a manifest 502, a manifest signature 503, and an operating system (new) image 501. Each image segment may be protected with a pair of image protection keys 533.

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

[0074] After verifying the integrity of the installation package, the update agent 110 extracts the operating system from the corresponding image segment 501 in step S33 and stores the (new or updated) operating system in the memory of the secure element in step S34.

[0075] When the download of the operating system is successfully completed, the update agent 110 transfers control of the secure element 100 to the operating system (step S4 in FIG. 3). The transfer of control can be performed by steps S41 to S43 shown in FIG.

[0076] Referring to Figure 7, the update agent 110 indicates to the external device that the download is complete (step S41). A reset may be required to transfer control of the secure element to the newly installed operating system (step S42), which completes Phase II of Figure 8.

[0077] In the above exemplary embodiment of Figures 4-7 for implementing the method of downloading an operating system of Figure 3, the update agent receives the installation package segment by segment from the external device, and in Phase I of Figure 8, the first segment of the installation package up to and including the manifest is received. After the update agent proceeds and accepts the manifest, the system is rebooted, and during Phase II, the update agent receives the complete installation package and extracts the operating system contained therein.

[0078] In an alternative implementation of the method of FIG. 3, the update agent may receive the complete installation package during Phase I, store it in local memory, and process the installation package segment by segment up to and including the segment containing the manifest. In this case, step S11 of FIG. 4 may be slightly different and may require the update agent to process the installation package until it reaches the manifest segment. The remaining steps S12-S14 may remain unchanged. After a system reset (during which the update agent assumes control of the secure element), the external device no longer needs to send the entire installation package because the update agent has already received it. Step S31 of FIG. 6 may become obsolete. All remaining steps and substeps illustrated in connection with the first implementation may be similarly performed in the alternative implementation.

[0079] The aspects and embodiments described herein provide an efficient and secure solution for updating software, in particular the operating system, on a secure element at any point after the secure element is manufactured, thereby keeping the secure element up to date with market evolutions, as well as providing patches, security and bug fixes at any point in the lifecycle of the secure element.

[0080] In the foregoing specification, the present invention has been described with reference to specific embodiments thereof. However, it will be apparent that various modifications and changes can be made thereto without departing from the broader scope of the present invention. For example, the process flows above are described with reference to a particular order of process actions. However, the order of many of the described process actions can be changed without affecting the scope or operation of the present invention. Accordingly, the specification and drawings are to be interpreted in an illustrative rather than a restrictive sense.

Claims

1. 1. A method for downloading an operating system to a secure element, comprising: The secure element (100) includes an update agent (110); The method comprises the steps performed by the update agent, namely: Receiving (S1) from an external device (200; 300) an installation package (500) for installing an operating system on the secure element (100); Requesting control of the secure element (100) (S2); loading (S3) the operating system received with the installation package into the secure element (100); Transferring control of the secure element (100) to the operating system (S4); Including, The method, wherein the installation package includes a header portion (530) and a data carrier portion (520), the header portion (530) including a secure channel initialization signature (532), the data carrier portion (520) including a plurality of image segments (521), and a sequence of consecutive image segments including a manifest (502), a manifest signature (503), and an image (501) of the operating system to be loaded into the secure element (100).

2. 2. The method of claim 1, wherein receiving (S1) the installation package (500) comprises receiving (S11) a first portion of the installation package including the header (530) and a first sequence of the plurality of image segments, the first sequence including the manifest signature (501) and the manifest (502), and the method further comprises verifying (S12) the installation package by verifying the secure channel initialization signature (532) and the manifest signature (503) using a first key, in particular an Elliptic Curve Digital Signature Algorithm (ECDSA) key, stored in the update agent.

3. 2. The method of claim 1, wherein requesting (S2) control of the secure element (100) comprises sending (S21) a request to the external device (200; 300) to perform a system reset.

4. 4. The method of claim 3, further comprising: assuming control of the secure element (100) (S22); and deleting an initial operating system (S23) contained within the secure element (100) after the system reset.

5. Loading the operating system (S3) receiving (S31) a complete installation package (500) from the external device (200; 300) after the system reset, the complete installation package including the plurality of image segments (521), the plurality of image segments carrying the manifest (502), the manifest signature (503), and the image (501) of the operating system, each image segment being protected with a pair of image protection keys (533); Verifying the integrity of the installation package (S32); Extracting the operating system from the corresponding image segment (S32); storing the operating system in the memory of the secure element (S33); The method of claim 1 , comprising:

6. 6. The method of claim 5, wherein the image protection key (533) is established through a key agreement process between the external device (200; 300) and the secure element (100) to ensure the integrity of the installation package (500) and is used to implement a protection scheme based on the SCP03t algorithm.

7. 6. The method of claim 5, wherein the header (530) of the installation package (500) further includes a package binding signature (531), and the method further includes authenticating the installation package by verifying the package binding signature (531) using a second key, in particular an Elliptic Curve Digital Signature Algorithm (ECDSA) key, stored in the update agent (110).

8. An update agent (110) for downloading software, in particular an operating system, to a secure element (100), comprising: Receiving an installation package (500) for installing an operating system by a computer-implemented data structure, the computer-implemented data structure being configured to provide the software installation package (500), in particular the operating system installation package, to an update agent (110) on a secure element (100), the computer-implemented data structure comprising: a header portion (530) including a secure channel initialization field (532) carrying information regarding an installation operation to be performed and information for performing key derivation in the secure element (100); and a data carrying portion (520) including a plurality of image segments (521). a data carrier portion (520) including a sequence of consecutive image segments containing a manifest (502), a manifest signature (503), and an image (501) of the software to be loaded into the secure element, wherein the software installation package (500) is transmitted from an external device (200; 300) to the secure element (100), and the header portion (530) and the data carrier portion (520) are configured such that a set of keys is established between the external device (200; 300) and the secure element (100) through a key agreement process to establish the integrity of the software installation package (500); Validating the installation package (500) and requesting control of the secure element (100); loading the operating system received with the installation package (500) into the secure element (100); transferring control of the secure element (100) to the operating system; The Update Agent is configured to run.

9. The update agent of claim 8, wherein the header portion (530) further includes a protected key field (533) carrying an image protection key for encrypting the software image.

10. An update agent as described in claim 8, wherein the header portion (530) further includes a package binding signature (531) including a signature of the secure channel initialization field and / or protected key field for authenticating the software installation package.

11. An update agent as described in claim 8, wherein the manifest includes information about the software image to be uploaded, in particular information for authenticating the software image and / or information for authenticating the publisher of the image.

12. at least, a first key, in particular an Elliptic Curve Digital Signature Algorithm (ECDSA) key, for verifying the manifest signature and the secure channel initialization signature in the installation package; a key pair, in particular an Elliptic Curve Key Agreement (ECKA) key pair, for processing the image segments of the installation package; a second key, in particular an Elliptic Curve Digital Signature Algorithm (ECDSA) key, for verifying the package binding signature (531); 11. The update agent of claim 10, personalized with a plurality of encryption keys selected from a set comprising:

13. An update agent (110) according to claim 12, adapted to carry out the method according to any one of claims 1 to 7.

Citation Information

Patent Citations

  • Method for managing objects in a secure element

    EP3208717A1

  • Method for reconstructing software package

    JP2007026244A

  • Updating operating system for secure element

    JP2014029688A

  • How to manage packages inside the secure element

    JP2018533796A

  • Method and apparatus for updating operating system

    US20200034137A1