Method for updating applications installed in plurality of secure elements comprised in device

Abstract

The invention proposes a method for updating an application, referred to as a previous application, installed in a plurality of secure elements (30) comprised in a device, the method comprising for each of the secure elements (30), sending, over the air, a script comprising a new ELF version comprising a latest version of the application from the update server to a system manager connected to the secure elements (30), where, for each of the secure elements (30), the script comprises:-a complete AID of the new ELF version; -identifying a partial AID of a previous application, the method comprising, for each of the secure elements (30):-for each secure element (30) and the corresponding partial AID, loading the latest version of the application identified by the complete AID, and executing the latest version of the application in each of the secure elements (30); -in the event of a failure of execution of the at least one application, for each of the secure elements (30), restoring the previous application, the complete AID for designing the application being to be updated.

Description

[0001] The present invention relates to telecommunications, and more specifically to a method for updating applications installed in at least one electronic component and in a secure element. Within the scope of the present invention, the electronic component and the secure element (such as, for example, an eSE (embedded secure element), an eSIM (embedded SIM, such as an eUICC or iUICC)) are included in a connected device, such as, for example, a refrigerator, an electricity meter, a door lock, a car, a laptop, a smartphone, a PDA, etc. The connected device includes a system manager connected to the electronic component and to the secure element. The system manager is capable of communicating with an update server (such as an OTA (over-the-air) server). This communication particularly allows, for example, regular updates of applications present in the electronic component and in the secure element.

[0002] The electronic component is typically a microprocessor containing such an application. In the automotive sector, a connected device is, for example, a car comprising such a system manager and the electronic component connected to the system manager. In certain cases, a secure element is also connected to the system manager.

[0003] Then, updating the applications involves updating (or replacing) the applications present in the electronic component and in the secure element. If necessary, all applications are updated.

[0004] The Global Platform standard, in its Amendment H (e.g., as described in "Global Platform Technology Executable Load File Upgrade Card Specification v2.3 - Amendment H Version 1.1, Public Release March 2018 - Document Reference: GPC_SPE_120"), proposes an extension to the Global Platform Card Specification to facilitate upgrades of executable load files (ELFs) present in secure elements. ELFs are executable load files.

[0005] More precisely, this amendment H proposes a solution for switching from one version of an application to another.

[0006] In this amendment H, it is precisely all modern digital devices that allow a software upgrade process, especially when there is an available network connection. There are many reasons to upgrade software: fix bugs, add new features, etc. With billions of pieces deployed, smart cards will definitely need their own software upgrade mechanism. With respect to deployment, the fundamental difference between upgrading classic software and smart card (i.e., secure element) software is the existence of persistent instances of software programs. These instances are created and personalized by the service provider using both user data and confidential or sensitive data. The personalization process can sometimes be complex and expensive, and ideally should not be repeated in the case of software upgrades. For service providers, simply deleting their applications (and related data) and then installing them again and personalizing them is not a good solution. Some of the technical characteristics of smart cards also need to be considered, which can often be limited by memory space (both RAM and NVRAM). It is very common that after personalization and deployment, smart cards have almost no memory space left. Amendment H focuses on GlobalPlatform cards that implement the Java Card specification. In particular:

[0007] - The executable file loaded is a Java Card package.

[0008] - The executable module is a Java Card applet class.

[0009] - Application is a Java Card applet instance.

[0010] Each of these is identified by an AID (Application Identifier).

[0011] This revision H specifically describes the executable loader upgrade process. The ELF being upgraded is usually referred to as the "old ELF version", and the ELF that upgrades the old ELF version is usually referred to as the "new ELF version". The ELF upgrade process basically consists of the following stages:

[0012] - Save Phase: Each existing application instance created from an old ELF version can save its instance data using the upgrade API. Registry data (instance data not directly manipulated by the application instance) is automatically saved. The old ELF version, its application instances, and their instance data are then deleted, except for the instance data saved using the upgrade API and the automatically saved registry data. The load phase can then begin immediately or be deferred and executed later.

