System and method for applying a patch to executable code

Abstract

According to a first aspect of the present disclosure, a system for applying a patch to an executable code is provided, comprising: a plurality of execution environments configured to execute the code in different execution contexts; a control unit configured to apply the patch to the code; wherein the control unit is configured to apply a specific patch to the specific code when or after the execution environment configured to execute the specific code switches to the execution context corresponding to the specific code. According to other aspects of the present disclosure, a corresponding method for applying a patch to an executable code is conceived, and a corresponding computer program is provided.

Description

Technical Field

[0001] The present disclosure relates to a system for applying a patch to an executable code. In addition, the present disclosure relates to a corresponding method for applying a patch to an executable code, and a corresponding computer program. Background Art

[0002] A mobile device such as a smart phone may include several execution environments in which executable code is executed. For example, a mobile phone typically includes a so-called embedded universal integrated circuit card (eUICC) and an embedded security element (eSE). The eUICC (which may also be referred to as an embedded subscriber identity module (eSIM)) is a security element designed to remotely manage multiple mobile network operator subscriptions and comply with GSMA specifications. The eSE is a tamper-proof chip that can be embedded in any mobile device. Specifically, a security element (SE) may be a tamper-proof integrated circuit with an installed or pre-installed smart card-level application (e.g., a payment application), the security element having a specified function and a specified security level. In addition, the security element may implement security functions such as encryption functions and authentication functions. Different execution environments of a mobile device typically execute applications that are unrelated to each other. For example, an eUICC may execute applications related to mobile network communications, and an eSE may execute applications related to near field communication (NFC) transactions. Summary of the invention

[0003] According to a first aspect of the present disclosure, a system for applying a patch to an executable code is provided, comprising: a plurality of execution environments configured to execute the code in different execution contexts; a control unit configured to apply the patch to the code; wherein the control unit is configured to apply a specific patch to a specific code when or after the execution environment configured to execute the specific code switches to the execution context corresponding to the specific code.

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

[0005] In an embodiment, the patch is stored in a memory location different from the memory location where the code is stored.

[0006] In an embodiment, the control unit is further configured to generate a checksum for the code and the patch.

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

[0008] In an embodiment, the control unit is configured to apply the shared patch by loading the patch into a memory location shared by code in a specific execution context.

[0009] In an embodiment, the control unit is a hypervisor or a general purpose operating system.

[0010] In an embodiment, the execution environment includes at least an embedded universal integrated circuit card (eUICC) and an embedded secure element (eSE).

[0011] In an embodiment, the execution environment comprises an operating system, and the patch comprises a patch of one or more codes executable by the operating system.

[0012] In an embodiment, the code comprises an applet and the patch comprises a patch of the applet.

[0013] According to a second aspect of the present disclosure, a method for applying a patch to an executable code is conceived, comprising: executing the code in different execution contexts by multiple execution environments; applying the patch to the code by a control unit; and applying a specific patch to a specific code by the control unit when or after the execution environment configured to execute the specific code switches to the execution context corresponding to the specific code.

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

[0015] In an embodiment, the patch is stored in a memory location different from the memory location where the code is stored.

[0016] In an embodiment, the control unit generates a checksum on the code and the patch.

[0017] According to a third aspect of the present disclosure, there is provided a computer program comprising executable instructions which, when executed by a control unit, perform a method of the type set out. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Embodiments will be described in more detail with reference to the accompanying drawings, in which:

[0019] Figure 1 An illustrative embodiment of a system for applying a patch to executable code is shown;

[0020] Figure 2 An illustrative embodiment of a method for applying a patch to executable code is shown;

[0021] Figure 3 An illustrative embodiment of a platform having multiple execution environments is shown;

[0022] Figure 4 Another illustrative embodiment of a system for applying a patch to executable code is shown;

[0023] Figure 5 Another illustrative embodiment of a system for applying a patch to executable code is shown. DETAILED DESCRIPTION

[0024] A mobile device such as a smart phone may include several execution environments in which executable code is executed. For example, a mobile phone typically includes a so-called embedded universal integrated circuit card (eUICC) and an embedded security element (eSE). The eUICC (which may also be referred to as an embedded subscriber identity module (eSIM)) is a security element designed to remotely manage multiple mobile network operator subscriptions and comply with GSMA specifications. The eSE is a tamper-proof chip that can be embedded in any mobile device. Specifically, a security element (SE) may be a tamper-proof integrated circuit with an installed or pre-installed smart card-level application (e.g., a payment application), the security element having a specified function and a specified security level. In addition, the security element may implement security functions such as encryption functions and authentication functions. Different execution environments of a mobile device typically execute applications that are unrelated to each other. For example, an eUICC may execute applications related to mobile network communications, and an eSE may execute applications related to near field communication (NFC) transactions.

