Dynamic adaptation of a secure element execution environment to profiles

Abstract

An eUICC card (10) comprises an initial runtime environment (100), subscriber profiles (P1, P2, 210, 220), associated adapters (211, 221), and an adaptive routine (110) configured to apply these adapters. An adapter allows the initial runtime environment to be adapted to the specifics of the corresponding profile when that profile is active. To allow dynamic adaptation of the runtime environment to the profiles in use, the eUICC card also includes inverse adapters (212, 222) associated with the profiles. The inverse adapter for the active profile allows the initial runtime environment to be restored when that profile is deactivated or deleted. Adaptation can consist of modifying a Java class in the eUICC Java card's runtime environment according to the specifics of a profile.

Description

technical field

[0001] The present invention relates, in general, to the field of secure elements and more particularly to the management of their execution in such elements. Previous technique

[0002] A secure element, SE, is a tamper-proof hardware component or platform (typically a chip or smart card) used in a host terminal (typically a mobile terminal) and capable of securely hosting applications and data in compliance with rules and security requirements set by trusted authorities.

[0003] An increasingly common form factor for the secure element (SE) is the embedded secure element (eSE). This embedded secure element is typically soldered to the host terminal. A more recent form factor is the integrated secure element (iSE). In this case, the secure element is an integral part of the main processor (for example, as a secure core alongside other processor cores).

[0004] The secure elements are programmed according to the desired applications.

[0005] For example, an eSE or iSE can form the secure element necessary for many uses or services relying on NFC (Near Field Communication) implemented by a host mobile terminal. For instance, an NFC payment service requires the user's confidential banking information, which is advantageously stored in the eSE, protected from unauthorized access. This is also the case for a public transport service where the eSE allows the user to be identified at fare gates.

[0006] Another example of a secure element is the embedded UICC (Universal Integrated Circuit Card), which provides a subscriber's credentials for authentication on one or more mobile networks, particularly across different operators. This could be, for example, an eSE or iSE configured as a SIM card (Subscriber Identity Module). This is then referred to as eUICC (embedded UICC) or iUICC (integrated UICC).

[0007] The main advantage of these secure elements is to offer multiple services using a single secure element. Several service providers must therefore load data and / or applications into the same secure element, allowing a user to access their services. This data and / or applications, specific to a service provider for a user, form a service profile stored in the secure element. Profiles, as defined by the GSMA RSP Technical Specification, Version 2.2 of September 1, 2017 (hereafter GSMA SGP.22), are well-known. These profiles are associated with mobile operators (service providers) and contain the user's information enabling access to their mobile phone services. Configurations, as defined by the GlobalPlatform Card Specification (Version 2.0), are also well-known.3 of October 2015) which are associated with authorities (service providers) and contain user information enabling them to access their respective services.

[0008] Each service provider has its own specific requirements that necessitate adapting the execution environment within the secure element, such as an operating system and / or a virtual machine (typically a Java Card system), to use the corresponding service profile. However, these adaptations of one or more execution resources are not necessarily compatible from one profile to another.

[0009] In general, it would be beneficial to improve the management of the execution of a secure element containing a service profile.

[0010] US publication 2010 / 012732 describes the use of corrective data or "patches" to update a smart card module after its initialization. However, this method corrects errors in the execution environment. This approach does not allow for dynamic management of the execution environment based on the execution profile(s). Document EP 3 606 119 A1 (GIESECKE DEVRIENT MOBILE SECURITY GMBH [DE]) February 5, 2020 (2020-02-05) discloses the saving and restoring of profiles on the card when a profile is changed. The use of a Local Profile Assistant (LPA), either on the eUICC or separately on the phone, saves and restores the static (keys, rules, and connection parameters) and dynamic data identified for all profiles.

[0011] When a profile is deactivated, this profile data is sent to the LPA. This data can then be restored all at once. US document 2018 / 249322 A1 (KIM SUNG OH [KR] ET AL) dated August 30, 2018 (2018-08-30) discloses an improvement to the standard, which stipulates that only one profile (ISD-P) can be active at any given time. Thus, when using a profile in one country, profiles from other countries cannot normally be used. The Local Profile Assistant (LPA) allows the virtual use of multiple profiles simultaneously (via time-division multiplexing).

[0012] Each application can use a different profile, which is switched on the fly when needed. All profiles then appear as activated to the applications.

[0013] The present invention aims to remedy these drawbacks. Description of the invention

[0014] The invention is defined by the independent claims. The dependent claims provide implementation examples. The invention relates firstly to a secure element comprising an initial execution environment, a first service profile, adaptive data (or "adapter" in English terminology) from the initial execution environment to an execution environment adapted to the first service profile, an adaptive routine configured to apply the adaptive data to the initial execution environment, characterized in that it further comprises inverse adaptive data (or inverse adapter) to restore the initial execution environment from the adapted execution environment, the adaptive routine being configured to apply the inverse adaptive data after use of the first service profile.

[0015] Correspondingly, the invention also relates to a method of execution in a secure element comprising an initial execution environment and a first service profile, the method comprising the following steps: apply, by an adaptive routine, adaptive data from the initial execution environment to obtain an execution environment adapted to the first service profile, use the first service profile in the adapted execution environment, then apply, by the adaptive routine, inverse adaptive data to the adapted execution environment to restore the initial execution environment.

