Patent ID: 12254083

DETAILED DESCRIPTION

FIG.1shows a system1wherein a secure element10according to the invention is implemented. By way of illustration, the system1shown is a mobile telephone system, although the invention applies to any system using a secure element10containing one or more execution profiles.

In this example, the secure element10is an eUICC embedded in a conventional host equipment20, a mobile telephone-like device.

The secure element10can be any type of card module to be soldered or inserted in a removable manner into a secure element reader or the host device20, examples of which are an eSE, an iSE, an eSIM (for embedded SIM), an SSP (for Smart Secure Platform, examples of which are iSIM (for integrated SIM) or ieUICC (for integrated eUICC). The host device20may be any of a mobile phone (for example, cellular or smart phone), a computer (for example, a laptop), a tablet, a portable communication apparatus, a portable computing apparatus (e.g., a personal data assistant), an entertainment apparatus (for example, a music or video apparatus, or a satellite radio), or any other suitable apparatus.

In the example ofFIG.1, the telephone20is connected to an SM-DP+30 server (“Subscription Manager Data Preparation or a server for preparing data and managing subscriptions) of a mobile network, which server receives data from different operators MNO1and MNO2in order to transmit them to subscribers. According to the implementation situations of the invention, the host terminal20can be connected to different types of remote servers30. In particular, the SM-DP+ server can be replaced by two SM-DP and SM-SR servers.

The eUICC10(or more generally the secure element) includes:a processing unit12—or microprocessor;one or several non-volatile memories14for example ROM (acronym for “Read Only Memory”), Flash, EEPROM (acronym for “Electrically Erasable Read Only Memory”) or any type of hard disk;a live memory16or cache memory or volatile memory for example RAM (acronym for “Random Access Memory”) comprising registers adapted to the recording of variables and parameters during the operation of the eUICC10of the terminal20; when implementing the invention, the program instruction codes stored in non-volatile read-only memory are loaded into RAM memory with a view to being executed by the processing unit12;one or several communication interfaces18adapted for exchanging (transmitting and receiving) data with the host terminal20and/or with the remote server30via a telecommunications network and a COM communication interface of the host terminal20.

FIG.2shows an example of a high-level architecture of an eUICC10(generally a secure element) utilizing mobile telephony where it hosts several operator profiles MNO1, MNO2allowing access to the mobile network of these operators (generally it hosts one or more execution profiles enabling access to respective services).

The eUICC10comprises a runtime environment100, an ISD-R200root security domain, one or more (herein two) ISD-P profile security domains210,220corresponding to two profiles P1and P2, and an ECASD230domain.

The runtime environment100comprises, for example, the operating system OS of the eUICC10. The runtime environment100may also comprise a JCRE runtime environment (generally comprising a JCVM virtual machine) executed by the OS when the eUICC10is designed in accordance with Java Card technology.

The runtime environment100includes a telecom service102, a profile enabling service104, a profile package interpreter106, one or several resources108used by the installed profiles (for example by applications), an adaptive routine110, and a garbage collector112.

The telecom service102provides network authentication algorithms for the profiles (P1, P2) stored on the eUICC10. The profile activation service104validates and enforces profile policy rules. The interpreter106translates profile packages (typically in CAP format) received into profiles (for example P1and P2) installed on the eUICC10.

The resources108used by the profiles can be of various types: data, applications, code (interpreted or native), API (application programming interface), functions, classes (addition, deletion, or modification of fields of a class). These resources108are “adapted” using adaptive data (hereinafter “adapter”) in an implementation of the invention. In the following example, an “adaptable” resource is considered to be a Java Card class used by profiles P1and P2. Nevertheless, the invention applies to the adaptation of any resource.

The adaptive routine110makes it possible to apply adaptive data to these resources108in order to obtain adapted resources. By applying adaptive data intended for a particular profile (thus adapted to an operator), it is then possible to adapt the runtime environment100to the profile considered, making it possible to ensure and support the specific functionalities intended in this profile. Advantageously, the adaptation can be carried out on the native code of the runtime environment. As a variant, the adaptation can be carried out on interpretable code of the runtime environment.

The example proposed below is based on the adaptation of class108to different profiles, for example by adding/modifying a field or a method of class108. Of course, more resources can be adapted, which differ from one profile to another. Additionally, resources other than Java classes can be modified, for example code or data of an application loaded with the runtime environment100.

According to the invention, the adaptive routine110also makes it possible to apply inverse adaptive data making it possible to restore the resource108to its initial state. Thus, it is possible to dynamically adapt the runtime environment100to a particular profile to be used: by applying the appropriate adaptive data to obtain the adapted resources used by the profile, then by applying, at the end of use, the inverse adaptive data to restore the initial resources.

The Garbage collector112in a Java environment, allows resources specific to profiles that are no longer in use to be collected, in order to delete them (in order to free memory). This involves, for example, collecting Java objects that are no longer reachable by the methods and other objects implemented.

In a known manner, the ISD-R200enables the creation of ISD-P profile security domains210,220as well as the management of their life cycles, that is the installation of profiles P1and P2, their enabling, disabling and deletions. Commands can thus be received by the ISD-R200from the remote server30or from an action (for example input, choice, click, etc.) carried out by the user on the host terminal20, for the purpose of modifying the status of a profile.

If two execution profiles cannot be active at the same time, the enabling of an inactive profile is also interpreted as a request to disable the active profile. As a variant, two profiles can be active simultaneously, based on a same runtime environment (optionally adapted) or on different runtime environments, in which case the runtime environment is dynamically adapted in real time to the profile requesting execution.

Each ISD-P profile210or220security domain corresponds to a P1or P2profile for accessing the mobile network of an MNO1or MNO2operator. In a known manner, an ISD-P includes a certain number of elements (not shown) such as an MNO-SD (security domain of the operator containing cryptographic keys), supplementary security domains (SSD), a controlling authority security domain (CASD), applications (applets), a network access application (NAA) used to allow access to the operator's network using MNO-SD keys, profile data (including profile policy rules).

Each ISD-P profile security domain210or220(or profile P1or P2) security domain further includes an adapter211/221and an inverse adapter212/222.

The adapter211/221makes it possible to adapt the initial (or original) runtime environment100into a runtime environment adapted to the specificities of the profile P1or P2(and therefore of the associated operator). The adapter211/221corresponds to the binary difference between the initial runtime environment100and the runtime environment adapted to the specificities of the operator. The adaptation can relate to one or more execution resources108.

The inverse adapter212/222makes it possible to restore the initial runtime environment100from the runtime environment adapted by the adapter211/221. In other words, the inverse adapter212/222thus corresponds to the binary difference between the runtime environment adapted to the specificities of the operator and the initial runtime environment100that is not adapted. The restoration can relate to the adapted execution resource(s)108.

The adapters are encapsulated in directives that can be interpreted by the adaptive routine110, that is in the form of applications. Two lists of directives (corresponding to adapter and inverse adapter) can thus be stored in each profile, as objects. These objects can thus be easily recognized by the adaptive routine110as adapters to be executed. Their format (interpretable directives) advantageously makes it possible to dispense with the restrictive schemes of the background art wherein only indirections (list of certain addresses) are proposed for optional correction.

Although the profiles depicted in the figure each have an adapter and an inverse adapter, one or more profiles installed on the secure element10may have no adapter, especially if they do not require (for their use) any adaptation of the runtime environment100and its execution resources108.

In the example, a profile (herein P1) is disabled when another profile (herein P2) is enabled. Other profiles can be provided, preferably disabled for the case where only one profile is active at a time within the secure element10.

The ECASD domain230is responsible for securing the security domains200,210,220and the authentication functions of the eUICC10, by storing the keys and other certificates associated with the security domains.

By virtue of the adapter and inverse adapter according to the invention, the runtime environment100can be dynamically adapted to a particular profile to be used, without constraint for the operator of the profile. In particular, it can be adapted dynamically during profile changes, that is according to the life cycle of the various profiles stored in the secure element10.

Any type of execution resource108can be adapted dynamically, unlike known techniques generally limited only to the modification of certain predetermined resources (generally a list of possible indirections on these resources).

Appropriate management of the adapters as disclosed below (in particular using the inverse adapters to restore the runtime environment) thus makes it possible to coexist, within the same secure element10, profiles that are potentially incompatible therebetween.

FIG.3shows, using a flowchart, general steps for the deployment of adapters211,221and inverse adapters212,222in a secure element10.

Beforehand, an initial runtime environment100(for example an operating system OS and/or a Java Card system with a Java Card virtual machine) is generated (step300) for installation on secure element10(step302) according to conventional techniques. For example, the installation of the runtime environment100can be carried out, in the factory plant, during the manufacturing, pre-personalization or personalization of the secure element10. As a variant, it can be performed remotely by OTA (OTA standing for over-the-air—see for example the GSMA SGP 22 RSP standards—Technical Specification—Version 2.2.1 of Dec. 18, 2018, GSMA SGP.02—Remote Provisioning Architecture for Embedded UICC—Technical Specification—Version 4.0 of Feb. 25, 2019, GlobalPlatform Card—Remote Application Management over HTTP—Card Specification v2.2—Amendment B—version 1.1.3) via the remote server30, for example during an update of the OS or the Java Card virtual machine.

At any time, a service provider (a mobile operator in the example below) may wish to install a service profile (a P2mobile subscriber profile in the example below but which can also be a banking profile linked to a banking service, a transport profile linked to a transport service, etc.) in the secure element10. Step304and the following steps are therefore carried out as many times as there are profiles to be installed, when these require an adaptation of the runtime environment100.

To take into account the specific features of the service provided, the operator generates (step304) a runtime environment specific to this service. This specific runtime environment is referred to hereinafter as “the runtime environment adapted to profile P2”. This step can start from the initial runtime environment100as created in step300.

FIG.4shows an example of adapting an execution resource108based on Java technology, for example Java Card.

The execution resource108is herein a Java class descriptor as known in the background art, comprising for example interfaces, fields, methods and/or attributes. The Java class can be instantiated into objects used by profiles. In the example, objects A and B are two instances of the class108as provided for in the initial runtime environment100(i.e., created in step300). Objects A and B were created for profile P3, which for example implement a method of the class defined in the initial runtime environment100.

In the runtime environment specific to profile P2, the Java class descriptor is modified for example to include one or more modified interfaces, fields, methods and/or attributes that correspond to the specificities of the service of the MNO2operator of profile P2. For example, a different method (than that provided for in class108) may be required to carry out an operation of the MNO2operator's service. An instantiation of this modified or “adapted” class is carried out through the object C, created for profile P2. Object C thus includes, for example, the modified method400.

Likewise, in the runtime environment specific to profile P1, the Java class descriptor is modified to the specificities of the service of the operator MNO1of profile P1. The object D instantiated for this profile thus includes, for example, the modified method402.

Returning toFIG.3, in step306, the adapter221and the inverse adapter222specific to profile P2considered are generated. Each adapter can in particular be the binary difference between the two runtime environments generated in steps300and304: the adapter221, the difference between the initial runtime environment100and the specific (or adapted) runtime environment in step304and the inverse adapter222, the difference between the specific runtime environment of step304and the initial runtime environment100.

In the case ofFIG.4, adapter221and inverse adapter222for profile P2include the additive definition of additional components400(for adapter221) and the subtractive definition of additional components400(for inverse adapter222), respectively.

At step308ofFIG.3, the adapters generated221,222are encapsulated in directives that can be interpreted by the adaptive routine110of the runtime environment100. These directives are themselves encapsulated in step310in an application, typically a Java Card applet of type CAP file, as two additional components (“custom components” in the Java Card specification). The application may be marked, for example using a predefined header, as containing the adapters.

In step312, this application is added to a package of profile P2, this package (Profile Package according to certain SIM Alliance standards) intended to be deployed in the secure element10in the field. The creation of a profile package for its installation in a secure element and the addition of applications therein are known to a skilled person. For example, the package can be generated according to the document “SIMalliance eUICC Profile Package Interoperable Format Technical Specification”, Version 2.2.

Then the package is sent, via remote server30, to the secure element10, during step314.

The next step316takes place in the secure element10receiving the sent package within which the adapters are located. In a known manner, secure element10installs profile P2using the package received. A procedure for loading and installing a profile is for example disclosed in document “GSMA SGP.22—RSP Technical Specification”, Version 2.1 of Feb. 27, 2017.

During installation, the runtime environment recognizes the marking of the applet of the adapters. It can thus process this applet to extract therefrom the interpretable directives (representing each of the adapters221and222) and store them in connection with profile P2, for example in the ISD-P2forming this profile. In other words, adapter221and inverse adapter222are stored in the memory reserved for profile P2in secure element10.

In a variant, only the adapter221of the initial runtime environment100is generated in step306. In this variant, the inverse adapter222may be generated (and installed) by the secure element10for example during the installation of adapter221(step316) or during the first use/application of adapter221. In this case, it is the secure element10(and no longer an equipment at the plant or a remote server) that obtains the specific (adapted) runtime environment by applying the adapter received to the initial runtime environment100, and then determines the binary difference between that specific runtime environment and the initial runtime environment100to build the inverse adapter.

AlthoughFIG.3is disclosed in connection with an installation package of profile P2in the secure element, the same mechanism can be implemented with an update package of profile P2.

FIGS.5to7show, using flowcharts, the use of adapters and inverse adapters according to the enabling, disabling and deletion of the associated profiles. These figures thus show how adapters and inverse adapters are applied according to the life cycle of the profiles.

FIGS.5and6show in particular the application of the adapters to the initial runtime environment100upon enabling one of the profiles and the application of the inverse adapters to the adapted runtime environment upon disabling or deleting the profile. A dynamic and just-in-time adaptation of the runtime environment to the different profiles successively enabled (then disabled) is thus obtained, by successively applying the steps ofFIGS.5and6.

There can be as many possible adaptations of the runtime environment as there are operators (or profiles). In the example ofFIG.4, class108is used to instantiate objects A and B whereupon profile P3is active (the runtime environment not being adapted). Then profile P1is enabled (instead of P3), the runtime environment being thus adapted as a result (with adapter211adding method402) and object D is instantiated from class108modified with method402specific to P1. Then profile P2is enabled (instead of P1), leading to the application of the inverse adapter212of P1(disabling of P1) and the application of the adapter221of P2to adapt the runtime environment to P2. Object C is then instantiated from class108modified with method400specific to P2.

In step500, secure element10, and more precisely the ISD-R200, receives a command to activate a profile. In the example ofFIG.2, the command can request the enabling of the inactive profile P1. This request can also be interpreted as a command to disable, beforehand, the active profile, herein P2. In this case, the process ofFIG.6is executed for disabling profile P2before the process ofFIG.5for enabling profile P1.

Examples of command and enabling procedure (Profile Enabling) are disclosed in documents GSMA SGP.02 (“Remote Provisioning Architecture for Embedded UICC Technical Specification”, Version 3.2 of Jun. 27, 2017) and GSMA SGP.22.

In step502, the ISD-R200begins the execution of the enabling command in a conventional manner. During this execution, the ISD-R200calls the adaptive routine110on behalf of the ISD-P1. In step504, the adaptive routine110retrieves the adapter211of profile P1to be enabled (and not the inverse adapter212).

The nature of the command (enabling or disabling, for example) allows the adaptive routine110to retrieve either the adapter to adapt the initial runtime environment (enabling command) or the inverse adapter to restore it (disabling/deletion command).

The operating system of the eUICC constantly knows the current state of the runtime environment, that is which profile is active, by virtue of a stored persistent value that indicates, for example, the life cycle of the profiles. On the basis of this information, the adaptive routine110can therefore retrieve the appropriate adapter: Thus, the operating system continually knows which profile is currently active. If it appears that no profile is active and therefore that the runtime environment is not suitable, the adaptive routine110can then retrieve the adapter of the profile to be enabled in the event of an enabling command. On the other hand, if it appears that a profile is currently active, the adaptive routine110can retrieve the inverse adapter of the active profile in the event of a command to disable or delete this profile.

If no adapter is available (for example, because the profile does not require adaptation of the runtime environment), the method proceeds directly to step506. As a variant, a default adapter can be stored with the adaptive routine110(with an inverse adapter corresponding by default), whichever adapter by default is applied by the routine in the absence of a specific adapter for the profile to be enabled.

Also in step504, the adaptive routine110applies the adapter211retrieved to dynamically adapt the initial runtime environment100to profile P1. In the example ofFIG.4, class108is adapted to contain, for example, the modified method400.

In step506, the ISD-R200continues the execution of the enabling command in a conventional manner, resulting in the enabling of profile P1. The register storing an identifier of the active profile is updated (set to the value of the identifier of P1).

Profile P1can thus be used in the adapted runtime environment. The adapted runtime environment operates totally according to the characteristics of the adapter applied, ensuring that the functions or data specific to operator MNO1are available.

After use, profile P1can be disabled (for example because another profile, P2in the example, is enabled) in accordance withFIG.6. In step600, the ISD-R200therefore receives a disabling command (Profile Disabling) of profile P1.

In step604, the ISD-R200begins the execution of the disabling command in a conventional manner. During this execution, the ISD-R200calls the adaptive routine110. Either the indication of the profile (herein P1) to be disabled is indicated in the command, or the adaptive routine110can use the register storing an identifier of the active profile. In step606, the adaptive routine110retrieves the inverse adapter212of profile P1to be disabled. If no inverse adapter is available (for example, because the runtime environment did not need to be adapted to the active profile), the method proceeds directly to step608or, as a variant, the inverse adapter by default is retrieved.

Also in step606, the adaptive routine110applies the retrieved inverse adapter212in order to restore the initial runtime environment100. In the example ofFIG.4, class108is restored without the modified method400.

In step608, the ISD-R200continues the execution of the enabling command in a conventional manner, resulting in the disabling of profile P1. The register storing an identifier of the active profile is updated (set to 0).

In one embodiment, it may be beneficial to delete, from the memory, data of profile P1to be disabled. This is the case, for example, with Java objects instantiated during the use of profile P1, in order to free up memory space14that may be limited in the secure element10.

This operation is carried out by the garbage collector112. According to one embodiment, it is configured to scan only the objects of the active profile with a view for collection. Indeed, if an object comes from a class that is adapted for a profile, the structure of this object is recognized only if the runtime environment is adapted. In other words, the garbage collector112runs the risk of not recognizing the structure of an object belonging to the profile P if the runtime environment is not adapted.

Additionally, care must be taken to limit the intervention of the garbage collector112to only the current profile in order to avoid any corruption (by unwanted deletion of objects) of another profile. Also, the objects will have been created in the JCRE while respecting, preferably, a partitioning of the profiles with one another, implying in particular that no object of one profile points towards an object of another profile. This allows for a simplified cleaning mechanism while also improving profile security.

The cleaning is thus carried out at the optional step602preceding the application of the inverse adapter (step606) and consists in the ISD-R200launching an execution of the garbage collector112on behalf of the active profile (identifier indicated in the launch command or retrieved from the register storing the identifier of the active profile). This execution involves collecting instantiated objects (for example from class108but not only) for profile P1only (the one to be disabled) and then the deletion thereof. The garbage collector112does not collect herein any eventual objects instantiated for other profiles or within the JCRE.

The objects instantiated for profile P1can be those stored in a memory space reserved for the ISD-P1.

As a variant, the objects can be instantiated by the JCVM virtual machine by stamping them with a marking (or indicator) representative of their profiles. Thus, the garbage collector112can easily identify the objects linked to the profile P1to disable.

According to another variant, it is possible to keep up to date a correspondence table that lists the objects created for each profile. Thus, the garbage collector112can quickly identify the objects linked to the profile P1to be disabled.

According to another variant, it is possible to set up a set of indirections that indicates the locations (memory addresses) wherein the instantiated objects are stored for each profile.

Although this collection mechanism by the garbage collector112is presented in connection with the disabling of a profile, it can also be implemented during the deletion of a profile as disclosed below in connection withFIG.7: the objects belonging to the profile to be deleted are collected by the garbage collector and then deleted.

According to another variant, the objects created can be collected at any time for deletion, for example during a memory saturation.

In this example ofFIG.5, the adaptation is carried out only once when profile P1is enabled. As a variant, profile P1may be enabled in a conventional manner without adaptation (at this stage) of the initial runtime environment100and an adaptation using the adapter211can be initiated (steps502and504) during other events, for example each time the profile P1is accessed. Access to profile P1can take place during an authentication procedure (of a network, banking or transport service for example) or during a call to an application located in profile P1. In this variant, the initial runtime environment100can be restored (using steps602to606) at the end of these operations, e.g., of the authentication procedure or of the execution of the application located in profile P1.

FIG.7shows some steps when deleting a profile.

In step700, the secure element10, and more precisely the ISD-R200, receives a deletion command (Profile Deletion) of a profile P, for example in accordance with the GSMA documents mentioned herein before.

For efficient use of the garbage collector112, the runtime environment is adapted to the profile to be deleted. Thus, in step702, the ISD-R200calls the adaptive routine110on behalf of the profile to be deleted. In step704, the adaptive routine110recovers the adapter211or221of the profile P to be deleted (and not the inverse adapter212or222), then applies it so as to adapt the initial runtime environment100to profile P.

At step706(similar to step602disclosed herein before), the ISD-R200, which takes over, initiates an execution of the garbage collector112on behalf of the profile P to be deleted. This execution involves the collection of the instantiated objects (from a recognized class, possibly adapted) for the profile P only (the one to be deleted) and then the deletion thereof.

In step708, the ISD-R200deletes the constituent elements of profile P, in particular data and applications. During this operation, the inverse adapter212or222is added in the persistence roots of the JCRE in order to preserve it (it is not seen and therefore not deleted by the ISD-R200).

Following this deletion of the constituent elements of the profile P, the initial runtime environment100can now be restored during step710. For this to happen, the ISD-R200calls the adaptive routine110again, which retrieves the inverse adapter212or222of the profile P to be deleted, then applies it so as to restore the initial runtime environment100.

In step712, the ISD-R200deletes the inverse adapter from profile P (after removing it from the persistence roots of the JCRE). This step closes the complete deletion of profile P. The initial runtime environment100can thus regain control of the execution in the secure element10.

In one embodiment, a runtime environment cleanup routine can trigger, upon command or periodically or any other event, a cleanup operation for unnecessary objects to free up memory space, even though no profile can be active. This routine can thus successively consider all, or part of the profiles installed (for example the profile or profiles determined according to a predefined rule—by way of illustration the last profile used) and for a profile P considered:retrieving (step702) and applying (step704) the adapter of the profile P to obtain the adapted runtime environment;launching the garbage collector112(step706) to collect the objects of the profile P and delete them (step708); thenretrieving and applying (step710) the inverse adapter of profile P to restore the initial runtime environment.

The preceding examples are only non-limiting embodiments of the invention.

In particular, these examples mainly relate to a mobile phone application with subscriber profiles P1, P2, a mobile network infrastructure and mobile operators, they can be easily transposed to any type of service profile (including configurations according to GlobalPlatform), any type of remote server and any type of service provider.