[0013] - Loading phase: During this phase, the new ELF version is loaded. Before loading the new ELF version, library ELFs previously imported by the old ELF version and remaining unused after the old ELF version is deleted can be deleted / replaced, unrelated ELFs can be deleted / loaded, and new library ELFs (e.g., new library ELFs imported by the new ELF version) can be loaded. After loading the new ELF version, the recovery phase can begin.

[0014] -Restore phase: New application instances are automatically created from the new ELF version, with the same number and AID as the previously existing application instances. Each new application instance is allowed to restore instance data from the previous application instance with the same AID. The registry data of the previous application instance is also automatically restored and associated with the new application instance.

[0015] So, in summary, the upgrade process is divided like this:

[0016] During the preservation phase, the first revision H command (Manage ELF Upgrade [Start]) triggers the deletion of the old ELF version and associated instances while preserving the user data on the SE (Secure Element).

[0017] During the loading phase, a set of commands (regular global platform card specification commands) will be used to load the new ELF (binary code of the new package P2) on the SE.

[0018] During the restore phase, the last modified H command (manage ELF upgrade [restore]) triggers the instantiation of a new ELF and the restoration of user data in that application instance.

[0019] The problem is that Revision H doesn't offer a solution that allows you to roll back to the previous version after the upgrade is complete (there's no mechanism in Revision H to do this). One solution is to send a new Revision H script (exactly the same scenario as before, but in reverse): asking to switch from package P2 to package P1. Again, we need to know P1 (which will be the new package), its AID, and the final script.

[0020] GlobalPlatform is for secure elements with security functions within a system. Essentially, GP is for SIM cards. SIM cards are UICCs (Universal Integrated Circuit Cards). With the current evolution of UICCs, they have been replaced by eUICCs (embedded UICCs) and iUICCs (integrated UICCs). These are also eSEs (embedded secure elements) that don't perform telecommunications tasks: they are embedded in transportation applications, banking applications, electronic car key management, and more.

[0021] If a problem occurs during execution of the new ELF version of the script in one of the secure elements, a recovery process is performed and that particular secure element is restored to the previous version of the ELF.

[0022] But if the execution of the script is successful (e.g. for other secure elements in the global system), we need to run the new script in order to revert to the previous version of the ELF.

[0023] Figure 1 It is shown how the updating of an application can be implemented in a global system comprising several components including one or several secure elements to be updated according to a revision H of the GP.

[0024] In this figure, several elements are represented:

[0025] - Update server 10, usually an OTA platform;

[0026] - A global system included in a device, such as a car, including, for example:

[0027] ○ System manager 11;

[0028] o Different components (eSE) 12a to 12c.

[0029] Each component 12a-12c includes at least an application that can be updated over the air by the update server 10. Typically, such an update involves sending a script for each component 12a-12c from the update server 10 to the system manager 11, the script containing the latest version of the corresponding application. The system manager 11 is connected to the different components 12a-12c.

[0030] Here, components 12a and 12c are components that are not secure elements including sensitive data, and component 12b is a secure element including sensitive data (eg, it is an eSE).

[0031] Furthermore, each component 12a-12c has its own latest version of the application stored therein (version x, where x may be different for each component).

[0032] Updating an app involves the following steps:

[0033] At step 13, the system manager 11 queries the update server 10 whether there is a new version of the application to be downloaded to the components 12a-12c.

[0034] At step 14, the update server returns the available version of each component: version y (y may be different for each component).

[0035] At step 15, system manager 11 compares version y with version x installed in components 12a-12c. If the versions are different, system manager 11 asks update server 10 to send it update scripts, and at step 17, these scripts are sent from update server 10 to system manager 11.

[0036] The update process can then begin: at steps 18 to 20, the update scripts are sent to the different components 12a-12c. More precisely, according to revision H, at steps 18 and 20, the update scripts are sent to components 12a and 12c, and at step 19, the update script is sent to the secure element 12. Components 12a-12c then execute the scripts and send the update results at step 21.