[0016] For example, adaptation might involve a Java class frequently used in a secure element built using Java Card technology. In this case, adaptive data is configured to adapt an initial Java class from the initial runtime environment to the format of an object instantiating the Java class in the first service profile, and inverse adaptive data is configured to restore the initial Java class from the adapted Java class. Of course, other runtime resources, such as applications loaded into the secure element, can also be adapted.

[0017] The principle of adaptation of the present invention also applies in the situation where objects of the class have already been instantiated by other profiles.

[0018] The present invention thus enables the dynamic adaptation of the execution environment of a secure element to different load profiles, each with its own specific characteristics. Advantageously, the proposed adaptation mechanism does not impact existing infrastructures (particularly mobile telephone networks) while increasing the scope available to service providers to adapt the execution environment to their services. This results in greater freedom for them to offer new functionalities or services.

[0019] Optional features of embodiments of the invention are defined in the dependent claims.

[0020] In one embodiment, the adaptive routine is configured to apply adaptive and inverse adaptive data based on the lifecycle of the first service profile. This approach provides efficient dynamic adaptation of the execution environment.

[0021] For example, the adaptive routine is configured to apply adaptive data to the initial execution environment when the first service profile is activated, and to apply inverse adaptive data to the adapted execution environment when the first service profile is deactivated or deleted. This arrangement ensures optimal operation of the activated profiles.

[0022] Correspondingly for the method according to the invention, adaptive data and inverse adaptive data are applied according to the lifecycle of the first service profile, for example, adaptive data is applied to the initial execution environment when the first service profile is activated and inverse adaptive data is applied to the adapted execution environment when the first service profile is deactivated or deleted.

[0023] In one embodiment, adaptive and inverse adaptive data are stored as lists of directives that can be interpreted by the adaptive routine. This arrangement increases the possibilities for adapting the execution environment compared to known techniques limited to a small number of indirections (to an operating system) where a modification can be made. The applications and functionalities of profiles can therefore be more varied.

[0024] In one embodiment, adaptive and inverse adaptive data are stored in or associated with the first service profile, for example, in memory reserved for the first profile. Each profile also stores its own adaptive data. This facilitates the use and management of adaptive data for its application when the profile is activated, for example.

[0025] In one embodiment, the secure element includes a means of communication for receiving adaptive and inverse adaptive data within a package transmitted by external equipment, such as an installation package for the first service profile transmitted by equipment at a personalization site or by a remote network server, or a package transmitted by a remote network server after the first service profile has been installed in the secure element. Specifically, the adaptive and inverse adaptive data can be encapsulated as two additional components (called custom components in Java Card technology) of a first profile application within the package. Therefore, no adaptation of existing installation mechanisms (standards provisioning) is required.

[0026] Correspondingly for the method according to the invention, it further comprises the reception of adaptive data and inverse adaptive data within a package transmitted by external equipment, for example an installation package of the first service profile transmitted by equipment from a personalization site or by a remote network server, or a package transmitted by a remote network server after the installation of the first service profile in the secure element.

[0027] In one variant, the secure element includes a module for generating inverse adaptive data from adaptive data received from a remote network device. The adaptive data can be received as an additional component of an application in the first profile within an installation package for that profile. Generating the inverse adaptive data by the secure element reduces the risk of errors during its generation. In this variant, the generation can now take into account the actual result obtained by applying the adaptive data to the secure element's execution environment (considering, for example, the hardware platform used), which a remote server cannot do. This generation occurs during the adaptation of the execution environment.

[0028] In one variant, this generation can take place upon profile installation or upon first profile activation.

[0029] Correspondingly for the method according to the invention, it further comprises the generation, by the secure element, of inverse adaptive data from the adaptive data received from a remote network equipment.

[0030] In one embodiment, the secure element further includes a second (or more) profile chosen from: a service profile usable in the initial execution environment, a service profile usable in a modified execution environment obtained by applying other adaptive data different from said adaptive data to the initial execution environment, this service profile including the other adaptive data and other inverse adaptive data to restore the initial execution environment from the modified execution environment.

[0031] The application of adaptive data and inverse adaptive data from different profiles can then be carried out according to their life cycles, i.e. as they are activated, deactivated, deleted.

[0032] In one embodiment, the secure element includes a garbage collector that collects unused profile resources (e.g., objects, typically Java) stored in memory. The garbage collector is configured to collect only profile resources associated with one or more specific service profiles. This collection is generally performed to remove unused resources and free up memory. The garbage collector's behavior is thus tailored to the type of object being collected, based on the targeted profile(s). It is therefore possible to collect only one type of object.

[0033] The specific service profile(s) can consist of a single profile designated by an action or command as described below, or a set of profiles running on the same adapted execution environment (i.e., profiles with identical corresponding adaptive data). For example, when a target profile is identified for collection by the garbage collector, the latter can extend the collection to all profiles sharing the same adapted execution environment as the target profile.

[0034] According to one characteristic, the particular service profile is an active service profile within the secure element. Data collection is thus performed for the active profile, for example, in response to a command to deactivate the active profile.

[0035] In one variant, the specific service profile is the last active service profile. This arrangement can be used during a memory cleanup procedure when no profile is active.

