阅读说明：本技术 用于将补丁应用于可执行代码的系统和方法 (System and method for applying patches to executable code ) 是由 安德里亚斯·莱西克 马克·伦纳德·布尔 于 2020-03-30 设计创作，主要内容包括：根据本公开的第一个方面,提供一种用于将补丁应用于可执行代码的系统,其包括：多个执行环境,其被配置成在不同的执行上下文中执行所述代码；控制单元,其被配置成将所述补丁应用于所述代码；其中所述控制单元被配置成在被配置成执行具体代码的执行环境切换到对应于所述具体代码的执行上下文时或之后,将具体补丁应用于所述具体代码。根据本公开的其它方面,构想了一种用于将补丁应用于可执行代码的对应方法,并且提供对应的计算机程序。(According to a first aspect of the present disclosure, there is provided a system for applying a patch to executable code, 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 particular patch to particular code when or after an execution environment configured to execute the particular code switches to an execution context corresponding to the particular code. According to other aspects of the present disclosure, a corresponding method for applying patches to executable code is contemplated, and a corresponding computer program is provided.)

1. A system for applying a patch to executable code, 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 particular patch to particular code when or after an execution environment configured to execute the particular code switches to an execution context corresponding to the particular code.

2. The system of claim 1, further comprising a mapping between execution context and patches, wherein the control unit is configured to determine the particular patch to apply by selecting a patch to activate for the execution context according to the mapping.

3. The system of any preceding claim, wherein the patch is stored in a memory location different from a memory location in which the code is stored.

4. The system of any preceding claim, wherein the control unit is further configured to generate a checksum over the code and the patch.

5. The system of any preceding claim, wherein the control unit is further configured to apply a shared patch, the shared patch being shared by a plurality of codes in a particular execution context.

6. The system as recited in claim 5, wherein the control unit is configured to apply the shared patch by loading the patch into a memory location shared by the code in the particular execution context.

7. The system of any preceding claim, wherein the execution environment comprises an operating system, and wherein the patch comprises a patch of one or more codes executable by the operating system.

8. The system of any preceding claim, wherein the code comprises an applet, and wherein the patch comprises a patch for the applet.

9. A method for applying a patch to executable code, comprising:

executing the code in different execution contexts by a plurality of execution environments;

applying, by a control unit, the patch to the code;

applying, by the control unit, a particular patch to a particular code upon or after switching an execution environment configured to execute the particular code to an execution context corresponding to the particular code.

10. 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 9.

Technical Field

The present disclosure relates to a system for applying patches to executable code. Furthermore, the present disclosure relates to a corresponding method for applying a patch to executable code, and a corresponding computer program.

Background

A mobile device, such as a smartphone, may contain several execution environments in which executable code is executed. For example, mobile phones often contain so-called embedded universal integrated circuit cards (euiccs) and embedded secure elements (eses). The 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 is compliant with the GSMA specification. The eSE is a tamper-resistant chip that can be embedded into any mobile device. In particular, the Secure Element (SE) may be a tamper-resistant integrated circuit with installed or pre-installed smart card-level applications, such as payment applications, having a defined function and a defined security level. In addition, the secure element may implement security functions, such as encryption functions and authentication functions. Different execution environments of a mobile device typically execute applications that are not related to each other. For example, the eUICC can execute applications related to mobile network communications, and the eSE can execute applications related to Near Field Communication (NFC) transactions.

Disclosure of Invention

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

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

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

In an embodiment, the control unit is further configured to generate a checksum on the code and the patch.

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

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.

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

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

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

In an embodiment, the code comprises an applet and the patch comprises a patch for the applet.

According to a second aspect of the present disclosure, a method for applying a patch to executable code is contemplated, comprising: executing the code in different execution contexts by a plurality of execution environments; applying, by a control unit, the patch to the code; applying, by the control unit, the particular patch to the particular code upon or after switching an execution environment configured to execute the particular code to an execution context corresponding to the particular code.

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

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

In an embodiment, the control unit generates a checksum over the code and patch.

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 forth.

Drawings

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

FIG. 1 shows an illustrative embodiment of a system for applying patches to executable code;

FIG. 2 shows an illustrative embodiment of a method for applying a patch to executable code;