[0025] In addition to the general operating system comprising executable code, such as the Java Card (JC) operating system that can be shared by several execution environments, each execution environment can also include special executable code, such as Java virtual machine and global platform (GP) code. In addition, the JC operating system can include, for example, a kernel, a flash library and a driver. Each of these components includes an executable code that sometimes needs to be patched. However, for safety reasons, the code should be authenticated before use. This safety authentication is both expensive and time-consuming. Therefore, safety authentication should not be performed too frequently.

[0026] Nowadays, the device including security element integrates many functions in the operating system. In addition, service providers (such as payment service providers) may need the authentication of both the operating system and the payment applet. After authentication, the code of the operating system can no longer be changed without re-authentication. Therefore, the patch of the code will also need to be re-authenticated. In addition, if the certificate of the operating system changes, the applet executed on the operating system should also be re-authenticated. Therefore, the functional test of the applet should also be repeated. Since usually a plurality of applet should be authenticated, this is both expensive and time-consuming. Now describe a system and method for applying a patch, which can reduce the need for re-authentication of the type.

[0027] Figure 1 An illustrative embodiment of a system 100 for applying a patch to executable code is shown. The system 100 includes a plurality of execution environments 104, 110, which are configured to execute code in different execution contexts 106, 108, 112. In other words, each execution environment 104, 110 can execute code in one or more execution contexts 106, 108, 112. Examples of execution contexts are payment contexts and common transport contexts, in which different applets are executed and specific operating system resources are reserved for them. In addition, the system 100 includes a control unit 102 operably connected to the execution environments 104, 110. The control unit 102 is configured to apply the patch to the code. In addition, the control unit 102 is configured to apply a specific one of the patches to a specific one of the codes when or after the execution environment configured to execute the specific code switches to the execution context corresponding to the specific code. In this way, patches can be dynamically applied to the target context. It should be noted that a patch can be a small block of code inserted into a program to improve its functionality or correct a bug, or more generally, any code that modifies or updates existing code.

[0028] Specifically, the operating system will switch between different execution contexts to facilitate the execution of specific code (e.g., operating system code and applet). Switching to a specific context serves as a trigger for applying a specific patch to the code executed in the context. The patch is not applied to code executed in other contexts. Therefore, the code executed in other contexts will not change and does not need to be re-authenticated. It should be noted that a context refers to a set of allocated resources, such as a set of loaded variables and / or reserved memory locations, for executing applications within the context. For example, each context can have reserved memory space and can have reserved hardware resources (e.g., peripheral device access). In this sense, each context can have dedicated non-volatile and volatile memory space. The applet executed is also context-specific. Therefore, if the applet is loaded into one context, it cannot usually be executed in another context unless it is loaded into another context. Global variables can also be context-specific, and if necessary, they can be copied so that each context has its own variables. It should be noted that different contexts can share the same code, but usually do not share data.

[0029] In an embodiment, the system 100 further comprises a mapping between execution contexts and patches, and the control unit 102 is configured to determine the specific patch to be applied by selecting a patch to be activated for the execution context 106, 108, 112 according to the mapping. In this way, it becomes easier to dynamically apply patches for the target context. The mapping may be implemented, for example, as a table or list or another representation. In a practical and efficient implementation, the control unit 102 may contain such a table or list.

[0030] In an embodiment, the patch is stored in a memory location different from the memory location where the code is stored. In this way, the original code is not overwritten and the risk that the code belonging to another context is affected by the patch of the target context is small. Furthermore, in an embodiment, the control unit 102 is configured to generate a checksum for the code and the patch. In this way, it can be proved that the code belonging to the context other than the target context has not been changed. This in turn can be sufficient to avoid re-authentication of these codes.