[0036] According to another interpretation, the specific service profile is a service profile to be deleted. This situation therefore usually arises in response to a command to delete a profile.

[0037] In both of these variants, the execution environment is not adapted to the profile targeted by the collection. Therefore, the secure element can be configured to apply, before performing the collection, the adaptive data associated with the particular service profile (to adapt the execution environment to the profile), and to apply, after the collection, the inverse adaptive data associated with the particular service profile (to restore the initial execution environment). This allows for efficient collection targeted at objects specific to the profile in question. In an embodiment specific to the collection for a profile to be deleted, the garbage collector collects, during said collection, the profile resources of the service profile to be deleted, with the exception of the inverse adaptive data associated with that service profile, and deletes the inverse adaptive data only after it has been applied.This provision ensures a return to the generic execution environment when a profile is deleted. The secure element can therefore continue to be used with the remaining profiles.

[0038] In one particular embodiment, the profile resources are marked with an indicator representing their respective performance profiles. This arrangement allows the waste collector to efficiently search among the relevant resources.

[0039] In one particular embodiment, profile resources can be collected spontaneously, that is, independently of receiving a command (for example, to delete or deactivate). For example, collection can be triggered when memory saturation is detected.

[0040] In this case, in particular but not exclusively, the garbage collector can be configured to scan—that is, as those skilled in the art know—read all the references of an object, all the objects of all profiles, and thus proceed with the collection across all objects of all profiles. This global "view" of the garbage collector provides increased accuracy, in the sense of being able to collect all unreachable objects, thanks to the ability to clear the entire memory.

[0041] Preferably, data collection is performed only for objects in the active profile to focus solely on the current context. However, other implementation options are possible depending on the desired performance (data collection accuracy, in the sense of better memory clearance, or reduced processing time).

[0042] The invention also relates to a computer program product comprising instructions configured for implementing the steps of the above process when said program is executed on a computer, as well as a tangible medium comprising such a computer program product. Brief description of the drawings

[0043] Other features and advantages of the invention will become apparent in the following description, illustrated by the accompanying figures which show examples of implementation without any limiting character. There Figure 1 illustrates a system in which a secure element according to the invention is implemented. Figure 2 illustrates an example of a high-level architecture of an eUICC 10 card for an implementation of the invention. Figure 3 illustrates, using a flowchart, general steps for deploying adapters according to the invention in a secure element. Figure 4illustrates an example of adapting a Java class according to an embodiment of the invention. Figure 5 illustrates, using a flowchart, the general steps involved in adapting an execution environment when a profile is activated, according to one embodiment of the invention. Figure 6 illustrates, using a flowchart, the general steps for restoring an execution environment when a profile is deactivated, according to one embodiment of the invention. Figure 7 illustrates, using a flowchart, general steps of the dynamic adaptation of an execution environment when a profile is deleted, according to an embodiment of the invention. Detailed description

[0044] There Figure 1illustrates a system 1 in which a secure element 10 according to the invention is implemented. For illustrative purposes, the system 1 shown is a mobile telephony system, although the invention applies to any system using a secure element 10 containing one or more execution profiles.

[0045] In this example, the secure element 10 is an eUICC embedded in a conventional host device 20, such as a mobile phone.

[0046] The secure element 10 can be any type of card module that can be soldered or removably inserted into a secure element reader or the host device 20, examples of which are an eSE, an iSE, an eSIM (for embedded SIM), or an SSP (for Smart Secure Platform, examples of which are an iSIM (for integrated SIM) or an ieUICC (for integrated eUICC)). The host device 20 can be any of the following: a mobile phone (e.g., cellular or smartphone), a computer (e.g., laptop), a tablet, a portable communication device, a portable computing device (e.g., a personal data assistant), an entertainment device (e.g., a music or video device, or a satellite radio), or any other suitable device.

[0047] In the example of the Figure 1 ,The telephone 20 is connected to an SM-DP+ server 30 (Subscription Manager Data Preparation server) of a mobile network, which receives data from various operators MNO1 and MNO2 to transmit to subscribers. Depending on the implementation of the invention, the host terminal 20 can be connected to different types of remote servers 30. In particular, the SM-DP+ server can be replaced by two servers, SM-DP and SM-SR.

[0048] The eUICC 10 (or more generally the secure element) includes: a processing unit 12 - or microprocessor; one or more non-volatile memories 14 for example ROM (acronym for "Read Only Memory" in Anglo-Saxon terminology), Flash, EEPROM (acronym for "Electrically Erasable Read Only Memory" in Anglo-Saxon terminology) or any type of hard disk; a random access memory 16 or cache memory or volatile memory for example RAM (acronym for "Random Access Memory" in Anglo-Saxon terminology) comprising registers adapted for recording variables and parameters during the operation of the eUICC 10 of the terminal 20; during the implementation of the invention, the program instruction codes stored in non-volatile read-only memory are loaded into RAM for execution by the processing unit 12;one or more communication interfaces 18 adapted to exchange (transmit and receive) data with the host terminal 20 and / or with the remote server 30 via a telecommunications network and a COM communication interface of the host terminal 20. ;

[0049] There Figure 2 illustrates an example of high-level architecture of an eUICC 10 (generally a secure element) in a mobile telephony use where it hosts several operator profiles MNO1, MNO2 allowing access to the mobile network of these operators (generally it hosts one or more execution profiles allowing access to respective services).

