Patent Description:
Smart cards are widely used in a variety of systems such as mobile phones, payment cards, access cards, to provide identification, authentication, data storage and application processing.

Where the smart card contains security-critical applications and sensitive data, such as in the case of payment cards and the like, a secure element is used to store the data. A secure element is a tamper resistant element, TRE, that provides a secure memory and execution environment in which application code and application data can be securely stored and administered. The secure element ensures that access to the data stored on the card is provided only when authorized.

Such a secure element may exist in any form factor such as UICC, embedded SE, smartSD, smart microSD, etc..

A secure element may include one or more security domains (SDs), each of which includes a collection of data, such as operating system, personalization data, packages, applets, applications, and the like, which are authenticated using security keys. Thus, the operating system and applications are stored within the secure element in volatile and non-volatile memory modules, and are executed in a secured processor of the secure element.

The operating system of a secure element provides basic functionality to network access applications associated with a given operator, such as secure access to on-card storage, authentication and encryption.

<CIT> describes systems, methods, and computer-readable media for logging secure element updates of an electronic device. In one example embodiment, a method, at a secure element including a previously-installed secure element asset, includes, inter alia, receiving an update package, uninstalling the previously-installed secure element asset based on the received update package, installing a new secure element asset based on the received update package, and updating at least one of a counter on the secure element and a log on the secure element based on the installation of the new secure element asset.

<CIT> describes a secure element including a boot program comprises instructions for the execution a startup step to determine if a non-volatile memory stores an active operating system, and, in the affirmative, to launch execution of the operating system, an authentication step of a updater device, as a function of first authentication data determined by a secure element and second authentication data received from the updater device, and, in response to the authentication step, a storage step of a new operating system received from the update, device in the non-volatile memory and an activation step of the new operating system, when said instructions are executed by a microprocessor.

Recent smart card architectures allow loading several operating systems within a secure element, and thus the co-existence of multiple operating systems within the secure element. Although such solutions provide flexibility when deploying a secure element in the field, they require a high amount of memory within the secure element for hosting multiple operating systems.

As the size of the secure elements currently available is relatively small and the secure elements have only a limited storage capacity, loading multiple operating systems onto a secure element would be viable only for very small operating systems with limited functionality.

It is therefore desirable to provide a solution for managing multiple operating systems for a secure element which addresses the above-mentioned drawbacks.

The present invention addresses the above object by the subject-matter covered by the independent claims.

According to a first aspect of the present invention, there is provided a method for managing a plurality of operating systems for a secure element by an update agent within the secure element. More specifically, the method comprises identifying a first operating system, OS1, being actively used by the secure element and identifying inactive operating systems within the secure element, which are not actively used by the secure element. If inactive operating systems have been identified, the update agent allocates these inactive operating systems to a storage provider.

By keeping only the active operating system within the secure element and outsourcing all inactive operating systems to a storage provider, that is, to a memory space outside the secure element, internal memory of the secure element is efficiently used. This allows to provide the secure element with larger operating systems with more differentiated functionality, as only one operating system is stored at a time within the secure element, while the remaining inactive operating systems are kept externally and ready for being (re-)loaded onto the secure element on demand.

In some embodiments of the present invention, identifying an operating system as active or inactive comprises checking a status indicator of the operating system, wherein the status indicator is a data structure located on the se-cure element and storing for each operating system of the plurality of operating systems a corresponding status.

In some embodiments of the present invention, the method comprises further receiving a request to load a second operating system, OS2, as a new active operating system on the secure element; performing a secure backup of the first operating system, OS1; and loading the second operating system, OS2, onto the secure element.

In some embodiments of the present invention, not only the active operating system is backed-up in a secure manner upon receiving a request to load or switch to another operating system, but also all the inactive operating systems which were initially in an inactive state within the secure element.

Performing a secure backup has the advantage that the outsourced operating systems are protected from accidental data loss, corruption, and unauthorized access.

Preferably, performing a secure backup of an operating system, the operating system being the first (active operating system) or one of the inactive operating systems, comprises creating an image of the operating system, and providing the operating system image to the storage provider to be stored thereon.

Preferably, the operating system image is created by encapsulating the operating system and securing it with cryptographic keys. Preferably, the encapsulated operating system is encrypted according to a predetermined security scheme and by cryptographic keys and/or key sets supported by the update agent.

By encapsulating the current software version and encrypting it with the up-date agent's private cryptographic key, a tamper resistant secured image of the operating system is obtained, reducing thus the risk of the backup operating systems being manipulated by a third party while being stored outside of the secure element.