[0037] Then, there are two alternatives:

[0038] - At step 22, all updates are OK (new version y has been successfully installed in the different components). As already mentioned, y may be different for each component.

[0039] - At step 23, if at least one update fails, a rollback process is performed:

[0040] o Components 12a and 12c are returned to their previous versions x;

[0041] o The secure element 12b returns to its previous version x by performing a rollback procedure according to revision H of GP.

[0042] The entire system is then in the situation it was in before the update process (each component is returned to its previous version after the rollback process).

[0043] However, there is a problem when the update server does not know which version of the application is installed in the component: the server may, for example, only store the latest version of the application.

[0044] This is especially true in the automotive sector: the update server has no knowledge of which cars have been sold and are currently in the field. When applications must be updated automatically or on demand by the end user, the latest versions of all applications must be downloaded to each component. The update server only has the latest versions of all applications.

[0045] about Figure 1 The problem with the described solution is that the AID of the previous ELF must be known, but the server does not know the current version of the application. And when performing a rollback process, the AID and binary code of the previous ELF must be known, but the server does not have this information.

[0046] The context of the invention is that it is desired to update the entire system including the ESE so that each component has the latest version of its application and this version must be the same for all components (if the execution of the update is successful, all components will have the latest existing version at the end of the process), otherwise if the execution of the update is unsuccessful, all components will return to their previous version x at the end of the process (x can be different for each component).

[0047] In this respect, the invention proposes a solution according to claim 1 .

[0048] The present invention will be better understood by reading the following description of the accompanying drawings, which show:

[0049] - Figure 1 represents prior art;

[0050] - Figure 2 shows how to update a secure element using the improvements of revision H according to the present invention;

[0051] - Figure 3 1 shows a rollback mechanism implemented with the improvement of modification H according to the present invention.

[0052] Figure 1 It has been described within the scope of the prior art.

[0053] Figure 2 It is shown how a secure element can be updated with the improvements of revision H according to the invention.

[0054] In this figure, a single eSE 30 is shown, but the present invention is applicable to the upgrade of the software in each secure element. Each secure element can be:

[0055] -eSE,

[0056] -UICC,

[0057] -eUICC,

[0058] -iUICC.

[0059] The secure elements are not necessarily of the same kind, but they all have security functionality, and some of them (at least one) may have telecommunication functionality (with the MNO) so that the device in which it is included can communicate with the update server.

[0060] As previously mentioned, a secure element is included in a device (eg, a car).

[0061] In the pre-update state, the eSE includes an ELF (package P1 31 ), an instance I1 32 in which the mentioned application is instantiated (executed), and user data 33 that must be preserved during all processes.

[0062] The method of the invention proposes to update the application included in the package 31, which is called the previous application. In order to update this application, the following must be taken into account:

[0063] - a script including a new ELF version containing the latest version of the application is sent to all secure elements present in the device, from the update server to the system manager connected to the secure elements;

[0064] - These scripts contain, for each of the secure elements:

[0065] o Partial AID identifying the previous application (an application that has already been installed and executed in the secure element);

[0066] ○ The full AID of the new ELF version;

[0067] ○ The latest version of the ELF binary identified by the previous full AID.

[0068] Back to Figure 2 In a first step 40 corresponding to the saving phase, the update script sends to the secure element 30 a partial AID identifying the previous application (the application already installed and executed in the secure element).

[0069] For example, the partial AID is the same as the full AID with the ELF version number missing. In other words, the partial AID does not contain any ELF version.

[0070] In a specific implementation, for a complete AID of 11 bytes, there are, for example, 9 bytes that fully identify the application type and 2 bytes that identify the application version.

[0071] In this case, thanks to the partial AID (contained in 9 bytes), the secure element 30 can identify the application to be updated.

