Patent Description:
Mobile devices, such as smartphones, may contain several execution environments in which executable codes are executed. For instance, a mobile phone typically contains a so-called embedded Universal Integrated Circuit Card (eUICC) and an embedded Secure Element (eSE). An eUICC - which may also be referred to as an embedded Subscriber Identity Module (eSIM) - is a secure element designed to remotely manage multiple mobile network operator subscriptions and to be compliant with GSMA specifications. An eSE is a tamper-resistant chip, which may be embedded in any mobile device. In particular, a secure element (SE) may be a tamper-resistant integrated circuit with installed or pre-installed smart-card-grade applications, for instance payment applications, which have a prescribed functionality and a prescribed level of security. Furthermore, a secure element may implement security functions, such as cryptographic functions and authentication functions. The different execution environments of a mobile device often execute applications which are unrelated to each other. For instance, the eUICC may execute applications related to mobile network communications, while the eSE may execute applications related to Near Field Communication (NFC) transactions. Documents <CIT> and <CIT> form part of the background art.

In accordance with a first aspect of the present disclosure, a system is provided for applying patches to executable codes, comprising: a plurality of execution environments configured to execute said codes in different execution contexts; a control unit configured to apply the patches to said codes; wherein the control unit is configured to apply a specific patch to a specific code upon or after an execution environment configured to execute said specific code switches to an execution context corresponding to said specific code.

In an embodiment, the system further comprises a mapping between execution contexts and patches, wherein the control unit is configured to determine the specific patch to be applied by selecting a patch activated for the execution context according to said mapping.

In an embodiment, the patches are stored in memory locations different from the memory locations in which the codes are stored.

In an embodiment, the control unit is further configured to generate checksums on the codes and the patches.

In an embodiment, the control unit is further configured to apply shared patches, said shared patches being shared by a plurality of codes in a specific execution context.

In an embodiment, the control unit is configured to apply the shared patches by loading the patches into memory locations which are shared by the codes in the specific execution context.

In an embodiment, the control unit is a hypervisor or a common operating system.

In an embodiment, the execution environments include at least an embedded Universal Integrated Circuit Card (eUICC) and an embedded Secure Element (eSE).

In an embodiment, the execution environments include operating systems, and the patches include patches of one or more codes executable by said operating systems.

In an embodiment, the codes include applets, and the patches include patches of said applets.

In accordance with a second aspect of the present disclosure, a method is conceived for applying patches to executable codes, comprising: executing said codes by a plurality of execution environments in different execution contexts; applying, by a control unit, the patches to said codes; applying, by the control unit, a specific patch to a specific code upon or after an execution environment configured to execute said specific code switches to an execution context corresponding to said specific code.

In an embodiment, the execution contexts are mapped to the patches, and the control unit determines the specific patch to be applied by selecting a patch activated for execution context according to the mapping.

In an embodiment, the control unit generates checksums on the codes and the patches.

In accordance with a third aspect of the present disclosure, a computer program is provided, comprising executable instructions that, when executed by a control unit, carry out a method of the kind set forth.

Mobile devices, such as smartphones, may contain several execution environments in which executable codes are executed. For instance, a mobile phone typically contains a so-called embedded Universal Integrated Circuit Card (eUICC) and an embedded Secure Element (eSE). An eUICC - which may also be referred to as an embedded Subscriber Identity Module (eSIM) - is a secure element designed to remotely manage multiple mobile network operator subscriptions and to be compliant with GSMA specifications. An eSE is a tamper-resistant chip, which may be embedded in any mobile device. In particular, a secure element (SE) may be a tamper-resistant integrated circuit with installed or pre-installed smart-card-grade applications, for instance payment applications, which have a prescribed functionality and a prescribed level of security. Furthermore, a secure element may implement security functions, such as cryptographic functions and authentication functions. The different execution environments of a mobile device often execute applications which are unrelated to each other. For instance, the eUICC may execute applications related to mobile network communications, while the eSE may execute applications related to Near Field Communication (NFC) transactions.