In some embodiments of the present invention, when the second operating system is loaded, the update agent checks first whether there is a backup version of the second operating system already allocated within the storage provider. If there is such a backup version is allocated within the storage provider, the update agent retrieves the backup version, and replaces the first operating system with the backup version of the second operating system. The second operating system becomes thus the first currently active operating system loaded onto the secure element.

This allows a secure element having limited memory space to switch between various operating systems stored externally and to revert to a previously used operating system without being dependent on the free memory in the secure element.

In some embodiments of the present invention, if there is no backup version of the second operating system allocated within the storage provider, the update agent downloads the second operating system onto the secure element and replaces the first operating system with the downloaded second operating system. Preferably, the replacement step comprises installing the second operating system onto the secure element and deleting the first operating system from the secure element. As the first operating system has already been securely backed up within the storage provider, the first operating system can be deleted from the secure element, and the second operating systems becomes the new active operating system in use on the secure element.

Preferably, the update agent sets, upon downloading the second operating system or its backed up version, the status of the second operating system to active and the status of the first operating system to inactive.

In some embodiments of the present invention, the storage provider is at least one of the following: an electronic device the secure element is embedded on, a server, or a network cloud.

According to a second aspect of the present invention, there is provided an update agent for managing a plurality of operating systems for a secure element. The update agent is configured to perform the steps of identifying a first operating system, OS <NUM>, being actively used by the secure element; identifying inactive operating systems within the secure element, which are not actively used by the secure element; and allocating the inactive operating systems to a storage provider.

Preferably, the update agent is configured to perform the method according to the first aspect.

Preferably, the update agent is configured after loading the second operating systems or the backed up version thereof, to set the status of the second operating system to active and the status of the first operating system to inactive.

According to a third aspect of the present invention, there is provided a secure element, SE, comprising an update agent according to the second aspect of the present invention. Preferably, the update agent is configured to perform the method according to the first aspect.

According to a further aspect of the present invention, there is provided an apparatus, comprising at least one processor, at least one memory including computer program code, and the at least one processor with the at least one memory and the computer program code, being arranged to cause the apparatus to at least perform identifying a first operating system, OS1, being actively used by a secure element; identifying inactive operating systems within the secure element, which are not actively used by the secure element; and allocating the inactive operating systems to a storage provider.

In a preferred embodiment the at least one processor with the at least one memory and the computer program code being arranged to cause the apparatus to perform, upon receiving a request to load a second operating system on the secure element, a secure backup of the first operating system and load the second operating system onto the secure element.

In a preferred embodiment the at least one processor with the at least one memory and the computer program code being arranged to cause the apparatus to check whether there is a backup version of the second operating system allocated within the storage provider; if there is a backup version allocated within the storage provider, retrieving the backup version, and replacing the first operating system with the backup version of the second operating system; and if there is no backup version of the second operating system allocated within the storage provider, installing the second operating system onto the secure element and deleting the first operating system.

It has to be noted that all the devices, elements, units and means described in the present application could be implemented in software or hardware elements or combination thereof. All steps which are performed by the various entities described in the present application as well as the described functionalities are intended to mean that the respective entity is adapted to or configured to perform the respective steps and functionalities.

Further aspects, features and advantages of the present invention will become apparent to those of ordinary skills in the art upon reviewing the following detailed description of preferred embodiments and variants of the present invention in conjunction with the accompanying figures.

Reference will now be made to the accompanying figures, in which:.

Detailed explanations of the present invention are given below with reference to attached drawings that illustrate specific embodiment examples of the present invention. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention. It is to be understood that the 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 present invention. In addition, it is to be understood that the position or arrangement of individual elements within each disclosed embodiment may be modified without departing from the scope of the present invention. The following detailed description is, therefore, not to be taken in a limiting sense, and the scope of the present invention is defined only by the appended claims, appropriately interpreted, along with the full range of equivalents to which the claims are entitled. In the drawings, like numerals refer to the same or similar functionality throughout the several views.

<FIG> shows the architecture of a system and flow of data for implementing a method for managing a plurality of operating systems according to an embodiment.

The system comprises a secure element <NUM> onboard in a device <NUM>, and a storage provider <NUM>.

The secure element <NUM> is for example a smart card embedded within the device <NUM>. The device <NUM> is for instance a mobile device.

The secure element SE <NUM> may comprise a microprocessor <NUM>, a communication interface <NUM>, and a memory unit <NUM>, which may comprise a volatile memory and a non-volatile memory. The microprocessor <NUM> may execute programs stored in the memory unit <NUM>. Particularly, programs may be stored in a non-volatile memory while a volatile memory is used as workspace. In particular, the microprocessor <NUM> is configured to execute a boot program during startup of the secure element <NUM>, wherein the boot program is responsible for launching execution of the operating system <NUM>.

