Secure elements are small devices comprising a memory, a microprocessor and an operating system for computing treatments. Such secure elements may comprise a plurality of memories of different types, like non-volatile memory and volatile memory. They are called “secure” because they are able to control the access to the data they contain and to authorize or not the use of data by other machines. The secure elements may also provide computation services based on cryptographic components. In general, secure elements have limited computing resources and limited memory resources and they are intended to be connected to a host machine which provides them with electric power. Secure elements may be removable or fixed to a host machine. For example, smart cards are a kind of secure elements.
A secure element may contain applications and their associated applicative data which encompass user data, file systems and secret key. Such an application may be developed as a package or a set of packages which is stored into the secure element. One or several instances of the application are then created as needed. Each instance owns, handles and store its own instance data.
Secure elements may be accessed by a remote server via a wireless channel or through a wired network, like Internet for instance. For example, secure elements which are intended to be used in Telecom domain or Machine-To-Machine (M2M) domain are able to manage an OTA (Over-The-Air) channel. These secure elements may also be accessed through the HyperText Transfer Protocol, usually called HTTP or HTTPS for the secure mode. Thus, a distant server can remotely manage the content of a secure element like an UICC (Universal Integrated Circuit Card) through a dedicated communication session using a specific protocol. For example, the server may use the RAM (Remote Applet Management) mechanism as defined by GlobalPlatform® v 2.2 standard—Amendment B “RAM over HTTP” or the OMA-DM (Open Mobile Alliance—Device Management) protocol as defined by OMA-TS-DM V1.2.1 standard.
According to JavaCard™ specifications, a package may be loaded in a secure element through a CAP file. The package generally comprises several classes. When an application is installed from the package, an instance of a class is created. This instance corresponds to an object.
JavaCard™ objects are not created each time a JavaCard™ OS or a JavaCard™ applet is started. They are created once (for example when a JavaCard™ applet is installed, personalized, etc.) and then become persistent, except if deleted, for the rest of the life of the JavaCard™ OS or the JavaCard™ applet. A remote server can send a new version or an upgrade of the operating system of the secure element. In this case, the existing objects (e.g. existing instances of class) must be re-instantiated when the operating system has been updated. In other words, new instances of class corresponding to the old ones must be instantiated in the new operating system context in order to re-create the previously existing objects. This instantiation is carried out from the packages stored in the secure element. It is to be noted that old class instances are no more used or even deleted and their content is lost in the new operating system context.
The re-instantiation of object from a package may require time and a large part of the available computing resources of the secure element. This problem is exacerbated when a large number of objects (i.e. class instances) must be re-created in a secure element. Moreover, the remote server may have no access to the relevant package if this package has been installed by another entity like a third party.
There is a need for allowing to maintain existing objects in a functional state when the operating system of a secure element is updated.
USPTO Backgrounds
USPTO Backgrounds