[0050] eUICC 10 includes a 100 runtime environment, an ISD-R 200 root security domain, one or more (here two) ISD-P 210 profile security domains, 220 corresponding to two profiles P1 and P2, and an ECASD 230 domain.

[0051] Execution environment 100 includes, for example, the OS operating system of eUICC 10. Execution environment 100 may also include a JCRE execution environment (usually including a JCVM virtual machine) run by the OS when eUICC 10 is designed in accordance with Java Card technology.

[0052] The runtime environment 100 includes a telecom service 102, a profile activation service 104, a profile package interpreter 106, one or more resources 108 used by installed profiles (e.g., by applications), an adaptive routine 110, and a garbage collector 112.

[0053] The telecom service 102 provides network authentication algorithms for profiles (P1, P2) stored on the eUICC 10. The profile activation service 104 validates and applies profile policy rules. The interpreter 106 translates received profile packages (typically in CAP format) into profiles (e.g., P1 and P2) installed on the eUICC 10.

[0054] The resources 108 used by the profiles can be of various types: data, applications, code (interpreted or native), APIs (application programming interfaces), functions, classes (adding, deleting, or modifying fields of a class). These resources 108 are "adapted" using adaptive data (hereinafter "adapter") in an implementation of the invention. In the following example, a Java Card class used by profiles P1 and P2 is considered an "adaptable" resource. However, the invention applies to the adaptation of any resource.

[0055] The adaptive routine 110 allows adaptive data to be applied to these resources 108 in order to obtain adapted resources. By applying adaptive data designed for a particular profile (i.e., adapted to an operator), it is possible to adapt the execution environment 100 to the profile in question, thus ensuring and supporting the specific functionalities defined in that profile. Advantageously, the adaptation can be performed on the native code of the execution environment. Alternatively, the adaptation can be performed on interpretable code of the execution environment.

[0056] The example below relies on adapting class 108 to different profiles, for example by adding or modifying a field or method within class 108. Of course, several resources can be adapted, which differ from one profile to another. Furthermore, resources other than Java classes can be modified, such as the code or data of an application running in runtime environment 100.

[0057] According to the invention, the adaptive routine 110 also allows the application of inverse adaptive data to restore the resource 108 to its initial state. Thus, it is possible to dynamically adapt the execution environment 100 to a particular profile for use: by applying the appropriate adaptive data to obtain the adapted resources used by the profile, and then, at the end of use, applying the inverse adaptive data to restore the initial resources.

[0058] The garbage collector (also known as the "garbage collector" in a Java environment) collects resources from profiles that are no longer in use, in order to delete them (to free up memory). This includes, for example, collecting Java objects that are no longer accessible by the methods and other objects in use.

[0059] As is well known, the ISD-R 200 allows the creation of ISD-P profile security domains (210 and 220) and the management of their lifecycles, including the installation, activation, deactivation, and deletion of profiles P1 and P2. Commands can be received by the ISD-R 200 from the remote server 30 or from an action (e.g., input, selection, click, etc.) performed by the user on the host terminal 20, in order to modify the state of a profile.

[0060] If two execution profiles cannot be active simultaneously, activating an inactive profile is also interpreted as a request to deactivate the active profile. Alternatively, two profiles can be active at the same time, either using the same (possibly adapted) execution environment or different execution environments, in which case the execution environment is dynamically adapted in real time to the profile requesting execution.

[0061] Each ISD-P 210 or 220 profile security domain corresponds to a P1 or P2 profile for accessing the mobile network of an MNO1 or MNO2 operator. As is known, an ISD-P comprises a number of elements (not shown) such as an MNO-SD (operator security domain containing cryptographic keys), additional security domains (SSDs), a controlling authority domain (CASD), applications (applets), a network access application (NAA) used to enable access to the operator network using the keys from the MNO-SD, and profile data (including profile policy rules).

[0062] Each ISD-P 210 or 220 profile security domain (or P1 or P2 profile) also includes a 211 / 221 adapter and a 212 / 222 reverse adapter.

[0063] The 211 / 221 adapter allows the initial (or original) execution environment 100 to be adapted to the specific characteristics of profile P1 or P2 (and therefore the associated operator). The 211 / 221 adapter corresponds to the binary difference between the initial execution environment 100 and the execution environment adapted to the operator's specific characteristics. The adaptation can apply to one or more execution resources 108.

[0064] The inverse adapter 212 / 222 allows the initial execution environment 100 to be restored from the execution environment adapted by the adapter 211 / 221. In other words, the inverse adapter 212 / 222 corresponds to the binary difference between the execution environment adapted to the operator's specific requirements and the initial, unadapted execution environment 100. The restoration can concern the adapted execution resource(s) 108.

[0065] The adapters are encapsulated in directives that can be interpreted by the adaptive routine 110, that is, in the form of applications. Two lists of directives (corresponding to the adapter and the inverse adapter) can thus be stored in each profile as objects. These objects can then be easily recognized by the adaptive routine 110 as adapters to be executed. Their format (interpretable directives) advantageously allows us to move beyond the restrictive schemes of the prior art, where only indirections (lists of certain addresses) are offered for potential correction.