Besides a common operating system containing executable code, such as a Java Card (JC) operating system which can be shared by several execution environments, each execution environment may also contain dedicated executable code, such as a Java Virtual Machine and GlobalPlatform (GP) code. Furthermore, the JC operating system may contain a kernel, flash libraries and drivers, for example. Each of these components includes executable code, which sometimes needs to be patched. For security reasons, however, this code should be certified before it is used. This security certification is costly and time-consuming. Therefore, the security certification should not be performed too often.

Nowadays, devices that include secure elements integrate a lot of functionality in the operating system. Furthermore, service providers - such as payment service providers - may require a certification of both the operating system and the payment applets. After certification the code of the operating system cannot be changed anymore without a recertification. Thus, patches of the code will also require a recertification. Furthermore, if the certificate of an operating system changes, the applets executed on this operating system should also be recertified. As a consequence, the functional testing of the applets should also be repeated. Since typically multiple applets should be certified, this is costly and time-consuming. Now a system and a method for applying patches are described, which may reduce the need for a recertification of the kind set forth.

<FIG> shows an illustrative embodiment of a system <NUM> for applying patches to executable codes. The system <NUM> comprises a plurality of execution environments <NUM>, <NUM> configured to execute the codes in different execution contexts <NUM>, <NUM>, <NUM>. In other words, each execution environment <NUM>, <NUM> may execute codes in one or more execution contexts <NUM>, <NUM>, <NUM>. Examples of the execution contexts are a payment context and a public transit context, in which different applets are executed and for which specific operating system resources are reserved. Furthermore, the system <NUM> comprises a control unit <NUM> operatively coupled to the execution environments <NUM>, <NUM>. The control unit <NUM> is configured to apply the patches to the codes. Furthermore, the control unit <NUM> is configured to apply a specific one of said patches to a specific one of said codes upon or after an execution environment configured to execute the specific code switches to an execution context corresponding to the specific code. In this way, the patches can be applied dynamically for targeted contexts. It is noted that a patch may be a small piece of code inserted into a program to improve its functioning or to correct a fault, or, in more general terms, any code that modifies or updates existing code.

In particular, an operating system will switch between different execution contexts, to facilitate the execution of specific codes (e.g., operating system code and applets). The switching to a particular context is used as a trigger for applying a specific patch to the code executed in that context. This patch is not applied to code executed in other contexts. Therefore, the code executed in other contexts does not change, and does not need to be recertified. It is noted that a context refers to a set of allocated resources, for example a set of loaded variables and/or reserved memory locations, for executing applications within said context. For instance, each context may have a reserved memory space and may have reserved hardware resources (e.g. peripheral access). In this sense, each context may have a dedicated non-volatile and volatile memory space. Applets that are executed are also specific to a context. Thus, if an applet is loaded in one context it can typically not be executed in another context, unless it is loaded into the other context. Global variables may be context-specific as well, and if needed they may be duplicated so that each context has its own variables. It is noted that different contexts may share the same code, but typically they will not share data.

In an embodiment, the system <NUM> further comprises a mapping between execution contexts and patches, and the control unit <NUM> is configured to determine the specific patch to be applied by selecting a patch activated for the execution context <NUM>, <NUM>, <NUM> according to the mapping. In this way, it becomes easier to apply the patches dynamically for targeted contexts. The mapping may for example be realized as a table or a list or as another representation. In a practical and effective implementation, the control unit <NUM> may contain such a table or list.

In an embodiment, the patches are stored in memory locations different from the memory locations in which the codes are stored. In this way, the original code is not overwritten, and the risk that a code belonging to another context is affected by a patch for the targeted context is small. Furthermore, in an embodiment, the control unit <NUM> is configured to generate checksums on the codes and the patches. In this way, it can be proven that codes belonging to contexts other than the targeted context have not been changed. This, in turn, may be sufficient for avoiding a recertification of these codes.

