Method for updating an operating system installed in a secure element, corresponding system and secure element - Patents.com

Abstract

The present invention relates to a method for updating an OS (102) installed in a secure element (106) thanks to an OS update platform (104) that exposes the same ES9+ interface as SM-DP+, the secure element (106) being an eUICC or iUICC that cooperates with a terminal, the secure element and the terminal being comprised in a device, the method comprising: loading an OS update script (102) into the OS update platform (104) of the manufacturer of the secure element (100); The method includes triggering the LPA (105) to connect to the OS update platform (104), downloading the OS update script (102) into the ISD-P (107) of the secure element (106) by the LPA (105), and installing the OS update script (102) into the ISD-P (107) of the secure element (106); and returning an execution result to the OS update platform (104) through the LPA (105) by the secure element (106) after the installation of the OS update script (102) into the ISD-P (107).

Description

[Technical field]

[0001] The invention relates to a consumer integrated secure element like eSIM (embedded UICC also called eUICC or integrated UICC also called iUICC) and a server managing such an integrated secure element for consumer products (tablets, smartphones, PDAs, telematics (a branch of information technology dealing with the transmission of computerized information over long distances)...), in particular for patching their OS (operating system). The invention is applicable to cellular networks (3G (UMTS), 4G networks (LTE) or 5G networks). The invention applies in particular to automotive systems. [Background technology]

[0002] It is known from patent application WO2020 / 201313 that it is possible to transparently patch the operating system on the secure element through the SM-SR platform.

[0003] In this patent application, the SM-DP platform patches the operating system on a secure element embedded in a terminal.

[0004] The suggested approach is: i- sending a command from the SM-DP platform to the SM-SR to create an ISD-P on the secure element; ii- Establishing a secure channel between the SM-DP platform and the ISD-P or secure element; iii- sending an operating system patch from the SM-SR to the secure element; iv- Executing the operating system patch in the ISD-P; v- sending a message from the secure element to the SM-DP platform to inform the SM-DP platform of the result of the execution of the patch; Includes.

[0005] A GSMA compliant eUICC or iUICC (Secure Element or eSIM in the following description) is soldered into the device and deployed in the field. It is managed by a set of well-defined OTA platforms (SM-SR / SM-DP). SM-SR is the Subscription Manager Secure Routing platform and SM-DP is the Subscription Manager Data Preparation platform. SM-DP is the entity used by the operator to securely encrypt the operator profiles (a profile is a set of file systems, applications and certificates) ready for over-the-air installation into the Secure Element through SM-SR.

[0006] The SM-SR securely delivers the encrypted operator profile to the secure element and then, once the profile is installed, remotely manages the secure element thereafter (enabling, disabling, and removing it as needed during the product life).

[0007] Maintenance of the operating system and secure element content requires over-the-air (OTA) or internet connectivity, but applying operating system maintenance commands requires specific applications installed on the device that will be authorized to send commands to the eSIM.

[0008] Although the GSMA eSIM specification allows the EUM (secure element manufacturer) to use proprietary commands to patch the secure element OS, the EUM generally does not own one of the identified platforms above (SM-SR / SM-DP), and the identified platforms do not have management of OS patches within their scope.

[0009] Although using the solution described in WO2020 / 201313 could be realised for M2M Secure Elements, the different architecture (no SM-SR, no direct access to ISD-P, no possibility to execute arbitrary APDUs) does not make it applicable for consumer Secure Elements. [Prior art documents] [Patent documents]

[0010] [Patent Document 1] International Publication No. 2020 / 201313 Summary of the Invention [Problem to be solved by the invention]

[0011] Therefore, the scope of the present invention is to propose a solution for patching the OS of consumer secure elements without using SM-SR. [Means for solving the problem]