The secure element <NUM> may communicate with the device <NUM> through the interface <NUM> and/or via an update agent handler preferably provided on the device <NUM>.

The memory <NUM> may store at least an update agent <NUM>, which is a boot loader entity allowing the provisioning of software within the SE, at least one operating system <NUM>, a cryptographic key <NUM> of the update agent <NUM>, and a status indicator <NUM> of the operating system <NUM>.

The update agent <NUM> is preferably the entry point for the software to be executed in the card respectively secure element <NUM>.

The operating system <NUM> may be responsible for executing applications stored within the secure element <NUM>, such as for example secure applications for payment services.

The status indicator <NUM> of the operating system <NUM> can take an active or inactive value. The status indicator may be implemented as a bit flag stored in the update agent <NUM>. In case the secure element hosts a plurality of operating systems the status indicator may be implemented as an array or a list, each entry therein corresponding to one of the operating systems. Alternatively, the status indicator may be stored in the operating system <NUM>.

The update agent <NUM> is the main entity in charge of the management of multiple operating systems in the secure element.

<FIG> is a flow chart which illustrates the main steps executed by the update agent for managing a plurality of operating systems for a secure element, such as the secure element <NUM> of <FIG>. <FIG> shows further steps for managing a plurality of operating systems for a secure element, according to a preferred embodiment.

The procedure starts at step S1, after a preliminary step S0 in which a startup of the secure element took place. This preliminary step may be called during the boot process by an update agent handler instructing the update agent <NUM> to perform the SE startup.

At step S1, the update agent determines if there is an operating system active. This may be implemented by the update agent checking the status indicator <NUM>, and identifying the active operating system.

If the status indicator of an operating system shows the value inactive, the update agent determines the corresponding operating systems as being inactive in step S2.

Then in step S3, the update agent <NUM> may allocate the inactive operating systems identified in step S2 to a storage provider, to be stored thereon. Preferably, the storage provider is a memory external of the secure element, such as a memory within the electronic device <NUM> the secure element <NUM> is embedded on. Alternatively, the storage provider <NUM> may be a server or a network cloud, with which the device <NUM> is able to communicate.

By identifying and allocating inactive operating systems to an external memory, internal memory on the secure element is freed up, as any not currently selected operating system is not occupying space in the SE. An inactive operating system, which has been outsourced to a storage provider, may be re-activated on demand later on.

The outsourcing procedure for inactive operating systems is depicted in <FIG>. The reactivation procedure of an outsourced operating system is depicted in <FIG>.

With reference to <FIG>, the reactivation of a backed up operating system may commence with the update agent <NUM> receiving, in step S4, a request to load a second operating system, OS2, as a new active operating system on the secure element. Before loading, that is, downloading and storing the second operating system, the update agent performs, in step S5, a secure backup of the active operating system, OS1, that is of the operating system currently in use on the secure element. In the next step S6, the new operating system is downloaded and stored within the secure element.

<FIG> shows a flow chart of a preferred implementation of step S5 in <FIG>, that is, of the step of performing a secure backup of the currently active operating system (referred to as first operating system).

With reference to <FIG>, the update agent <NUM> decides if an operating system image is created and thus may create in a first step S51 an image of the first operating system.