In an embodiment, the control unit <NUM> is further configured to apply shared patches. These patches are shared by a plurality of codes in a specific execution context. For instance, not only a payment context and a public transit context may be distinguished, but also a complete eSE or eUICC may be regarded as a higher-level execution context. In that case, a shared patch could be applied to all codes in a given context. This shared patch can also be applied dynamically. In a practical and effective implementation, the control unit <NUM> is configured to apply the shared patches by loading them into memory locations which are shared by the codes in the specific execution context. Alternatively, the shared patches may be applied by activating them at a current memory location - i.e. without loading them into shared memory locations - for example by making use of hardware watchpoints.

In an embodiment, the control unit <NUM> is a hypervisor or a common operating system. A hypervisor results in a practical and effective implementation. A hypervisor or virtual machine monitor (VMM) is computer software, firmware or hardware that creates and runs virtual machines. As such, it can control virtual machines in which the different execution environments are realized. The control unit <NUM> can also be implemented in a common operating system, such as a JC operating system kernel. As mentioned above, the execution environments may include at least an embedded Universal Integrated Circuit Card (eUICC) and an embedded Secure Element (eSE).

In an embodiment, the execution environments include operating systems, and the patches include patches of one or more codes executable by said operating systems. Alternatively, or in addition, the codes include applets, and the patches include patches of said applets.

<FIG> shows an illustrative embodiment of a method <NUM> for applying patches to executable codes. The method <NUM> comprises, at <NUM>, executing codes by a plurality of execution environments in different execution contexts, at <NUM>, applying, by a control unit, patches to said codes, and at <NUM> applying, by the control unit, a specific patch to a specific code upon or after an execution environment configured to execute said specific code switches to an execution context corresponding to said specific code. As mentioned above, in this way, the patches can be applied dynamically for targeted contexts.

<FIG> shows an illustrative embodiment of a platform <NUM> with a plurality of execution environments. The execution environments contain independent data and code <NUM>, <NUM>, meaning that the data and code in one execution environment does not depend on the data and code in the other execution environment. In this example, the eUICC is one execution environment, containing independent data and code <NUM>, and the eSE is another execution environment, containing independent data and code <NUM>. The eUICC contains one execution context, i.e. for executing mobile network applications, and the eSE contains two execution contexts, one for executing public transit applications (Transit Applet) and one for executing payment applications (EMV Applet). The execution environments may also be referred to as domains. The common operating system <NUM>, which is a JC operating system kernel in the present example, provides a separation of the eSE domain and the eUICC domain. For instance, in addition to code that is shared between the different domains, dedicated code and data may exist, i.e. code and data that are specific to - and that are only to be used in - the respective domains. In this sense, the combination of shared code and dedicated code and data for a given domain may be regarded as an independent operating system. The independent operating system of the eSE domain may for example support the execution of payment, transit, authentication, eGovernment and ultra-wideband (UWB) applications. The independent operating system of the eUICC domain may support the execution of mobile network applications. Both operating systems will work independently of each other. A hypervisor <NUM> manages the switching between different execution contexts. Thus, the hypervisor will have knowledge about which execution context is active at a given moment. As mentioned above, the eSE domain and the eUICC domain as a whole can be regarded as different execution contexts. In addition, different execution contexts can be distinguished within a particular domain, for example a payment context and a public transit context within the eSE domain. The hypervisor <NUM> is configured to manage these contexts. In such a case, the JC operating system may have to inform the hypervisor that a specific execution context becomes active in a given domain. Then, the hypervisor may enable or disable the corresponding patch or patches for this context.

<FIG> shows another illustrative embodiment of a system <NUM> for applying patches to executable codes. The system <NUM> comprises a control unit <NUM>, a table <NUM> containing a mapping between execution contexts and patches, and a plurality of patches <NUM>, <NUM>, <NUM>, <NUM>, <NUM>. At runtime, the control unit <NUM> can apply the patches <NUM>, <NUM>, <NUM>, <NUM>, <NUM> by looking up, for a given active execution context, which of the patches <NUM>, <NUM>, <NUM>, <NUM>, <NUM> are mapped to said active execution context. For instance, if the eUICC context is active, then the patches identified as ID <NUM>, ID2, IDn should be applied, if the transport context is active, then only the patch identified as ID2 should be applied, and the payment context is active, then the patches identified as ID2 and ID4 should be applied.