[0012] In this respect, the present invention proposes a method for updating an OS installed in a secure element, thanks to an OS update platform exposing the same ES9+ interface as SM-DP+, the secure element being an eUICC or iUICC cooperating with a terminal, the secure element and the terminal being comprised in a device, the method comprising: - loading the OS update script into the OS update platform of the secure element manufacturer; - Triggering the LPA of the terminal to connect to the OS update platform by using the ES9+SM-DP+ protocol; - downloading an OS update script into the ISD-P of the secure element by the LPA and installing the OS update script into the ISD-P of the secure element; - After the installation of the OS update script in the ISD-P, the execution result is returned by the secure element to the OS update platform through the LPA. Includes.

[0013] Preferably, the method includes notifying an original equipment manufacturer of a device that comprises the terminal that an OS update script is available.

[0014] Advantageously, the ISD-P in the secure element is deleted after execution of the OS update script.

[0015] Advantageously, the secure element prohibits the ISD-P from being enabled unless the ISD-P is removed.

[0016] Preferably, the loading of the OS update script includes several steps of dynamic generation of script commands depending on the characteristics of the secure element.

[0017] Advantageously, the OS update script includes one or more PE-non-standard commands that enable installation and execution of the OS update script.

[0018] Preferably, the PE-non-standard content is itself encrypted.

[0019] The invention also relates to a system comprising an OS update platform exposing the same ES9+ interface as SM-DP+, the system comprising a secure element cooperating with a terminal, the secure element and the terminal being comprised in a device, the secure element being able to update the OS upon receiving an OS update script of an OS update platform of a secure element manufacturer of the secure element, the terminal comprising an LPA: - The LPA is triggered to connect to the OS update platform by using the ES9+SM-DP+ protocol; - the LPA downloads the OS update script into the ISD-P of the secure element and installs the OS update script into the ISD-P of the secure element; After the installation of the OS update script in the ISD-P, the secure element returns the execution result to the OS update platform through the LPA.

[0020] The invention also relates to a secure element cooperating with a terminal, the secure element and the terminal being comprised in a device, the secure element being able to update the OS script upon receiving an OS update script of an OS update platform of a secure element manufacturer of the secure element, the terminal comprising an LPA: - The LPA is triggered to connect to the OS update platform by using the ES9+SM-DP+ protocol; - the LPA downloads the OS update script into the ISD-P of the secure element and installs the OS update script into the ISD-P of the secure element; After the installation of the OS update script in the ISD-P, the secure element returns the execution result to the OS update platform through the LPA.

[0021] The secure element can be an eUICC or an iUICC. [Brief description of the drawings]

[0022] [Figure 1] FIG. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0023] Other details and advantages of the invention will become apparent upon reading the following advantageous embodiments thereof, given by way of illustration and not by way of limitation, and upon reference to the attached single drawing, which shows a preferred method according to the invention.

[0024] In this figure 1, several elements are shown: - EUM 100 generating OS update scripts that are stored in the memory of a script platform 104 (also called OS update platform) with a signed token (e.g. a signed token known as an EUM certificate). EUM 100 also cooperates with OEM device 101 manufacturers, e.g. manufacturers of tablets integrated in the vehicle of a user 103 or car manufacturers. - LPA105 on the device itself; - the device comprises a secure element 106, such as an eUICC or an iUICC; - The secure element 106 also comprises an ISD-P (Secure Domain) 107 for OS update scripts (the creation of which is explained below), an ISDP-MNO 108 (ISD-P created to host the Mobile Network Operator Profile) and an ISD-R 109 (Issuer Security Domain - Root). The secure element 106 comprises an ISD-P 107 for OS update scripts, which is able to process dedicated programs or scripts to install new OS update scripts in the secure element 106. - MNO files and application repertoires integrated according to practice in the secure element 111; The secure element 106 also comprises an operating system 115, the latter: To verify the version of the OS update script and its signatures; To run OS update scripts; For QC (Quality Control) script execution; For rollback management, which is intended to undo the installation of the OS update script if something goes wrong during the installation of the OS update script; For result management to inform the script platform 104 whether the OS update script was installed correctly or not The system is provided with a presumed OS update script management system 113. - and finally, an OS update script 114 installed on the secure element 106 by the script platform 104, as will be described below.