[0031] In an embodiment, the control unit 102 is also configured to apply shared patches. These patches are shared by multiple codes in a specific execution context. For example, not only can the payment context and the common transport context be distinguished, but also the complete eSE or eUICC can be regarded as a higher-level execution context. In that case, the shared patch can be applied to all code in a given context. This shared patch can also be applied dynamically. In a practical and effective implementation, the control unit 102 is configured to apply the shared patch by loading it into a memory location shared by the code in the specific execution context. Alternatively, the shared patch can be applied by activating the shared patch at the current memory location, i.e., without loading them into a shared memory location, for example by utilizing a hardware observation point.

[0032] In an embodiment, the control unit 102 is a hypervisor or a general-purpose operating system. The hypervisor leads to a practical and effective implementation. A hypervisor or a virtual machine monitor (VMM) is a computer software, firmware, or hardware that creates and runs a virtual machine. Therefore, it can control virtual machines that implement different execution environments. The control unit 102 can also be implemented in a general-purpose operating system such as a JC operating system kernel. As described above, the execution environment may include at least an embedded universal integrated circuit card (eUICC) and an embedded security element (eSE).

[0033] In an embodiment, the execution environment comprises an operating system, and the patch comprises a patch of one or more codes executable by the operating system.Alternatively, or in addition, the code comprises an applet, and the patch comprises a patch of the applet.

[0034] Figure 2 An illustrative embodiment of a method 200 for applying a patch to executable code is shown. The method 200 includes: at 202, executing code in different execution contexts by multiple execution environments; at 204, applying a patch to the code by a control unit; and at 206, applying a specific patch to the specific code by the control unit when or after the execution environment configured to execute the specific code switches to the execution context corresponding to the specific code. As described above, in this manner, patches can be dynamically applied to a target context.

[0035] Figure 3An illustrative embodiment of a platform 300 with multiple execution environments is shown. The execution environments contain independent data and code 302, 304, which means that the data and code in one execution environment do not depend on the data and code in another execution environment. In the example, the eUICC is an execution environment containing independent data and code 304, and the eSE is another execution environment containing independent data and code 302. The eUICC contains an execution context, i.e., for executing mobile network applications, and the eSE contains two execution contexts, one for executing public transport applications (transport applets) and one for executing payment applications (EMV applets). The execution environment may also be referred to as a domain. The general operating system 306 is a JC operating system kernel in this example, which provides separation of the eSE domain and the eUICC domain. For example, in addition to the code shared between different domains, there may also be dedicated code and data, i.e., code and data specific to each domain and used only in each domain. In this sense, the combination of shared code and dedicated code and data for a given domain can be regarded as an independent operating system. The independent operating system of the eSE domain can, for example, support the execution of payment, transport, authentication, e-government, and ultra-wideband (UWB) applications. The independent operating system of the eUICC domain can support the execution of mobile network applications. The two operating systems will work independently of each other. The hypervisor 310 manages the switching between different execution contexts. Therefore, the hypervisor will know which execution context is active at a given moment. As described 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 specific domain (e.g., a payment context and a public transport context within the eSE domain). The hypervisor 310 is configured to manage these contexts. In such cases, the JC operating system may have to notify the hypervisor that a specific execution context has become active in a given domain. The hypervisor can then enable or disable the corresponding one or more patches for the context.

[0036] Figure 4Another illustrative embodiment of a system 400 for applying patches to executable code is shown. The system 400 includes a control unit 402, a table 404 containing mappings between execution contexts and patches, and a plurality of patches 406, 408, 410, 412, 414. At runtime, for a given active execution context, the control unit 402 can apply the patches 406, 408, 410, 412, 414 by looking up which of the patches 406, 408, 410, 412, 414 are mapped to the active execution context. For example, if the eUICC context is active, patches identified as ID1, ID2, IDn should be applied, if the transport context is active, only the patch identified as ID2 should be applied, and if the payment context is active, patches identified as ID2 and ID4 should be applied.

[0037] More specifically, the control unit 402 (e.g., a general operating system or hypervisor) maintains a registry (e.g., a table) in which all patches available in the system are mapped to one or more execution contexts. When a patch is applied to a chip, it is stored in a separate location (e.g., a dedicated flash memory page) and is assigned to one or more execution contexts (this is the meta information of the patch). The control unit 402 stores the information in the registry. When a context switch occurs, the control unit 402 accesses the registry and checks which patch or patches should be applied. Subsequently, the control unit 402 can apply the patch or patches.