[0066] Although the profiles shown in the figure each have an adapter and a reverse adapter, one or more profiles installed on the secure element 10 may have no adapter, especially if they do not require (for their use) any adaptation of the execution environment 100 and its execution resources 108.

[0067] In this example, one profile (here P1) is deactivated when another profile (here P2) is activated. Other profiles can be provided, preferably deactivated in the event that only one profile is active at a time within the secure element 10.

[0068] The ECASD 230 domain is responsible for securing security domains 200, 210, 220 and the authentication functions of eUICC 10, by storing the keys and other certificates associated with the security domains.

[0069] Thanks to the adapter and inverse adapter according to the invention, the execution environment 100 can be dynamically adapted to a particular profile for use, without constraint for the profile operator. In particular, it can be dynamically adapted during profile changes, that is, according to the lifecycle of the different profiles stored in the secure element 10.

[0070] Any type of execution resource 108 can be dynamically adapted, unlike known techniques generally limited only to modifying certain predetermined resources (usually a list of possible indirections on these resources).

[0071] Appropriate management of adapters as described below (using in particular reverse adapters to restore the execution environment) thus makes it possible to coexist, within the same secure element 10, profiles which are potentially incompatible with each other.

[0072] There Figure 3 illustrates, using a flowchart, general steps for the deployment of adapters 211, 221 and reverse adapters 212, 222 in a secure element 10.

[0073] As a preliminary step, an initial runtime environment 100 (e.g., an OS operating system and / or a Java Card system with a Java Card virtual machine) is generated (step 300) for installation on the secure element 10 (step 302) using conventional techniques. For example, the installation of the runtime environment 100 can be performed at the factory during the manufacturing, pre-customization, or customization of the secure element 10. Alternatively, it can be performed remotely via OTA (OTA stands for over-the-air - see, for example, the GSMA SGP 22 RSP - Technical Specification - Version 2.2.1 of December 18, 2018, GSMA SGP .02 - Remote Provisioning Architecture for Embedded UICC - Technical Specification - Version 4.0 of February 25, 2019, GlobalPlatform Card - Remote Application Management over HTTP - Card Specification v2.2 - Amendment B - version 1.1).3) via the remote server 30, for example during an OS or Java Card virtual machine update.

[0074] At any time, a service provider (a mobile operator in the following example) may wish to install a service profile (a mobile subscriber profile P2 in the following example, but it could also be a banking profile linked to a banking service, a transport profile linked to a transport service, etc.) in the secure element 10. Steps 304 and following are therefore carried out as many times as there are profiles to install, when these require an adaptation of the execution environment 100.

[0075] To account for the specific characteristics of the service provided, the operator generates (step 304) a service-specific execution environment. This specific execution environment is referred to hereafter as the "P2 profile-adapted execution environment." This step can be based on the initial 100 execution environment as created in step 300.

[0076] There Figure 4 illustrates an example of adapting a runtime resource 108 based on Java technology, for example Java Card.

[0077] The runtime resource 108 is a Java class descriptor as understood in the prior art, including, 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 class 108 as defined in the initial runtime environment 100 (i.e., created in step 300). Objects A and B were created for profile P3, which implements, for example, a method of the class defined in the initial runtime environment 100.

[0078] In the P2 profile-specific execution environment, the Java class descriptor is modified to include, for example, one or more modified interfaces, fields, methods, and / or attributes that correspond to the specific features of the MNO2 operator service for the P2 profile. For example, a different method (than the one defined in class 108) might be required to perform an operation of the MNO2 operator service. An instantiation of this modified or "adapted" class is performed through the C object, created for the P2 profile. The C object thus includes, for example, the modified method 400.

[0079] Similarly, in the execution environment specific to profile P1, the Java class descriptor is modified to reflect the specifics of the MNO1 operator service for profile P1. The object D instantiated for this profile thus includes, for example, the modified method 402.

[0080] Back to the Figure 3 ,In step 306, the adapter 221 and inverse adapter 222 specific to the profile P2 under consideration are generated. Each adapter can notably be the binary difference between the two execution environments generated in steps 300 and 304: adapter 221, the difference between the initial execution environment 100 and the specific (or adapted) execution environment of step 304, and inverse adapter 222, the difference between the specific execution environment of step 304 and the initial execution environment 100.

[0081] In the case of the Figure 4 , The 221 adapter and 222 reverse adapter for the P2 profile include the additive definition of the additional components 400 (for the 221 adapter) and the subtractive definition of the additional components 400 (for the 222 reverse adapter), respectively.

[0082] At stage 308 of the Figure 3 ,The generated adapters 221 and 222 are encapsulated in directives interpretable by the adaptive routine 110 of the runtime environment 100. These directives are themselves encapsulated in step 310 within an application, typically a Java Card applet of the CAP file type, as two additional components ("custom components" in the Java Card specification). The application can be marked, for example using a predefined header, as containing the adapters.

[0083] In step 312, this application is added to a P2 profile package. This package (Profile Package according to certain SIM Alliance standards) is intended for deployment in the secure element 10 in the field. Creating a profile package for installation in a secure element and adding applications to it are known to those skilled in the art. For example, the package can be generated according to the document "SIMalliance eUICC Profile Package Interoperable Format Technical Specification", Version 2.2.

[0084] Then the package is sent, via remote server 30, to secure element 10, during step 314.