FIG. 3 shows an illustrative embodiment of a platform having multiple execution environments;

FIG. 4 shows another illustrative embodiment of a system for applying patches to executable code;

FIG. 5 shows another illustrative embodiment of a system for applying patches to executable code.

Detailed Description

A mobile device, such as a smartphone, may contain several execution environments in which executable code is executed. For example, mobile phones often contain so-called embedded universal integrated circuit cards (euiccs) and embedded secure elements (eses). The 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 is compliant with the GSMA specification. The eSE is a tamper-resistant chip that can be embedded into any mobile device. In particular, the Secure Element (SE) may be a tamper-resistant integrated circuit with installed or pre-installed smart card-level applications, such as payment applications, having a defined function and a defined security level. In addition, the secure element may implement security functions, such as encryption functions and authentication functions. Different execution environments of a mobile device typically execute applications that are not related to each other. For example, the eUICC can execute applications related to mobile network communications, and the eSE can execute applications related to Near Field Communication (NFC) transactions.

In addition to a general-purpose operating system containing executable code, such as a Java Card (JC) operating system, which may be shared by several execution environments, each execution environment may also contain specialized executable code, such as Java virtual machines and Global Platform (GP) code. Further, the JC operating system may contain, for example, a kernel, a flash library, and a driver. Each of these components includes executable code that sometimes needs to be patched. However, for security reasons, the code should be authenticated before use. Such security authentication is both expensive and time consuming. Therefore, the security authentication should not be performed too frequently.

Today, devices that include secure elements integrate many functions in the operating system. Further, a service provider (such as a payment service provider) may require 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, patches of code will also require re-authentication. Furthermore, if the operating system's credentials change, the applet executing on the operating system should also be re-authenticated. Therefore, the functional testing of the applet should also be repeated. This is both expensive and time consuming, as typically multiple applets should be authenticated. A system and method for applying patches is now described that may reduce the need for re-authentication of that type.

FIG. 1 shows an illustrative embodiment of a system 100 for applying patches to executable code. The system 100 includes multiple execution environments 104, 110, the multiple execution environments 104, 110 configured to execute code in different execution contexts 106, 108, 112. In other words, each execution environment 104, 110 may execute code in one or more execution contexts 106, 108, 112. Examples of execution contexts are payment contexts and common transport contexts, where different applets are executed and specific operating system resources are reserved for them. Further, the system 100 includes a control unit 102 operatively coupled to the execution environments 104, 110. The control unit 102 is configured to apply the patch to the code. Further, the control unit 102 is configured to apply a particular one of the patches to a particular one of the code when or after an execution environment configured to execute the particular code switches to an execution context corresponding to the particular code. In this way, patches can be dynamically applied for the target context. It should be noted that a patch may be a small piece of code that is inserted into a program to improve its functionality or correct errors, or more generally, any code that modifies or updates existing code.

In particular, the operating system will switch between different execution contexts to facilitate execution of specific code (e.g., operating system code and applets). Switching to a particular context serves as a trigger to apply a particular patch to code executing in that context. The patch does not apply to code executing in other contexts. Thus, code executing in other contexts does not change and does not need to be re-authenticated. It should be noted that a context refers to a set of allocated resources, e.g., a set of loaded variables and/or reserved memory locations, for executing an application within the context. For example, 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 dedicated non-volatile and volatile memory space. The executing applet is also context specific. Thus, if an applet is loaded into one context, it typically cannot execute in another context unless it is loaded into another context. Global variables may also be context specific and they may be replicated if needed so that each context has its own variable. It should be noted that different contexts may share the same code, but typically do not share data.

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 apply by selecting the patch to activate for the execution context 106, 108, 112 according to the mapping. In this way, it becomes easier to apply patches dynamically for the target context. The mapping may for example be implemented 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.

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

In an embodiment, the control unit 102 is further configured to apply a shared patch. These patches are shared by multiple codes in a particular execution context. For example, not only can payment context and common transport context be differentiated, but the complete eSE or eUICC can be considered a higher level execution context. In that case, the shared patch may be applied to all code in a given context. This shared patch may also be applied dynamically. In a practical and efficient implementation, the control unit 102 is configured to apply the shared patch by loading the shared patch into a memory location shared by code in a specific execution context. Alternatively, the shared patches may be applied by activating them at the current memory location, i.e., without loading them into the shared memory location, such as by using a hardware observation point.