[0025] The script platform 104 behaves like a standard SM-DP+ in its interface to the LPA 105 and to the EUM 100 .

[0026] Having described these different devices, a preferred method for implementing the invention will now be described.

[0027] When the EUM 100 or the service provider decides to send an update script (patch) to the target secure element 106, the steps are as follows, as shown:

[0028] In step 1, the EUM 100 sends the OS update script, and optionally a signed token, to the script platform 104. At the same time (step 1), the EUM 100 notifies the OEM device manufacturer 101 that the OS update script is available.

[0029] In the same step 1, the EUM 100, the OEM or the secure element owner 100, or the service provider or MNO that has the right to request the installation of an OS update script on the secure element 106, requests the script platform 104 to install the update script on this secure element 106.

[0030] This secure element may be the identified secure element or a batch of secure elements to be updated.

[0031] In step 2, the EUM, OEM device manufacturer, or MNO with access to the end user can then notify the user 103 (via email, SMS, push service, etc.) that an OS update script is available (optional step). The end user 103 is thus notified that the end user 103 is encouraged to perform the action.

[0032] The user 103 can then authorize (or not) the installation of the update script (step 3). This step can be transparent to the user 103, for example if the user 103 previously accepted to get the OS update. The end user can perform a gesture (which can be any of the following: a specific menu in the LPA; flashing a QR code; clicking on a link; ...) that triggers a connection of the LPA 105 (through an ES9+ connection) to the scripting platform 104 (seen as a regular SM-DP+).

[0033] The EUM, MNO, or OEM can also directly trigger the connection of the LPA 105 (through an ES9+ connection) to the scripting platform 104.

[0034] The OS update platform 104 (labeled "script platform" in the figure) uses LPA 105 to expose the same ES9+ interface as SM-DP+.

[0035] In steps 4 and 5, the LPA connects to the scripting platform using the ES9+SM-DP+ protocol, and the scripting platform requests to create an ISD-P 107 (ES3.CreateISDP).

[0036] In step 6, the LPA 105 downloads the OS update script into the secure element ISD-P 107. In the proposed solution, the LPA only relays the message.