Preferably, the update agent <NUM> creates the OS image by encapsulating the current OS version and securing it according to a security scheme with cryptographic keys supported by the update agent <NUM> (in step S52). In step S53 the update agent <NUM> sends the encrypted OS image to the storage provider <NUM>. Preferably, this is done through the intermediary of an update agent handler via the communication interface <NUM> (c. The update agent may additionally identify the OS image as being a "backup image".

As next the update agent <NUM> may set in step S54 the status of the first OS to inactive, indicating thus that the first OS has been backed up, and hence can be removed from the memory <NUM> of the secure element <NUM>. Step S54 is optional and may be performed instead at the end of step S6, as will be described below with reference to <FIG>.

The steps performed according to the flow chart of <FIG> allow to free up memory within the SE <NUM>, allowing thus to switch to another operating system or to install a brand-new operating system, without needing additional memory on the SE.

<FIG> shows a flow chart of a preferred implementation of step S6 in <FIG>, that is, of the step of loading/installing another operating system onto the SE. This another operating system can be a new operating system or a backed up outsourced operating system.

With reference to <FIG>, in a first step S61 the update agent <NUM> checks whether there is a backup version of the second OS allocated within the storage provider.

If this is the case, the update agent <NUM> retrieves in step S62 the backed up version of the OS and replaces or switches the first OS on the SE <NUM> with the retrieved backup version in step S64.

In step S66 the update agent <NUM> may then set the status of the first OS (the one OS that was replaced) to inactive and the status of the second OS (the new OS) to active.

Deleting the first OS and setting its status to inactive only after the second OS has been successfully installed, has the advantage that in case the second OS fails to be installed, the SE is still operational as it is not left without any active OS. In case an OS is set to active but is not available on the SE <NUM>, the update agent <NUM> ensures that the OS is downloaded again.

In case that the check in step S61 revels that there is no backup version of the second OS to be newly installed, the update agent <NUM> proceeds with replacing the first OS with the second OS. Preferably this is realized by downloading the second OS in step S63 and replacing the first OS <NUM> with the downloaded second OS <NUM> within the SE <NUM> in step S65. The replacement step S65 may be implemented by installing the second OS and deleting the first OS. Preferably, as a precautionary measure, the first OS is stored until or is deleted only if the second OS is installed or at least is available and ready to be installed on the SE <NUM>. In this respect, the provision of a secure backup of the first OS, as described above in connection to <FIG>, apply here as well.

Thereafter, the update agent <NUM> may set the status of the first OS (the one OS that was replaced) to inactive and the status of the second OS (the new active OS) to active in step S67. Preferably, the second OS is downloaded from an external image providing server, which can be the same as the storage provider used for the backup of inactive operating systems. However, separate memory spaces can be provided for keeping the backed up operating systems separately from new operating systems.

<FIG> shows several stages assumed by the system of <FIG> during the execution of the above described method of managing multiple operating systems for a secure element.

The initial state I shows a view of the secure element <NUM> and the storage provider <NUM> after the method of <FIG> has been executed. In particular, in the initial state I the secure element <NUM> stores only one active operating system, the OS1 <NUM>. Other (inactive or not yet downloaded) operating systems, such as the OS2 <NUM>, are stored within the storage provider <NUM>.

Stage II shows the view of the system after the active operating system, OS1, has been backed up on the storage provider, that is, at the end of the secure backup step S5 in <FIG>. During this step the update agent has used its own private key, indicated in <FIG> by reference numeral <NUM> to create an encrypted image of OS1 <NUM>. This encrypted image is sent to the storage provider <NUM> and stored thereon as the OS1 backup <NUM>'.

Stage III shows the view of the system after the second operating system OS2 <NUM> has been loaded and installed in the place of the first OS1 <NUM> within the secure element <NUM>.

<FIG> shows a block diagram of components of an apparatus according to an embodiment. The apparatus may be a device in communication with a secure element (e.g., the SE <NUM> in <FIG>), or a device, the secure element <NUM> is embedded on, such as, for instance the device <NUM> of <FIG>. The apparatus may have a processor <NUM>, a memory <NUM> closely coupled to the processor and comprised of a RAM <NUM> and a ROM <NUM>, and optionally, a user input <NUM> and a display <NUM>. The processor may be connected to the secure element <NUM> of <FIG>, through a suitable interface, such as the interface <NUM> of <FIG>, to control the secure element <NUM>. In particular, the processor <NUM> may request the SE <NUM> to perform backup of inactive operating systems currently stored in a memory of the secure element and/or request the SE <NUM> to perform a load (re-load) of another operating system.

The methods and apparatus as described through the embodiments above, allow an update agent to keep only an active operating system stored within a secure element and to outsource inactive operating systems to an external storage. This way, any operating system not currently selected in the secure element is not occupying space in the secure element. By loading the selected operating system each time, and creating and managing backups of the other operating systems will allow secure elements with limited memory to handle multiple operating systems in a resource efficient way. A viable solution for limited space secure elements, such as lower priced platforms, is thus provided. Moreover, for high end products this solution allows the use and
switch between multiple operating systems in a single secure element without being dependent on the free space in the secure element.

Claim 1:
A method for managing a plurality of operating systems for a secure element (<NUM>) by an update agent (<NUM>) within the secure element (<NUM>), the method comprising:
- identifying (S1) a first operating system, OS1 (<NUM>), being actively used by the secure element (<NUM>);
- identifying (S2) inactive operating systems within the secure element, which are operating systems which have been loaded onto the secure element (<NUM>) and are not actively used by the secure element (<NUM>); and
- allocating (S3) the inactive operating systems to a storage provider (<NUM>), which is a memory external of the secure element,
- wherein the inactive operating systems are kept externally in the storage provider and ready for being loaded onto the secure element on demand.