More specifically, the control unit <NUM> (e.g. a common operating system or a hypervisor) maintains a registry (e.g. a table) in which all the patches available in the system are mapped to one or more execution contexts. When a patch is applied to the chip, it is stored in a separate location (e.g. a dedicated Flash page) and it is assigned to one or multiple execution contexts (this is meta-information of a patch). The control unit <NUM> stores this information in the registry. When a context switch occurs, the control unit <NUM> accesses the registry and checks which patch or patches should be applied. Subsequently, the control unit <NUM> may apply said patch or patches.

<FIG> shows a further illustrative embodiment of a system <NUM> for applying patches to executable codes. In particular, a state of the memory <NUM> before patching is shown, as well as a state of the memory <NUM> after patching. A shared code patch is applied to the code shared between the eSE domain and the eUICC domain, but only to the execution context "eSE as a whole". In other words, the shared code patch is not applied to the shared code if the eSE context is not active. Furthermore, a patch to the eSE code is applied. The system <NUM> comprises a hypervisor <NUM>, which is configured to control a hardware-based memory management unit (MMU) or memory protection unit (MPU). As explained with reference to <FIG>, the hypervisor <NUM> looks up in table which patches should be applied if the eSE context is active and applies said patches by mapping the new code into a shared memory area, for example. It is noted that there also alternative ways to activate a patch for a given context. For instance, watchpoint vectors may be used or branch tables. Furthermore, code and other data which are relevant for non-active contexts may be blocked by the MPU.

For execution contexts not using a patch, a checksum may be applied to prove that still the original certified code without modification is executed. In particular, as shown in <FIG>, for execution contexts not using a patch, the code checksum will be the same before and after the patch. This proves that the code was not modified or patched. The checksum is calculated during runtime in the current active context. The operating system or the hypervisor <NUM> will support an application programming interface (API) or application protocol data unit (APDU) for this purpose. The checksum can be compared against the checksum with which the original build was certified. Each domain or context will have a dedicated checksum, e.g. one for eUICC one for eSE. If a small patch is applied, the hypervisor <NUM> will map the new code into the shared memory area (either via MMU or via re-sorting map-ram). This changes the code which is visible in the current domain and hence the checksum is different too. Basically, a flash page is replaced by another flash page with the new code. If the patch cannot be applied in-place it must be placed at a new location in the flash memory. However, to call this new location the original code must be modified to jump to or call the new function. This will change the checksum. So, in both cases the checksum mechanism can provide the desired proof. In addition, the hypervisor patch mechanism can include the patch code in the checksum calculation. To increase the level of security, the hypervisor checksum mechanism is also certified.

The systems and methods described herein may at least partially be embodied by a computer program or a plurality of computer programs, which may exist in a variety of forms both active and inactive in a single computer system or across multiple computer systems. For example, they may exist as software program(s) comprised of program instructions in source code, object code, executable code or other formats for performing some of the steps. Any of the above may be embodied on a computer-readable medium, which may include storage devices and signals, in compressed or uncompressed form.

Claim 1:
A system for applying patches to executable codes, comprising:
- a plurality of execution environments configured to execute said codes in different execution contexts;
- a control unit configured to apply the patches to said codes;
wherein the control unit is configured to apply a specific patch to a specific code upon or after an execution environment configured to execute said specific code switches to an execution context corresponding to said specific code;
characterized by
the system further comprising a mapping between execution contexts and patches, wherein the control unit is configured to determine the specific patch to be applied by selecting a patch activated for the execution context according to said mapping, and wherein the patches are stored in memory locations different from the memory locations in which the codes are stored.