[0085] The next step, 316, takes place in the secure element 10, which receives the sent package and contains the adapters. As is known, the secure element 10 installs the P2 profile using the received package. A procedure for loading and installing a profile is described, for example, in the document "GSMA SGP .22 - RSP Technical Specification", Version 2.1 of February 27, 2017.

[0086] During installation, the runtime environment recognizes the marking of the adapter applet. It can then process this applet to extract the interpretable directives (representing each of the 221 and 222 adapters) and store them in connection with the P2 profile, for example, in the ISD-P2 that forms this profile. In other words, the 221 adapter and the inverse 222 adapter are stored in the memory reserved for the P2 profile in the secure element 10.

[0087] In one embodiment, only the adapter 221 of the initial runtime environment 100 is generated in step 306. In this embodiment, the inverse adapter 222 can be generated (and installed) by the secure element 10, for example, during the installation of the adapter 221 (step 316) or during the first use / application of the adapter 221. In this case, it is the secure element 10 (and no longer a piece of equipment at the factory or a remote server) that obtains the specific (adapted) runtime environment by applying the received adapter to the initial runtime environment 100, and then determines the binary difference between this specific runtime environment and the initial runtime environment 100 to construct the inverse adapter.

[0088] Although the Figure 3 is described in connection with a P2 profile installation package in the secure element, the same mechanism can be implemented with a P2 profile update package.

[0089] THE Figures 5 to 7 Using flowcharts, they illustrate the use of adapters and inverse adapters based on the activation, deactivation, and deletion of associated profiles. These figures thus illustrate how adapters and inverse adapters are applied according to the profile lifecycle.

[0090] THE Figures 5 and 6 These examples illustrate, in particular, the application of adapters to the initial execution environment 100 when one of the profiles is activated, and the application of inverse adapters to the adapted execution environment when the profile is deactivated or deleted. This results in a dynamic and on-the-fly adaptation of the execution environment to the different profiles that are successively activated (and then deactivated), by successively applying the steps of Figures 5 and 6 .

[0091] There can be as many possible adaptations of the execution environment as there are operators (or profiles). In the example of the Figure 4 , Class 108 is used to instantiate objects A and B when profile P3 is active (the execution environment is not yet adapted). Then, profile P1 is activated (instead of P3), the execution environment is adapted accordingly (with adapter 211 adding method 402), and object D is instantiated from class 108 modified with method 402 specific to P1. Then, profile P2 is activated (instead of P1), leading to the application of the inverse adapter 212 of P1 (disabling P1) and the application of adapter 221 of P2 to adapt the execution environment to P2. Object C is then instantiated from class 108 modified with method 400 specific to P2.

[0092] At step 500, secure element 10, specifically ISD-R 200, receives a command to activate a profile. In the example of the Figure 2 , The command may request the activation of the inactive profile P1. This request can also be interpreted as a command to deactivate the active profile, here P2, beforehand. In this case, the process of the Figure 6 is executed to disable the P2 profile before the process of the Figure 5 for activating profile P1.

[0093] Examples of command and activation procedure (Profile Enabling) are described in the GSMA SGP.02 (“Remote Provisioning Architecture for Embedded UICC Technical Specification”, Version 3.2 of June 27, 2017) and GSMA SGP.22 documents.

[0094] At step 502, the ISD-R 200 begins executing the activation command in the usual way. During this execution, the ISD-R 200 calls adaptive routine 110 on behalf of the ISD-P1. At step 504, adaptive routine 110 retrieves adapter 211 from the P1 profile to be activated (and not the inverse adapter 212).

[0095] The nature of the command (activation or deactivation for example) allows the adaptive routine 110 to retrieve either the adapter to adapt the initial execution environment (activation command) or the inverse adapter to restore it (deactivation / removal command).

[0096] The eUICC operating system constantly monitors the current state of the execution environment, i.e., which profile is active, thanks to a persistent value stored in memory that indicates, for example, the profile lifecycle. Based on this information, adaptive routine 110 can retrieve the appropriate adapter: Thus, the operating system continuously knows which profile is currently active. If it appears that no profile is active and therefore the execution environment is not adapted, adaptive routine 110 can then retrieve the adapter of the profile to be activated in the event of an activation command. Conversely, if it appears that a profile is currently active, adaptive routine 110 can retrieve the inverse adapter of the active profile in the event of a deactivation or deletion command for that profile.

[0097] If no adapter is available (for example because the profile does not require adaptation of the execution environment), the process goes directly to step 506. Alternatively, a default adapter can be stored with the adaptive110 routine (with a corresponding inverse default adapter), which default adapter is applied by the routine in the absence of a profile-specific adapter to be activated.

[0098] Still at step 504, adaptive routine 110 applies the retrieved adapter 211 to dynamically adapt the initial execution environment 100 to profile P1. In the example of the Figure 4 , Class 108 is suitable to contain, for example, the modified method 400.

[0099] At step 506, the ISD-R 200 continues the execution of the activation command in the usual way, resulting in the activation of profile P1. The register storing an identifier of the active profile is updated (set to the value of the identifier of P1).

[0100] The P1 profile can therefore be used in the adapted execution environment. The adapted execution environment operates entirely according to the characteristics of the applied adapter, ensuring that the functions or data specific to the MNO1 operator are available.