[0037] The script platform 104 then (after the user's 103 optional agreement in step 7) performs an ISD-P key establishment with the ISD-P 107 on the secure element 106 through the LPA 105. This generates an SCP03 keyset (or SCP03t) known only by the script platform 104.

[0038] This keyset can be used to secure an SCP03 or SCP03t script.

[0039] The script platform 104 then generates or formats the OS update script, adds one or more signed tokens to the OS update script, and secures the OS update script using SCP03 or SCP03t (see below description of scripts and signed tokens). The OS update script may have been previously secured using SCP03 / SCP03t as well.

[0040] In step 8, the script platform 104 sends the secured script to the LPA 105 using the ES9+ protocol.

[0041] In step 9a, the script platform 104 sends an OS update script to the secure element 106 using the ES8+ protocol. This script is received by the ISD-P 107 and sent to the OS system 115, which instructs the OS system 115 to install the patch 110 in the OS patcher 114 (step 9b). The OS of the secure element is then updated.

[0042] In step 10, after the execution of the script storage or the script execution, the secure element 106 returns the execution result to the LPA 105, which forwards it to the script platform 104. This is also done by using the ES8+ protocol.

[0043] In step 11, after executing the script if executed immediately, the eSIM may automatically remove the ISD-P 107. This is transparent to the LPA and the user 103.

[0044] Alternatively, the secure element prohibits the ISD-P 107 from being enabled unless this ISD-P 107 is removed.

[0045] The OS update script is: - A proprietary command concatenated and secured within SCP03t, where the first command is a proprietary command indicating the nature of the script (e.g. "InstallOSPatch") instead of the SIMAlliance Profile Package Profile header, or - regular SIMAlliance profile packages secured in SCP03t, including proprietary EFs which themselves contain proprietary commands (in a consumer eUICC architecture, scripts cannot be proprietary APDUs secured by SCP03, since the Script Platform / SM-DP+ cannot send APDUs to the eUICC, which is one of the reasons why the solution described by WO2020 / 201313 is not directly applicable); - Regular APDUs, and optionally proprietary APDUs, secured using SCP03, or - The usual SIMAlliance profile package secured with SCP03t, including the PE non-standard which itself contains proprietary commands It may consist of any one of the following.

[0046] In all cases the script can contain a few quality control (QC) instructions at the end to allow checking that the script is executed / stored correctly.

[0047] The PE non-standard content may itself be encrypted.

[0048] Preferably, the original equipment manufacturers of the devices that comprise the terminal are notified that an OS update script is available. This original equipment manufacturer can be the manufacturer of the modem of the vehicle or the smartphone. It is then possible to install the OS patch on the server of the vehicle manufacturer or on the smartphone. These original equipment manufacturers can then decide whether they want to install the OS patch in their devices or not.

[0049] The invention also relates to a system comprising an OS update platform exposing the same ES9+ interface as SM-DP+, the system comprising a secure element cooperating with a terminal, the secure element and the terminal being comprised in a device, the secure element being able to update the OS script upon receiving an OS update script of an OS update platform of a secure element manufacturer of the secure element, the terminal comprising an LPA: - The LPA is triggered to connect to the OS update platform by using the ES9+SM-DP+ protocol; - the LPA downloads the OS update script into the ISD-P of the secure element and installs the OS update script into the ISD-P of the secure element; After the installation of the OS update script in the ISD-P, the secure element returns the execution result to the OS update platform through the LPA.

[0050] The invention also relates to a secure element cooperating with a terminal, the secure element and the terminal being comprised in a device, the secure element being able to update the OS script upon receiving an OS update script of an OS update platform of a secure element manufacturer of the secure element, the terminal comprising an LPA: - The LPA is triggered to connect to the OS update platform by using the ES9+SM-DP+ protocol; - the LPA downloads the OS update script into the ISD-P of the secure element and installs the OS update script into the ISD-P of the secure element; After the installation of the OS update script in the ISD-P, the secure element returns the execution result to the OS update platform through the LPA.

[0051] This is done thanks to an applet installed in the secure element.

[0052] With regard to signed tokens, the script platform 104 can insert a signed token into the script, which will allow the secure element to verify that the script has been authorized by one or more actors, as described below: - one token can be a DLOA issued by a certification authority that delivers a DLOA (Digital Letter of Approval) only after verifying compliance to ensure that only security certified scripts are executed, the DLOA can be verified by the certification authority's PK stored in the eSIM's ECASD; - one token can be a signature using a shared key or key pair known only by the EUM to ensure that only scripts generated by the EUM system are executed, the signature can be for example signed by the EUM's SK.EUM.ECDSA or SK.ECASD.ECDSA known by the EUM and verified with the corresponding PK stored in the eSIM's ECASD; - one token can be multiply signed by each of the MNOs owning profiles installed on this secure element and verified using the well-known key set version number and the corresponding PK stored in the key index in each ISD-P or each profile to ensure that only scripts approved by the MNO involved are executed; - One token may be signed by a third party key if the script was generated by the service provider and verified using a key stored in the ECASD or in the service provider's security domain to ensure that only known third parties can affect the eSIM's OS.

[0053] Further controls may be used: The eSIM 106 can check that the scripting platform 104 certificate used for “common mutual authentication” or for “profile binding” identifies a well-known and authorized scripting platform 104 (e.g., by checking the OID of the platform’s certificate); - OS scripts may specify an OS version, and the eSIM 106 will check that the version matches its current status and will reject the script if it does not match.

[0054] To simplify the user experience, the script platform 104 or the actor wanting to trigger patching can dynamically trigger the download and execution of the script using SM-DS or a push service or a mechanism based on RPM (Remote Profile Management). This would mean replacing steps 2 and 3 by a call to SM-DS (Subscription Manager Discovery Server).

[0055] For transparency purposes, the script platform 104 can mark in the profile metadata that the profile (actually the OS patch script) is a test profile. In this case, especially when linked to step 4, installation and removal can be done silently without risking to show the "Profile" as a normal profile in the LPA.

[0056] In the above described sequence, the LPA 105 does not need any proprietary features: as soon as the LPA 105 can interact with the SM-DP+, it can interact transparently with the script platform 104.

[0057] The intention is not to hide patching from the user, but to allow patch deployment without specific development on the device side.

[0058] Certain developments may still be performed within the device (particularly within the LPA 105) to make the installation completely transparent to the end user (automatic maintenance of the OS, or automatic OS updates performed along with device OS updates) or to provide a more user-friendly user interface rendering of the patch process.

[0059] It is also possible to download EUM patches via any SM-DP+ and store the patch script until delivery, as long as the SM-DP+ accepts to consider the patch script as a profile script.

[0060] The present invention applies to the GSMA eSIM specification RSP for consumer eUICC: SGP.22.

Claims

1. 1. A method for updating an OS (115) installed in a secure element (106) via an OS update platform (104) exposing the same ES9+ interface as SM-DP+, the secure element (106) being an eUICC or iUICC, the secure element (106) cooperating with a terminal, the secure element and the terminal being comprised in a device; loading an OS update script (102) into the OS update platform (104) of the manufacturer (100) of the secure element (106); Triggering the LPA (105) of the terminal to connect to the OS update platform (104), said connection using the ES9+SM-DP+ protocol defined by GSMA; downloading the OS update script (102) by the LPA (105) into an ISD-P (107) of the secure element (106) and installing the OS update script (102), the installing resulting in the update of the OS (115); After the execution of the installing, returning an execution result by the secure element (106) to the OS update platform (104) through the LPA (105). A method comprising:

2. The method of claim 1 , wherein the method includes notifying an original equipment manufacturer of a device that comprises the terminal that an OS update script is available.

3. The method according to claim 1 or 2, wherein the ISD-P (107) in the secure element (106) is deleted after the installing.

4. The method according to claim 1 or 2, wherein the secure element prohibits the ISD-P (107) from being enabled if the ISD-P (107) is not removed.

5. The method according to any one of claims 1 to 4, wherein the loading of the OS update script comprises several steps of dynamic generation depending on the characteristics of the secure element (106).

6. A system comprising an OS update platform (104) exposing the same ES9+ interface as SM-DP+, comprising a secure element (106) cooperating with a terminal, said secure element (106) and said terminal being comprised in a device, said secure element (106) being able to update an OS upon receiving an OS update script of an OS update platform of a manufacturer (100) of said secure element (106), said terminal comprising an LPA (105); the LPA (105) is triggered to connect to the OS Update Platform by using the ES9+SM-DP+ protocol defined by GSMA; The LPA (105) downloads the OS update script into the ISD-P of the secure element (106) and installs the OS update script, the installation resulting in an update of the OS (115); After executing the installing, the secure element (106) returns an execution result to the OS update platform through the LPA (105).

7. A secure element (106) cooperating with a terminal, the secure element (106) and the terminal being comprised in a device, the secure element (106) being capable of updating an OS upon receiving an OS update script of an OS update platform (104) of a manufacturer of the secure element (106), the terminal comprising an LPA (105); said LPA (105) is triggered to connect to said OS Update Platform (104) by using the ES9+SM-DP+ protocol defined by GSMA; The LPA (105) downloads the OS update script into the ISD-P (107) of the secure element (106) and installs the OS update script, the installation resulting in an update of the OS (115); After performing the installing, the secure element (106) returns an execution result to the OS update platform (104) through the LPA (105).

8. The secure element (106) of claim 7, wherein the secure element (106) is an eUICC or an iUICC.

Images