[0038] Figure 5 Another illustrative embodiment of a system 500 for applying patches to executable code is shown. Specifically, a state of memory 502 before patching is shown, and a state of memory 504 after patching is shown. The shared code patch is applied to code shared between the eSE domain and the eUICC domain, but only to the execution context "eSE as a whole". In other words, if the eSE context is not active, the shared code patch is not applied to the shared code. In addition, the patch to the eSE code is applied. The system 500 includes a hypervisor 512, which is configured to control a hardware-based memory management unit (MMU) or memory protection unit (MPU). As shown in reference Figure 4 As explained, the hypervisor 512 looks up in a table which patches should be applied if the eSE context is active, and applies the patches, for example, by mapping new code to a shared memory area. It should be noted that there are also alternative ways to activate patches for a given context. For example, a watchpoint vector or a branch table may be used. In addition, code and other data associated with an inactive context may be blocked by the MPU.

[0039] For execution contexts that do not use patches, checksums can be applied to prove that the original unmodified authentication code is still executed. Specifically, if Figure 5 As shown, for an execution context that does not use a patch, the code checksum will be the same before and after the patch. This proves that the code has not been modified or patched. The checksum is calculated during runtime in the current active context. To this end, the operating system or hypervisor 512 will support an application programming interface (API) or application protocol data unit (APDU). The checksum can be compared with the checksum of the original build that authenticates it. Each domain or context will have a dedicated checksum, for example, one for eUICC and one for eSE. If a small patch is applied, the hypervisor 512 will map the new code to a shared memory area (via MMU or via reorder mapping-ram). This changes the code visible in the current domain, so the checksum is also different. Basically, the flash page is replaced by another flash page with 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. Therefore, 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 security level, the hypervisor checksum mechanism is also authenticated.

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

[0041] As used herein, the term "computer" refers to any electronic device that includes a processor, such as a general-purpose central processing unit (CPU), a special-purpose processor, or a microcontroller. A computer is capable of receiving data (input), performing a series of predetermined operations thereon, and producing results (output) in the form of information or signals therefrom. Depending on the context, the term "computer" will specifically mean a processor, or more generally a processor associated with a collection of associated elements contained within a single housing or casing.

[0042] The term "processor" or "processing unit" refers to a data processing circuit, which may be a microprocessor, a coprocessor, a microcontroller, a microcomputer, a central processing unit, a field programmable gate array (FPGA), a programmable logic circuit, and / or any circuit that manipulates signals (analog or digital) based on operating instructions stored in a memory. The term "memory" refers to a storage circuit or multiple storage circuits, such as a read-only memory, a random access memory, a volatile memory, a non-volatile memory, a static memory, a dynamic memory, a flash memory, a cache memory, and / or any circuit that stores digital information.

[0043] As used herein, "computer-readable medium" or "storage medium" can be any means that can contain, store, communicate, propagate, or transport a computer program for use by or in conjunction with an instruction execution system, device, or apparatus. A computer-readable medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or propagation medium. More specific examples (a non-exhaustive list) of computer-readable media can include the following: an electrical connector having one or more conductors, a portable computer disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), optical fiber, a portable compact disk read-only memory (CDROM), a digital versatile disk (DVD), a Blu-ray disc (BD), and a memory card.

[0044] It should be noted that the above embodiments have been described with reference to different subject matters. In particular, some embodiments may have been described with reference to method type claims, while other embodiments may have been described with reference to device type claims. However, it will be apparent to those skilled in the art from the above that, unless otherwise stated, any combination of features relating to different subject matters, in particular combinations of features of method type claims and features of device type claims, in addition to any combination of features belonging to one subject type, are deemed to be disclosed with this document.

[0045] In addition, it should be noted that the accompanying drawings are schematic. In different drawings, similar or identical elements are provided with the same reference numerals. In addition, it should be noted that, in order to provide a concise description of an illustrative embodiment, the implementation details that fall into the customary practice of those skilled in the art may not be described. It should be understood that in the development of any such implementation, as in any engineering or design project, many implementation-specific decisions must be made to achieve the specific goals of the developer, such as meeting system-related and business-related constraints, which may vary depending on the implementation. Moreover, it should be understood that such development efforts may be complex and time-consuming, but for ordinary technicians, this will be a program task of design, construction and manufacture.

[0046] Finally, it should be noted that a skilled person will be able to design many alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. The words "comprise" or "comprising" do not exclude the presence of elements or steps other than those listed in the claim. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The measures stated in the claims may be implemented by means of hardware comprising several different elements and / or by means of a suitably programmed processor. In a device claim enumerating several means, several of these means may be implemented by the same hardware. The fact that certain measures are stated in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