In an embodiment, the control unit 102 is a hypervisor or a general purpose operating system. The hypervisor results in a practical and efficient implementation. A hypervisor or Virtual Machine Monitor (VMM) is computer software, firmware, or hardware that creates and runs virtual machines. Thus, it can control virtual machines that implement different execution environments. The control unit 102 may also be implemented in a general-purpose operating system such as a JC operating system kernel. As described above, an execution environment may include at least an embedded universal integrated circuit card (eUICC) and an embedded secure element (eSE).

In an embodiment, the execution environment includes an operating system and the patch includes 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 for the applet.

FIG. 2 shows an illustrative embodiment of a method 200 for applying a patch to executable code. The method 200 comprises the following steps: at 202, code is executed in different execution contexts by multiple execution environments; applying, by the control unit, a patch to the code at 204; and at 206, applying, by the control unit, the particular patch to the particular code upon or after switching an execution environment configured to execute the particular code to an execution context corresponding to the particular code. In this manner, patches may be dynamically applied for the target context, as described above.

FIG. 3 shows an illustrative embodiment of a platform 300 with multiple execution environments. The execution environments contain independent data and code 302, 304, meaning that data and code in one execution environment is not dependent on data and code in another execution environment. In the example, the eUICC is one execution environment that contains independent data and code 304, and the eSE is another execution environment that contains independent data and code 302. The eUICC contains one execution context, i.e., for executing mobile network applications, and the eSE contains two execution contexts, one for executing common transport applications (transport applets) and one for executing payment applications (EMV applets). The execution environment may also be referred to as a domain. The common operating system 306, which in this example is the JC operating system kernel, provides separation of the eSE and eUICC domains. For example, in addition to code shared between different domains, there may be dedicated code and data, i.e., code and data that is specific to and used only in the respective domains. In this sense, the combination of shared code and specialized code and data for a given domain can be viewed as independent operating systems. The independent operating systems of the eSE domains may, for example, support the execution of payment, delivery, authentication, e-government, and ultra-wideband (UWB) applications. The standalone operating system of the eUICC domain can support execution of mobile network applications. The two operating systems will work independently of each other. Hypervisor 310 manages switching between different execution contexts. Thus, the hypervisor will know which execution context is active at a given time. As described above, the eSE domain and the eUICC domain as a whole can be considered as different execution contexts. In addition, different execution contexts can be distinguished within a particular domain (e.g., a payment context and a common delivery context within an eSE domain). Hypervisor 310 is configured to manage these contexts. In such cases, the JC operating system may have to inform the hypervisor that a particular execution context becomes active in a given domain. The hypervisor may then enable or disable the corresponding patch or patches for the context.

FIG. 4 shows another illustrative embodiment of a system 400 for applying patches to executable code. 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 activity execution context, the control unit 402 may apply the patches 406, 408, 410, 412, 414 by looking up which of the patches 406, 408, 410, 412, 414 are mapped to the activity 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 patches identified as ID2 should be applied, and the payment context is active, patches identified as ID2 and ID4 should be applied.