[0101] After use, profile P1 can be deactivated (for example, because another profile, P2 in the example, is activated) in accordance with the Figure 6 . At step 600, the ISD-R 200 therefore receives a command to deactivate (Profile Disabling) the P1 profile.

[0102] In step 604, the ISD-R 200 begins executing the deactivation command in the usual way. During this execution, the ISD-R 200 calls adaptive routine 110. Either the command specifies the profile (here P1) to be deactivated, or adaptive routine 110 can use the register storing an identifier for the active profile. In step 606, adaptive routine 110 retrieves the inverse adapter 212 for the profile P1 to be deactivated. If no inverse adapter is available (for example, because the execution environment did not need to be adapted to the active profile), the process proceeds directly to step 608 or, alternatively, the default inverse adapter is retrieved.

[0103] Still at step 606, adaptive routine 110 applies the recovered inverse adapter 212 to restore the initial execution environment 100. In the example of the Figure 4 , Class 108 is restored without the modified method 400.

[0104] At step 608, the ISD-R 200 continues the execution of the activation command in the usual way, resulting in the deactivation of profile P1. The register storing an identifier of the active profile is updated (set to 0).

[0105] In one embodiment, it may be beneficial to remove data from the P1 profile to be deactivated from memory. This is the case, for example, with Java objects instantiated during the use of the P1 profile, in order to free up memory space 14 which may be limited in the secure element 10.

[0106] This operation is performed by garbage collector 112. In one embodiment, it is configured to scan only objects in the active profile for garbage collection. Indeed, if an object belongs to a class that is suitable for a profile, the structure of that object is only recognized if the execution environment is suitable. In other words, garbage collector 112 may fail to recognize the structure of an object belonging to profile P if the execution environment is not suitable.

[0107] Furthermore, it is essential to limit the garbage collector's intervention to the current profile only to prevent any corruption (through the unintentional deletion of objects) of other profiles. Therefore, objects should ideally have been created in the JCRE while maintaining profile isolation, meaning that no object in one profile should point to an object in another. This simplifies the garbage collection mechanism while also improving profile-level security.

[0108] The cleanup is thus performed in optional step 602, preceding the application of the inverse adapter (step 606). For the ISD-R 200, this involves launching garbage collector 112 on behalf of the active profile (the identifier specified in the launch command or retrieved from the registry storing the active profile identifier). This execution collects instantiated objects (for example, from class 108, but not exclusively) for profile P1 only (the one to be deactivated) and then deletes them. Garbage collector 112 does not collect any objects instantiated for other profiles or within the JCRE.

[0109] Objects instantiated for the P1 profile can be those stored in a memory space reserved for ISD-P1.

[0110] Alternatively, objects can be instantiated by the JCVM virtual machine by stamping them with a marker (or indicator) representing their profiles. This allows garbage collector 112 to easily identify objects associated with profile P1 that need to be disabled.

[0111] According to another variant, a lookup table can be maintained that lists the objects created for each profile. This allows garbage collector 112 to quickly identify the objects related to profile P1 that need to be disabled.

[0112] According to another variant, a set of indirections can be put in place which indicates the locations (memory addresses) where the instantiated objects are stored for each profile.

[0113] Although this garbage collection mechanism by garbage collector 112 is presented in connection with profile deactivation, it can also be implemented when a profile is deleted, as described below in connection with the Figure 7: objects belonging to the profile to be deleted are collected by the garbage collector and then deleted.

[0114] According to another variant, the created objects can be collected at any time for deletion, for example in the event of memory saturation.

[0115] In this example of the Figure 5 ,The adaptation is performed only once, upon activation of profile P1. Alternatively, profile P1 can be activated conventionally without adaptation (at this stage) of the initial execution environment 100, and adaptation using adapter 211 can be initiated (steps 502 and 504) on other occasions, for example, each time profile P1 is accessed. Access to profile P1 can occur during an authentication procedure (for a network, banking, or transport service, for example) or when an application located in profile P1 is called. In this variant, the initial execution environment 100 can be restored (using steps 602 to 606) after these operations, e.g., the authentication procedure or the execution of the application located in profile P1.

[0116] There Figure 7 illustrates the steps involved in deleting a profile.

[0117] At step 700, the secure element 10, and more specifically the ISD-R 200, receives a command to delete (Profile Deletion) a profile P, for example conforming to the GSMA documents mentioned above.

[0118] For efficient use of garbage collector 112, the execution environment is adapted to the profile to be deleted. Thus, in step 702, the ISD-R 200 calls adaptive routine 110 on behalf of the profile to be deleted. In step 704, adaptive routine 110 retrieves adapter 211 or 221 from the profile P to be deleted (and not the inverse adapter 212 or 222), and then applies it to adapt the initial execution environment 100 to profile P.

[0119] At step 706 (similar to step 602 described above), the ISD-R 200, which takes over, launches an execution of garbage collector 112 on behalf of the profile P to be deleted. This execution involves collecting the instantiated objects (from a recognized, possibly adapted, class) for profile P only (the one to be deleted) and then deleting them.

[0120] At step 708, ISD-R 200 removes the constituent elements of the P profile, including data and applications. During this operation, the inverse adapter 212 or 222 is added to the JCRE persistence roots in order to preserve it (it is not seen and therefore not removed by ISD-R 200).