[0047] Reference numerals list

[0048] 100 A system for applying patches to executable code;

[0049] 102 control unit;

[0050] 104 execution environment;

[0051] 106 Execution Context;

[0052] 108 Execution context;

[0053] 110 execution environment;

[0054] 112 Execution context;

[0055] 200 Methods for applying patches to executable code;

[0056] 202 Code is executed by multiple execution environments in different execution contexts;

[0057] 204 applying the patch to the code by the control unit;

[0058] 206 applying, by the control unit, a specific patch to the specific code when or after the execution environment configured to execute the specific code switches to the execution context corresponding to the specific code;

[0059] 300 Platforms with multiple execution environments;

[0060] 302 independent data / code;

[0061] 304 independent data / code;

[0062] 306JC operating system kernel;

[0063] 308 Flash Library;

[0064] 310 Management procedures;

[0065] 312 Hardware;

[0066] 314 Driver;

[0067] 400 A system for applying patches to executable code;

[0068] 402 control unit;

[0069] Form 404;

[0070] 406 Patch ID 1;

[0071] 408 Patch ID 2;

[0072] 410 Patch ID3;

[0073] 412 Patch ID 4;

[0074] 414 Patch IDn:

[0075] 500 A system for applying patches to executable code;

[0076] 502 Memory before patching;

[0077] 504 patched memory;

[0078] 506 eSE OS activities;

[0079] 508 eUICC activities;

[0080] 510 includes hardware of a memory management unit and a memory protection unit;

[0081] 51 2 Management procedures;

[0082] 514 eUICC code checksum;

[0083] 516 eSE code checksum;

[0084] 518 eUICC code checksum;

[0085] 520 eSE code checksum.

Claims

1. A system for applying a patch to executable code, characterized in that The system comprises: a plurality of execution environments configured to execute the code in different execution contexts, wherein each of the different execution contexts corresponds to a set of reserved memory resources, wherein the reserved memory resources include non-volatile and volatile memory space; comprising a control unit of a computer configured to apply the patch to the code and to receive an indication of which of the execution contexts is active; wherein the control unit is configured to, in response to an execution environment of the plurality of execution environments configured to execute a specific code of the code based on the indication switching to one of the execution contexts using its respective group of associated memory resources, apply a specific patch to the specific code, one of the execution contexts being determined to be active and corresponding to the specific code, wherein the control unit is configured to determine the specific patch to be applied by selecting a patch activated for the one execution context according to a mapping between the different execution contexts and the patches; and Wherein, the execution environment at least includes an embedded universal integrated circuit card and an embedded security element.

2. The system according to claim 1, characterized in that The patch is stored in the memory location different from the memory location where the code is stored.

3. The system according to claim 1, characterized in that The control unit is further configured to generate a checksum for the code and the patch.

4. The system according to claim 1, characterized in that The control unit is further configured to apply a shared patch, the shared patch being shared by a plurality of codes in a specific execution context.

5. The system according to claim 4, characterized in that The control unit is configured to apply the shared patch by loading the patch into a memory location shared by the code in the specific execution context.

6. The system according to claim 1, characterized in that The execution environment comprises an operating system, and wherein the patch comprises a patch of one or more codes executable by the operating system.

7. The system according to claim 1, characterized in that The code comprises an applet, and wherein the patch comprises a patch to the applet.

8. A method for applying a patch to executable code, characterized in that The method comprises: executing the code in different execution contexts by a plurality of execution environments, wherein each of the different execution contexts corresponds to a set of reserved memory resources, wherein the reserved memory resources include non-volatile and volatile memory space; applying, by a control unit comprising a computer, the patch to the code and receiving an indication of which of the execution contexts is active; applying, by the control unit, a specific patch to the specific code in response to an execution environment of the plurality of execution environments configured to execute a specific code based on the code indicated switching to one of the execution contexts using its corresponding group of associated memory resources, one of the execution contexts being determined to be active and corresponding to the specific code, wherein the control unit is configured to determine the specific patch to be applied by selecting a patch activated for the one execution context according to a mapping between the different execution contexts and the patches; and Wherein, the execution environment at least includes an embedded universal integrated circuit card and an embedded security element.

9. A computer program comprising executable instructions, characterized in that When the executable instructions are executed by a control unit, the executable instructions perform the method according to claim 8.

Images