More specifically, control unit 402 (e.g., a general purpose 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 page) and assigned to one or more execution contexts (which is the patch's meta-information). The control unit 402 stores the information in a 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 may apply the patch or patches.

FIG. 5 shows another illustrative embodiment of a system 500 for applying patches to executable code. Specifically, the state of the memory 502 before patching is shown, as well as the state of the memory 504 after patching. The shared code patch applies 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 does not apply to the shared code. In addition, a patch of eSE code is applied. The system 500 includes a hypervisor 512 configured to control a hardware-based Memory Management Unit (MMU) or a Memory Protection Unit (MPU). As explained with reference to fig. 4, the hypervisor 512 looks up in the 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 for activating patches for a given context. For example, a viewpoint vector or a branch table may be used. In addition, code and other data related to the inactive context may be blocked by the MPU.

For execution contexts that do not use patches, a checksum may be applied to prove that the original authentication code, unmodified, is still executing. In particular, as shown in FIG. 5, 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 run time in the current active context. To this end, the operating system or hypervisor 512 will support Application Programming Interfaces (APIs) or Application Protocol Data Units (APDUs). The checksum may be compared to a checksum originally constructed for authentication. Each domain or context will have a dedicated checksum, e.g., one for the eUICC and one for the eSE. If a small patch is applied, hypervisor 512 will map the new code to a shared memory region (either via the MMU or via a re-order map-ram). This changes the code visible in the current domain and therefore the checksum is also different. Basically, a 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 invoke this new location, the original code must be modified to jump to or invoke the new function. This will change the checksum. Thus, in both cases, the checksum mechanism may provide the desired proof. In addition, the hypervisor patching mechanism may include patch code in the checksum calculation. To improve the security level, the hypervisor checksum mechanism is also authenticated.

The systems and methods described herein may be implemented, at least in part, by a computer program or multiple computer programs that may exist in multiple forms, both active and inactive, in a single computer system or across multiple computer systems. For example, they may exist as software programs comprised of program instructions in source code, object code, executable code or other formats for performing some 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.

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 a result (output) therefrom in the form of information or a signal. 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, depending on the context.

The term "processor" or "processing unit" refers to a data processing circuit that 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 operational instructions stored in memory. The term "memory" refers to a storage circuit or circuits, such as read-only memory, random access memory, volatile memory, non-volatile memory, static memory, dynamic memory, flash memory, cache memory, and/or any circuit that stores digital information.

As used herein, a "computer-readable medium" or "storage medium" can be any means that can contain, store, communicate, propagate, or transport the computer program for use by or in connection with the instruction execution system, apparatus, or device. The 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 the computer-readable medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CDROM), a Digital Versatile Disc (DVD), a blu-ray disc (BD), and a memory card.

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 apparatus type claims. However, a person skilled in the art will gather from the above that, unless other notified, in addition to any combination of features belonging to one type of subject matter also any combination of features relating to different subject matters, especially combinations of features of the method type claims and features of the apparatus type claims are considered to be disclosed with this document.

Further, it should be noted that the drawings are schematic. In different drawings, similar or identical elements are provided with the same reference numerals. Furthermore, it is noted that in order to provide a concise description of the illustrative embodiments, implementation details that fall within the customary practice of those skilled in the art may not be described. It should be appreciated that in the development of any such actual implementation, as in any engineering or design project, numerous implementation-specific decisions must be made to achieve the developers' specific goals, such as compliance with system-related and business-related constraints, which may vary from one implementation to another. Moreover, it should be appreciated that such a development effort might be complex and time consuming, but would nevertheless be a routine undertaking of design, fabrication, and manufacture for those of ordinary skill.

Finally, it should be noted that the 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 word "comprising" or "comprises" does not exclude the presence of elements or steps other than those listed in a claim. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The measures recited in the claims can be implemented by means of hardware comprising several distinct elements, and/or by means of a suitably programmed processor. In the device claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

List of reference numerals

100 a system for applying patches to executable code;

102 a control unit;

104 an execution environment;

106 an execution context;

108 an execution context;

110 an execution environment;

112 execution context;

200 a method for applying a patch to executable code;

202 executing code in different execution contexts by multiple execution environments;

204 applying, by the control unit, the patch to the code;

206 applying, by the control unit, a particular patch to the particular code upon or after switching an execution environment configured to execute the particular code to an execution context corresponding to the particular code;

300 a platform having a plurality of execution environments;

302 independent data/code;

304 independent data/code;

306JC operating system kernel;

308 a flash memory bank;

310 a hypervisor;

312 hardware;

314 driver;

400 a system for applying patches to executable code;

402 a control unit;

404 table;

406 patch ID 1;

408 patch ID 2;

410 patch ID 3;

412 patch ID 4;

patch 414 IDn:

500 a system for applying patches to executable code;

502 memory before patching;

504 the patched memory;

506 eSE OS activity;

508 eUICC activity;

510 hardware including a memory management unit and a memory protection unit;

512 a hypervisor;

514 eUICC code checksum;

516 eSE code checksum;

518 eUICC code checksum;

the 520 eSE code checksum.