[0121] Following this removal of the constituent elements of profile P, the initial execution environment 100 can now be restored during step 710. To do this, the ISD-R 200 calls again the adaptive routine 110, which retrieves the inverse adapter 212 or 222 of the profile P to be removed, and then applies it so as to restore the initial execution environment 100.

[0122] At step 712, the ISD-R 200 removes the inverse adapter from profile P (after removing it from the JCRE persistence roots). This step completes the removal of profile P. The initial execution environment 100 can then resume execution in secure element 10.

[0123] In one embodiment, a runtime environment cleanup routine can trigger, on command, periodically, or upon any other event, an operation to clean up unnecessary objects to free up memory space, even when no profile is active. This routine can thus successively consider all or part of the installed profiles (for example, the profile(s) determined according to a predefined rule—for example, the last used profile) and, for a given profile P: retrieve (step 702) and apply (step 704) the P profile adapter to obtain the appropriate runtime environment; launch garbage collector 112 (step 706) to collect objects from the P profile and delete them (step 708); then retrieve and apply (step 710) the inverse P profile adapter to restore the original runtime environment.

[0124] The preceding examples are only embodiments of the invention, which is not limited to them.

[0125] In particular, these examples mainly concern a mobile telephony application with P1, P2 subscriber profiles, a mobile network infrastructure and mobile operators; they can be transposed without difficulty to any type of service profile (including configurations according to GlobalPlatform), any type of remote server and any type of service provider.

Claims

1. Secure element (10) comprising: - an initial execution environment (100) consisting of native code and / or interpretable code; and - at least one security domain which is distinct from the execution environment, the at least one security domain comprising a first service profile (P1, P2, 210, 220), a service profile comprising credentials of a subscriber for authenticating on one or more mobile telephone networks; - the at least one security domain comprising adaptive data (211, 221) which adapt the initial execution environment into an execution environment adapted to the first service profile and inverse adaptive data (212, 222) for restoring the initial execution environment from the adapted execution environment, the adaptive data and inverse adaptive data being constituted in the form of a list of interpretable directives; - the initial execution environment (100) comprising an adaptive routine (110) configured to apply the adaptive data to the initial execution environment before the first service profile is used and to apply the inverse adaptive data after the first service profile is used.

2. Secure element (10) according to Claim 1, wherein the adaptive routine (110) is configured to apply the adaptive data to the initial execution environment when the first service profile is activated and to apply the inverse adaptive data to the adapted execution environment when the first service profile is deactivated or deleted.

3. Secure element (10) according to one of Claims 1 and 2, further comprising a communication means for receiving the adaptive data and the inverse adaptive data within an installation package of the first service profile transmitted by external equipment (30).

4. Secure element (10) according to one of Claims 1 to 3, further comprising a module for generating the inverse adaptive data on the basis of the adaptive data received from remote network equipment (30).

5. Secure element (10) according to one of Claims 1 to 4, further comprising a second profile chosen from among: - a service profile which can be used in the initial execution environment, - a service profile which can be used in a modified execution environment obtained by applying other adaptive data (221) which are different from said adaptive data (211) to the initial execution environment, this service profile comprising the other adaptive data and other inverse adaptive data (222) for restoring the initial execution environment from the modified execution environment.

6. Secure element (10) according to one of Claims 1 to 5, wherein the adaptive data (211, 221) are configured to adapt an initial Java class (108) of the initial execution environment (100) to a format of an object instantiating the Java class in the first service profile, and the inverse adaptive data (212, 222) are configured to restore the initial Java class (108) from the adapted Java class.

7. Method for execution in a secure element (10) comprising an initial execution environment (100) consisting of native code and / or interpretable code and at least one security domain which are distinct from the execution environment, the at least one security domain comprising a first service profile (P1, P2, 210, 220), a service profile comprising credentials of a subscriber for authenticating on one or more mobile phone networks, the method comprising the following steps: - applying (504, 704), by means of an adaptive routine (110) of the initial execution environment, adaptive data (211, 221), comprised in the at least one security domain, which adapt the initial execution environment in order to obtain an execution environment adapted to the first service profile, - using the first service profile in the adapted execution environment, - then applying (606, 710), by means of the adaptive routine, inverse adaptive data (212, 222), comprised in the at least one security domain, to the execution environment adapted to restore the initial execution environment, the adaptive and inverse adaptive data being constituted in the form of a list of interpretable directives.

8. Method according to Claim 7, wherein the adaptive data are applied to the initial execution environment when the first service profile is activated (500) and the inverse adaptive data are applied to the adapted execution environment when the first service profile is deactivated (600) or deleted (700).

9. Method according to one of Claims 7 to 8, wherein the secure element further comprises a second profile selected from among: - a service profile which can be used in the initial execution environment, - a service profile which can be used in the modified execution environment obtained by applying other adaptive data (221) which are different from said adaptive data (211) to the initial execution environment, this service profile comprising the other adaptive data and other inverse adaptive data (222) for restoring the initial execution environment from the modified execution environment.

10. Tangible medium comprising a computer program product comprising instructions which are configured for implementing the steps of the method according to one of Claims 7 to 9, when said program is executed by a secure element according to one of Claims 1 to 6.