The present invention relates to methods of managing a secure element. It relates particularly to methods of handling software applications installed in a secure element when a change of operating system occurs.
A secure element is either a tamper-resistant physical component able to store data and to provide services in a secure manner or a software component emulating such a component and providing a trusted storage area and trusted services. A secure element has an operating system configured to deny access to its resources to an entity which is not entitled. In general, a secure element has a limited amount of memory, a processor with limited capabilities and is devoid of battery. For instance a UICC (Universal Integrated Circuit Card) is a secure element which embeds SIM applications for telecommunication purposes. A secure element can be installed, fixedly or not, in a terminal, like a mobile phone for example. In some cases, the terminals are constituted by machines that communicate with other machines for M2M (Machine to Machine) applications.
A secure element can be in the format of a smart card, or may be in any other format such as for example but not limited to a packaged chip as described in PCT/SE2008/050380, or any other format.
It is known to solder or weld the secure element in a host device, in order to get it dependent of this host device. This is done in M2M (Machine to Machine) applications. The same objective is reached when a chip (a secure element) containing an application is contained in the host device. The chip is for example soldered to the mother-board of the host device or machine and constitutes an embedded-secure element (eSE).
A removable secure element uniquely associated with its hosting device may also be considered as an embedded-secure element.
Applications may be downloaded and installed in a secure element. Usually, an application is linked to the operating system. For instance, the executable part of an application may call specific functions of the operating system. Due to the increasing lifetime of secure elements, the need to change the current operating system may occur after a large number of applications has been installed in the secure element. In this case, the user of the secure element may want to keep these applications even in case of replacement of the operating system by a new one. Unfortunately, the links between the applications and the replaced operating system will be lost when the replacement happens.
There is a need to maintain applications in a functional state after replacing the operating system of a secure element.
An object of the invention is to solve the above mentioned technical problem.
The object of the present invention is a method for managing a secure element comprising a first operating system and a software application including an executable part. The executable part is tied to said first operating system through a plurality of links. The method comprises the steps:
Advantageously, the description may comprise, for each links of said plurality of links, a couple made of an identifier of a calling point in said executable part and its linked called item.
Advantageously, the secure element may check the validity of credentials associated with the un-map command and deny execution of the un-map command in case of unsuccessful checking.
Advantageously, the software application may include at least one object linked to the executable part, on receipt of the un-map command, the executable part may be moved to the memory area and the link between said at least one object and the executable part may be updated.
Advantageously, the un-map command may specify an identifier of the applications to be un-mapped.
Advantageously, the secure element may include a list comprising an identifier of the applications to be un-mapped and the list may be either updated in the secure element each time a new application is installed in the secure element or updated in the secure element by an external entity.
Another object of the invention is a secure element comprising a first operating system and a software application including an executable part. The executable part is tied to the first operating system through a plurality of links. The secure element comprises:
Advantageously, the description may comprise, for each link of said plurality of links, a couple made of an identifier of a calling point in said executable part and its linked called item.
Advantageously, the secure element may include a list comprising an identifier of the applications to be un-mapped.
Advantageously, the secure element may include a black list comprising an identifier of the applications which are not authorized to be un-mapped and the translating agent may be configured to ignore the applications belonging to the black list.
Other characteristics and advantages of the present invention will emerge more clearly from a reading of the following description of a number of preferred embodiments of the invention with reference to the corresponding accompanying drawings in which:
The invention may apply to any types of secure element intended to store software applications. The secure element may be coupled to any type of host machine able to establish a communication session with the secure element. For example, the secure element may be embedded in a the host machine like a mobile phone, a tablet PC, an electronic pair of glasses, an electronic watch, an electronic bracelet, a vehicle, a meter, a slot machine, a TV, a gaming device or a computer.
In this example, the secure element SE is an embedded UICC (eUICC) which comprises a working memory of RAM type, a processing means, a non-volatile memory ME and a communication interface for exchanging data with a host device.
The secure element is shown after the replacement of the operating system, in a state in connection with
The non-volatile memory ME comprises a memory area MR, an admin agent AA and an operating system OS2.
The memory area MR comprises two applications AP1 and AP2 and a link description DT. These applications may be Javacard applets and the operating system OS2 may comprise a Javacard® virtual machine. Typically, each application comprise an executable part and one or several objects. For example, the application AP1 may comprise an executable part EX-AP1 and two objects OB-AP1-01 and OB-AP1-02. These objects may comprise data personalized for the user of the secure element, and sensitive data like secret keys or certificates for instance.
The admin agent AA is configured to replace the current operating system by a new operating system while keeping the memory area MR unchanged.
Advantageously the location of the memory area MR may be predefined in the admin agent AA. Alternatively, the current operating system may comprise a mechanism allowing to specifies the boundaries/constraints of the memory area MR and then post this information to the admin agent AA (through a shared memory for instance). With these constraint information, the admin agent AA is able to forbid any memory area MR update tentative. For instance, such a watchdog mechanism can be implemented using the MMU (Memory Management Unit) of the chip.
The operating system OS2 comprises a translating agent TA which is adapted to record in the memory area MR a description of the links between an application and an operating system using an intermediate language. More precisely, the translating agent TA is adapted to record a description of the links between the executable part of an application and the current operating system. This description is recorded in the link description DT. The translating agent TA is configured to run on receipt of the un-map command.
Advantageously, the link description DT may comprise, for each link, a couple made of an identifier of a calling point in the executable part of the application and its corresponding linked called item.
For instance, for the call of the “arrayCompare” method by the application, the identifier of the calling point may be described as an offset from the memory area MR or as a memory address and the linked called item of the operating system may be described using the name of the called item: “AID=Javacard.framework+Method=“arrayCompare”, for instance, or using a hash of the combination package+method.
In case the previous and new operating systems are similar enough, the linked called item may be described using an index, like “AID=Javacard.framework+3”, meaning that the third method of the package Javacard.framework must be linked (assuming that the third method if the “arrayCompare” method).
The link from the application to the operating system could be directly replaced into the application itself by a link from the application to the link description DT that could store the description of the called item.
A link may relate to an executable Code like exemplified above. Thus, the link may be a Call reflecting the fact that the application invokes a method located into the operating system. A link may also relate to a non-executable data. In this case, the application access (read/write) some data located into the operating system. For example, in Java, an application can access some ‘static field’ data of the operating system. For instance, in the operating system class java.javacardx.biometry.BioBuilder, an application can access the static field ‘FINGERPRINT’.
Advantageously, the translating agent TA may be configured to check the validity of credentials associated with the un-map command and to deny execution of the un-map command in case of unsuccessful checking. For instance, a secret code (like a PIN code) may be passed as input parameter of the un-map command. In another example, the translating agent TA may be adapted to check that the relevant credentials have been previously granted in the secure element SE. (for instance an Administration code have been successfully presented).
In one example, the un-map command specifies a set of applications to be un-mapped. For instance, the un-map command may convey the identifier of the targeted applications.
In another example, the secure element SE stores a list comprising an identifier of all the applications to be un-mapped and the translating agent TA is configured to record a description of the links for all applications of this list.
The secure element SE may be adapted to automatically update the list each time an application is installed or removed. Alternatively, the list may be updated by an external entity like a remote administration server.
Advantageously, the secure element SE may store a black list comprising an identifier of the applications which are not authorized to be un-mapped and the translating agent TA may be configured to ignore the applications belonging to the black list when updating the link description DT.
Anyway, the applications for which the translating agent TA does not record the links in the link description DT will become unavailable after the installation of the new operating system.
The translating agent TA may be configured to move the executable part of the applications in the memory area MR.
The translating agent TA may be also configured to move the objects of the applications in the memory area MR. These objects are linked to the executable part of the application. Preferably, the secure element SE is configured to automatically update the links between the executable part and the objects of each moved application.
Although the operating system OS2 of
The operating system OS2 comprises a mapping agent MA adapted to restore a new set of links between the executable part of an application and the current operating system based on the link description DT on receipt of a re-map command.
The mapping agent MA is configured to analyze the link description DT and to create new links toward the new operating system.
For example, the mapping agent MA may get the list of applications to re-map by parsing the memory area MR and discovering these applications or by reading a preset field which contains the list of applications in the memory area MR. The location of the memory area MR may be predefined in the mapping agent MA. Alternatively, the mapping agent MA may be adapted to get the location (and size) of the memory area MR by reading at a preset address in the memory ME or through a shared memory.
It is to be noted that the translating agent TA and the mapping agent MA may be implemented as independent software components or as a single software component.
The memory ME contains, from bottom to top, the admin agent AA, the operating system OS1, the executable part EX-AP2 of the application AP2, the executable part EX-AP1 of the application AP1, a free area, an object OB-AP2-01 of the application AP2, an object OB-AP1-02 of the application AP1, another free area and an object OB-AP1-01 of the application AP1.
In this example, the applications AP1 and AP2 have been treated by the translating agent TA and their components (executable parts & objects) have been moved in the memory area MR so as to form a compact structure. The translating agent TA has created the link description DT in the memory area MR.
The admin agent AA and the operating system OS1 are kept unchanged.
At this stage, the applications AP1 and AP2 are still functional. They can be selected and executed in the framework of the operating system OS1.
Advantageously, the translating agent TA may delete the links between the applications and the current operating system. In this case, the applications AP1 and AP2 are disabled because their links with the current operating system have been removed. They cannot be selected and thus cannot be executed even if the operating system OS1 is still active.
The admin agent AA and the content of the memory area MR are kept unchanged.
The operating system OS1 has been replaced with the operating system OS2 by the admin agent AA. It is to be noted that the memory sizes required by these operating systems may be different.
It is to be noted that the admin agent AA does not modify the memory area MR when installing the new operating system.
The admin agent AA, the operating system OS2 and the application objects are kept unchanged.
The link description DT has been deleted for saving memory space.
The executable parts of applications have been moved near the operating system OS2. This moving allows to place the memory ME is a state similar to the initial state where the main free area is placed between the executable parts and the objects of applications. Alternatively, the executable parts of the applications may remain stored in the memory area MR.
At this stage, the applications AP1 and AP2 are fully functional again. They can be selected and run.
Thanks to the invention, the applications have been safely managed into the secure element by keeping them onboard. There is no need to temporary store these applications outside the secure element.
An advantage of the invention is to manage legacy applications without requiring any new specific design for the applications.
It must be understood, within the scope of the invention that the above-described embodiments are provided as non-limitative examples. In particular, the secure element may comprise any number of applications and the link description may be may be implemented using any appropriate coding rules or conventions.
The architecture of the secure element SE shown at
The invention is not limited to operating systems having a Javacard© virtual machine and may apply to any kind of operating systems.
The secure element SE is not necessarily a eUICC and can be, for example, a smart card, a removable/welded hardware component, an embedded secure element or, a USB token or a microSD© token.
Number | Date | Country | Kind |
---|---|---|---|
15305607 | Apr 2015 | EP | regional |
Filing Document | Filing Date | Country | Kind |
---|---|---|---|
PCT/EP2016/056412 | 3/23/2016 | WO | 00 |
Publishing Document | Publishing Date | Country | Kind |
---|---|---|---|
WO2016/169722 | 10/27/2016 | WO | A |
Number | Name | Date | Kind |
---|---|---|---|
9198024 | Khalid | Nov 2015 | B1 |
20040255263 | Ando | Dec 2004 | A1 |
20070277168 | Vetillard | Nov 2007 | A1 |
20090204806 | Kanemura | Aug 2009 | A1 |
20100218197 | Takeuchi | Aug 2010 | A1 |
20110145586 | Meyn | Jun 2011 | A1 |
20110209220 | Tikkanen | Aug 2011 | A1 |
20120060168 | Lee, II | Mar 2012 | A1 |
20120143929 | Baratakke | Jun 2012 | A1 |
20130060959 | Taveau | Mar 2013 | A1 |
20130067238 | Homme | Mar 2013 | A1 |
20130303146 | Van Voorhees | Nov 2013 | A1 |
20140020049 | Smith, III | Jan 2014 | A1 |
20140025940 | Giraud et al. | Jan 2014 | A1 |
20140096014 | Johnson | Apr 2014 | A1 |
20140324698 | Dolcino | Oct 2014 | A1 |
20150220729 | Rudolph et al. | Aug 2015 | A1 |
20150350881 | Weiss | Dec 2015 | A1 |
20150363765 | Alimi | Dec 2015 | A1 |
20150371226 | Hurley | Dec 2015 | A1 |
20150373778 | Holtmanns | Dec 2015 | A1 |
20160027033 | Lobmaier | Jan 2016 | A1 |
20160063480 | Ballesteros | Mar 2016 | A1 |
20160063490 | Ziat | Mar 2016 | A1 |
20160078397 | Barton | Mar 2016 | A1 |
20160095044 | Maria | Mar 2016 | A1 |
20160117660 | Prakash | Apr 2016 | A1 |
20160132875 | Blanco | May 2016 | A1 |
20160171207 | Chen | Jun 2016 | A1 |
20160234013 | El-Marouani | Aug 2016 | A1 |
20160274920 | Berthet | Sep 2016 | A1 |
20160295344 | Danree | Oct 2016 | A1 |
20160335433 | Dabosville | Nov 2016 | A1 |
20160344710 | Khan | Nov 2016 | A1 |
20160375733 | Lesesky | Dec 2016 | A1 |
20170055101 | Studerus | Feb 2017 | A1 |
20170109546 | Nerot | Apr 2017 | A1 |
20180225717 | Storti | Aug 2018 | A1 |
Number | Date | Country |
---|---|---|
0 688 010 | Jan 2014 | EP |
0 864 650 | Jul 2005 | FR |
WO 2008123827 | Oct 2008 | WO |
WO 2014023394 | Feb 2014 | WO |
Entry |
---|
International Search Report (PCT/ISA/210) dated Jun. 9, 2016, by the European Patent Office as the International Searching Authority for International Application No. PCT/EP2016/056412. |
Written Opinion (PCT/ISA/237) dated Jun. 9, 2016, by the European Patent Office as the International Searching Authority for International Application No. PCT/EP2016/056412. |
Number | Date | Country | |
---|---|---|---|
20180107822 A1 | Apr 2018 | US |