[0072] After this step, the secure element deletes the instance 32, but keeps the package 31 including the current application and user data 33. The package 31 may be hidden by the eSE so that it cannot be used anymore unless a rollback operation is triggered.

[0073] In the next step 41 corresponding to the loading phase, the script loads a new ELF with a complete AID (AID2) identifying the new ELF version (i.e., the latest version of the application). A new package P2 34 is then created using AID2, which contains the binary code of the latest version of the application.

[0074] In the next step 42 corresponding to the recovery phase, the script loaded in the package 34 is instantiated, which generates the instance I2 35 .

[0075] If the update process is performed correctly in all parts of the device, the update is complete.

[0076] Otherwise, if execution of at least one application in the components fails, then for each of the components, the previous version of their application is restored.

[0077] This is Figure 3 , which shows a rollback mechanism for a given secure element executed with the improvements of revision H. The term "rollback" designates a method that allows to cancel all requests that have just been made.

[0078] In this diagram, we start with the latest configuration of a secure element 30, including:

[0079] -Previously package 31;

[0080] - user data 33;

[0081] - a package 34 containing the latest version of the script for the application;

[0082] -Example 35.

[0083] The rollback script according to the present invention instructs (at step 50) the secure element to delete the newly installed package (package 34) and the corresponding instance 35. This is done by requesting a rollback of the complete AID (AID2). This corresponds to the preservation phase.

[0084] The package 31 containing the previous application and user data 33 remains in the secure element 30. This means that no loading phase is required.

[0085] The next step (restore upgrade 51) requests the secure element 30 to execute the application installed in the package 31, which creates a new instance I1 32. This corresponds to the restore phase.

[0086] The secure element now contains the same components as those contained at the beginning of the update process (see Figure 2 1 ).

[0087] In summary, the present invention proposes to modify two commands in H:

[0088] - According to the invention, the first command to modify H uses a partial AID to identify the package that has to be replaced, and a new parameter in this same command indicates to the secure element to keep the old (previous)

[0089] Package. When the Secure Element sees the new command as part of the AID, it knows which package must be replaced, forms an instance (keeping the previous package and data), and then performs a GP load;

[0090] When the second modified H command is executed, the new package is installed, just as before, and this newly executed package is linked to the user data. Therefore, at the end, the new package is still present. In the case of a rollback, the old package P1 does not need to be downloaded because it already exists in the secure element.

[0091] According to the present invention, each device will receive a different script because it does not contain the same application. In contrast, for a given eSE, every device (or connected device) will receive the same update script, regardless of the current version of the application installed in that eSE. And if any of the secure elements fails to correctly execute the update script, there will be a new stage (rollback) in which all secure elements will be returned to their previous version.

[0092] In the prior art, current version and rollback management needed to be handled entirely on the server side, knowing the exact contents of each secure element in the field. This is no longer the case in the present invention, which proposes an improvement to Global Platform Revision H (executable load file upgrade).

[0093] Another advantage is that the invention simplifies version management on the update server side, since the update server only needs to know the latest version available.

Claims

1. A method for updating an application, referred to as a previous application, installed in a plurality of secure elements (30) included in a device, the method comprising sending, over the air from an update server to a system manager connected to the secure element (30), a script comprising a new ELF version containing the latest version of the application, for each of the secure elements (30), wherein the script comprises: - the complete AID of the new ELF version; - a partial AID identifying said previous application, The method comprises, for each of the security elements (30): - for each secure element (30) and corresponding partial AID, loading the latest version of the application identified by the full AID, and executing the latest version of the application in each of the secure elements (30); - in case of failure of said execution of at least one application, for each of said secure elements (30), restoring said previous application, said complete AID for designing said application being updated. The method of claim 1 , wherein the device is a connection device.

3. The method according to any one of claims 1 and 2, wherein the update server is an OTA platform.

4. The method according to any one of claims 1 to 3, wherein the security element (30) is one of the following: -eSE, -UICC, -eUICC, -iUICC.

Images