Secure Element with optimized bytecode

Abstract

The invention relates to a secure element, in particular a smart card, configured for executing bytecode in a runtime environment and / or an applet, wherein the secure element is configured to allocate a user-defined bytecode to a free bytecode area that is unused according to the programming language specification. The smart card is further configured to provide a mapping table for converting the user-defined bytecode into a standard bytecode sequence, the conversion being performed depending on the context of the use of the user-defined bytecode. This solution enables memory savings.

Description

Field of the invention

[0001] The invention relates to a secure element configured to execute bytecode in a runtime environment and / or an applet, in particular a secure element based on Java Card technology that enables optimized memory space utilization of Java bytecode, in particular a chip card. Furthermore, the invention relates to a method for executing bytecode in a runtime environment and / or an applet, a secure element, and a computer program or applet that can execute the method. Technical background

[0002] Java is a widely used programming language that plays an important role in smart card technology due to its platform independence and security features. This independence is made possible by the use of a virtual machine (VM), which abstracts the respective hardware from the software applications. Despite their diverse applications in smart cards, the use of Java applets is limited because, for example, they do not allow direct memory access. However, this represents a security advantage, as it prevents an applet from being used as a virus to compromise the smart card's operating system (OS) or applets from other manufacturers.

[0003] A key aspect of smart card technology is the memory capacity of smart cards, which has a significant impact on pricing. The smart card's operating system already occupies a large portion of the memory. The remaining limited memory can be used for custom applets. Through careful design and sophisticated implementations, the memory requirements for the operating system could be significantly reduced while maintaining the same functionality. Such an approach opens up potential economic benefits, either in the form of higher profit margins or as a competitive advantage through lower prices.

[0004] An important method for saving memory is bytecode optimization. Java uses bytecodes, short instruction sequences, of which there are 223 different types. In addition, there are 33 free bytecodes that can be used to define custom instructions. To execute these free bytecodes, the VM must be extended.

[0005] A well-known approach to bytecode optimization defines free bytecodes as short forms of longer bytecodes and calls them "optimized bytecodes" (OBC). An example of this is the instruction to increment a counter by 1, which is implemented using an optimized bytecode that is detected in the VM and reduced to a general addition. In practice, this approach saves approximately 8% of memory, which represents a significant contribution to memory savings.

[0006] However, the known approaches have disadvantages.

[0007] Independence between the operating system and applets regarding the use of optimized bytecode is not guaranteed, which limits potential memory savings. Furthermore, applets with optimized bytecode can only be installed on an operating system that implements the same optimized bytecode, resulting in increased maintenance and administration effort and the need for multiple functionally identical applet versions. Furthermore, effective bytecode optimization of an applet may require a labor-intensive and not always practical adaptation of the operating system to the applet's bytecode in order to save the maximum possible memory.

[0008] US Pat. No. 5,905,895 A describes a concept for optimizing "non-native" bytecode, such as Java bytecode, before it is interpreted. However, the described concept only allows for limited memory reduction, particularly because the size of the optimized bytecode is only slightly smaller than that of the original bytecode. Object of the invention

[0009] The invention is based on the object of providing a concept that enables an effective reduction in memory space of applets executed on a secure element / chip card / smart card, whereby the dependency between applets and operating system is reduced. Summary of the invention

[0010] The object is achieved by a secure element according to claim 1 and a method and a computer program or applet according to claims 14 and 15.

[0011] Some of the terms used in this application are briefly explained below.

[0012] The term "Secure Element" is synonymous with the terms "UICC," "eUICC," "iUICC," "Subscriber Identity Module," "Chip Card," "iUICC," "Integrated eUICC," "Integrated Secure Element," "Embedded Secure Element," "Secure Element," "SIM," "eSIM," or "iSIM." Secure Elements also include USIM, TSIM, ISIM, CSIM, or R-UIM.

[0013] A secure element, or SE for short, within the meaning of the invention is an electronic module with reduced size and resource scope, which has a control unit (microcontroller) and at least one interface (data interface) for communication with entities located outside the secure element, such as end devices, servers, etc. This communication preferably takes place via a connection protocol, in the case of a secure element, in particular a protocol according to the ETSI TS 102 221 or ISO-7816 standard.

[0014] The secure element can also be a software component in a trusted part of the device's operating system, a so-called Trusted Execution Environment (TEE). The secure element is implemented, for example, within a secure runtime environment in the form of programs running within it, so-called "trustlets."

[0015] The secure element can also be an integral component of a larger integrated circuit, such as a modem or application processor. Such UICCs are referred to as "integrated UICC," "integrated TRE," "integrated eUICC," or "integrated SE." Such secure elements are permanently integrated into an SoC as an integrated processor block and can be connected via an on-chip bus.

[0016] The Secure Element can be used for remote monitoring, control, and maintenance of devices such as machines, plants, and systems. It can be used for metering units such as electricity meters, hot water meters, etc. The Secure Element is, for example, a component of IoT technology.

[0017] The SE can also be an integral component of a larger integrated circuit, such as a modem or application processor. Such SEs are referred to as "integrated UICC," "integrated TRE," "integrated eUICC," or "integrated SE." Such SEs are permanently integrated into an SoC as an integrated processor block and can be connected via an on-chip bus. The SE, for example, has an internal or external secure non-volatile memory area in which the identity data is securely stored to prevent attempts at manipulation and / or misuse during identification and / or authentication on the network.

[0018] In one embodiment, the SE can be operable via a terminal device, whereby the SE in this embodiment is autonomous except for supply signals such as supply voltage, clock, reset, etc. The SE can then have an interface (data interface) for communication with the terminal device, into which the SE is possibly integrated in a ready-to-use state. This communication preferably takes place via a connection protocol, in particular a protocol according to the ETSI TS 102 221 or ISO 7816 standard.

[0019] The term "end device" is preferred here, as the end device in communications technology can primarily be a "terminal." This does not preclude the "end device" from being a "device" in a different technology. The terms "end device" and "device" are used synonymously here.

[0020] The SE can be used for remote monitoring, control, and maintenance of devices such as machines, plants, and systems. It can be used for metering units such as electricity meters, hot water meters, etc. The SE is, for example, a component of IoT technology.

[0021] A terminal device within the meaning of the invention is essentially a device or device component with means for communicating with a communications network, for using services of the communications network, or for using services of a server via a gateway of the communications network. For example, this term encompasses a mobile device such as a smartphone, a tablet PC, a notebook, or a PDA. The term "terminal device" can also include multimedia devices such as digital photo frames, audio devices, televisions, and e-book readers, which also have means for communicating with the communications network.

[0022] In particular, the terminal device is installed in a machine, a vending machine and / or a vehicle. If the terminal device is installed in a motor vehicle, it has an SE integrated, for example. The SE can use the terminal device, for example a modem of the terminal device, to establish a data connection to a server via the communications network. The terminal device can, for example, be used to contact a server of the terminal device manufacturer in order to address control units, e.g. ECUs (ECU = Electronic Control Unit) for functionalities of the terminal device. A server in the background system of the mobile network operator, MNO, can be contacted via the UICC, for example a server to load updates for software, firmware and / or the operating system of the SE into the SE.

[0023] In addition to smartphones and mobile phones, mobile radio-enabled devices also include control devices (control devices or measuring devices, or combined control / measuring devices) for industrial facilities in commercial or private environments. Industrial facilities include, for example, production plants that have one or more control devices (end devices) that can communicate with a backend system and / or with each other via a mobile network. Other industrial facilities include smart home devices such as heating systems or power consumers with end devices in the form of control devices.

[0024] The secure element could be part of an Internet of Things (IoT) device, particularly using Java applets (or other bytecode). IoT devices may be mass-produced, therefore highly price-sensitive and subject to storage limitations.

[0025] A chip card, as an example of a secure element, refers to a card with an embedded microchip. This microchip can perform various functions, such as processing data and / or providing storage functionality. The microchip can include memory such as RAM or flash memory and / or a digital signal processor (DSP) and / or an application-specific integrated circuit (ASIC).

[0026] A smart card is a card with a built-in microprocessor that can perform more complex functions than a microchip, such as cryptographic operations.

[0027] Applet refers to a small program, preferably a Java program, that runs on a Secure Element and performs specific tasks, such as a payment transaction or the management of identification information.

[0028] Virtual Machine (VM) refers to software that enables commands programmed on the Secure Element hardware to be executed independently of specific hardware details.

[0029] Java Virtual Machine (JVM) is a software that enables the execution of Java applets on the Secure Element by converting Java bytecode into machine-readable instructions.

[0030] A runtime environment is software that provides services and resources to programs or applications, enables their interaction with the operating system and hardware, and manages the execution of program code. It typically includes functions for memory management, error handling, and interaction with the operating system.

[0031] In the hardware context, Java Card refers to a smart card or chip card that provides a Java runtime environment and can execute Java applets, and in the software context, it refers to an open application development framework and a technology specification that enables the development and deployment of Java applications (Java Card Applets) on smart cards and chip cards.

[0032] Bytecode is a special form of digital instructions that can be executed by a virtual machine (VM). Bytecode is platform-independent and can be executed on any hardware that has a suitable VM. Each instruction is typically at least one byte or several bytes in size. Bytecode is therefore compact and space-saving, which is especially important for resource-constrained systems such as secure elements, such as chip cards.

[0033] Free bytecode refers to a bytecode instruction that is not used in the current system implementation and is therefore available for defining special or user-defined instructions.

[0034] Optimized bytecode is a special version of bytecode that uses more efficient or compact instructions to save memory space. In Java programming, for example, unused bytecode can be used to shorten common instruction patterns and thus represent them more efficiently. Using optimized bytecode requires adjustments in the virtual machine to correctly interpret and execute these new instructions.

[0035] The punctuation mark “ / ” (slash) is understood as “or”.

[0036] One aspect of the invention relates to a secure element, in particular a chip card, which is configured to execute bytecode. The secure element is configured to execute the bytecode in a runtime environment and / or an applet on the secure element. The secure element is configured to allocate a free bytecode in a bytecode area that is unused according to the specification of the programming language as a user-defined bytecode and to provide an assignment table for converting the user-defined bytecode into a standard bytecode sequence comprising at least one standard bytecode, wherein the conversion takes place depending on the context of use of the user-defined bytecode. These features of the secure element, in particular the assignment of a user-defined bytecode to a free bytecode, have the technical effect of saving memory space.A standard bytecode sequence can consist of one or more standard bytecodes.

[0037] A further aspect of the invention relates to a method for executing bytecode in a runtime environment and / or an applet or a secure element. The method comprises allocating a free bytecode in a bytecode range that is unused according to the specification of the programming language as a user-defined bytecode and providing an assignment table for converting the user-defined bytecode into a standard bytecode sequence comprising at least one standard bytecode, wherein the conversion occurs depending on the context of use of the user-defined bytecode. In this step, the free bytecode is assigned to a user-defined bytecode. This assignment achieves a memory saving.

[0038] A further aspect of the invention relates to a computer program or applet which carries out the method described above when the computer program or applet is loaded into the memory of a previously described secure element and / or executed on the secure element.

[0039] The features and mechanisms associated with the described aspects of the invention are described below.

[0040] Bytecode is a form of instruction set designed for efficient execution by a software interpreter such as a virtual machine. Bytecode executability on the Secure Element means that the Secure Element can run applications that are i) coded in a high-level language such as Java and then translated into bytecode, or ii) or at least partially coded directly in bytecode.

[0041] The Secure Element is configured to execute bytecode in a runtime environment and / or an applet on the Secure Element. This includes the following aspects: - When the bytecode in the applet is executed, this can happen when the applet is called due to a specific event. The applet then operates within the runtime environment, which provides the services and resources the applet needs. - When executed in the runtime environment, the bytecode is not tied to a specific user event and can be part of the secure element's system-level operations. This can include initializing the card, managing resources, or performing security operations. - The execution of bytecode in both the runtime environment and the applet indicates a layered execution structure, where bytecode can be executed both at the system level in the runtime environment and at the application level in the applet. This hierarchical structure enables structured and efficient execution of tasks and functions on the secure element.

[0042] The secure element is configured to allocate a free bytecode in a bytecode range that is unused according to the specification of the programming language as a user-defined bytecode and to provide a mapping table for converting the user-defined bytecode into a standard bytecode sequence comprising at least one standard bytecode, wherein the conversion is performed depending on the context of use of the user-defined bytecode.

[0043] Allocating a free bytecode in a bytecode area that is not used according to the programming language specification means that the core functionality of the secure element is not affected or disrupted by this process.

[0044] Allocating a free bytecode with a context-dependent implementation in the form of custom bytecode refers to the dynamic nature of the secure element's functionality. The term implementation refers to overwriting or modifying the bytecode to increase execution efficiency. This may mean modifying the virtual machine or applet to change the bytecode's memory footprint (the amount of memory occupied by the custom bytecode) depending on the circumstances or context in which the free bytecode is used. By allocating free bytecode to custom bytecode, the functionality of a standard bytecode with a specific memory footprint can be transferred to a custom bytecode with a smaller memory footprint, thereby saving memory space.

[0045] Advantageous embodiments of the invention are described below. Each embodiment or its features can be combined with any other embodiment and / or aspect of the invention, provided this is technically feasible and / or permissible. For example, features illustrated or described as part of one embodiment can be used in or in conjunction with another embodiment to obtain a further embodiment.

[0046] According to one embodiment, the custom bytecode may be referred to as optimized bytecode due to the memory savings.

[0047] According to one embodiment, the programming language can be Java. This ensures compatibility and interoperability with a wide variety of systems and applications, as Java is platform-independent. Advantageously, this can lead to simpler implementation, broader use of the secure element, and greater flexibility, as Java is a widely used programming language with a rich ecosystem of libraries and tools. In this case, the unused bytecode range is preferably a range of hexadecimal values ​​between 0xCA and 0xFF, preferably between 0xCB and 0xFD.

[0048] According to one embodiment, the secure element can be a chip card, preferably a Java card. Preferably, the runtime environment can be a Java runtime environment and / or the programming language specification can be a Java specification. This ensures compatibility with the security, portability, and object-oriented features of Java and increases the robustness and versatility of the secure element. This configuration can increase the security and interoperability of the secure element with various applications and devices, thus promoting wider acceptance and use across various industries and applications.

[0049] According to one embodiment, the context may be determined by whether the bytecode is located in the operating system of the secure element or in an applet loaded onto the secure element. The context that determines the allocation of a free bytecode may depend on whether the bytecode is located in the operating system of the secure element or in an applet loaded onto the secure element.

[0050] If the bytecode is located within the operating system, the context is recognized as the secure element's operating system. This means that the specific implementation and interpretation of the assigned bytecode depends on the specific properties and requirements of the secure element's operating system, which can be important for core functionality and higher-level resource management.

[0051] If the bytecode is located within an applet loaded on the secure element, the context is identified as that specific applet. The specific interpretation and implementation of the bytecode then depends on the specific requirements of the applet. Since applets often perform specialized tasks compared to the operating system, this distinction enables more targeted optimizations that meet the requirements of the specific applet.

[0052] This approach thus creates a flexible system in which the allocation of free bytecodes can be fine-tuned according to the specific requirements of the operating system or an applet, using the context-dependent allocation process to increase efficiency and performance.

[0053] According to one embodiment, the context may comprise a package in which the bytecode is located. Preferably, the context may comprise a class to which the bytecode belongs and / or be determined by the type of a method in which the bytecode is located, wherein the method may in particular be an instance method, a constructor, or a static method.

[0054] In object-oriented programming languages ​​commonly used for secure elements, especially Java or, where appropriate, C++, Python, or JavaScript, a package is a grouping of related classes, interfaces, and subpackages. If the context is defined as the package in which the bytecode resides, the allocation of free bytecode is determined by the specific requirements and properties of that particular package. This can enable tailored memory savings at the package level.

[0055] Similarly, a class is a blueprint from which individual objects are created. If the context is defined as the class to which the bytecode belongs, the custom bytecode assigned to the free bytecode depends on the specific needs of that class. This allows for fine-grained memory savings at the class level, meeting the specific needs of each class.

[0056] In addition, the context can also be determined by the type of method in which the bytecode is located. Methods can be instance methods (belonging to an instance of a class), constructors (special methods called when a new object is created), or static methods (belonging to the class itself and not to any object). The specific requirements of these different types of methods can provide an even more granular level of context and enable corresponding memory savings.

[0057] For example, a constructor method may require a different bytecode implementation than a static method because they play a different role in object-oriented programming. This implementation can lead to a corresponding design of bytecode allocation, which can result in even better memory utilization or storage space savings.

[0058] According to one embodiment, the secure element can be configured to provide a mapping table for converting user-defined bytecode into context-dependent standard bytecode sequences, thereby determining the implementation of the free bytecodes. The mapping table plays a crucial role in converting user-defined bytecode, which has been assigned context-dependently, into standard bytecode sequences, and the user-defined bytecode can be considered equivalent to the optimized bytecode. It refers to bytecodes located in a specific range [0xCA..0xFF], preferably [0xCB..0xFD], which is not used according to the Java specification but is used here to save memory space.

[0059] The mapping table provides a way to translate user-defined bytecode back into standard bytecode according to the requirements / definitions of the programming language (in this context, Java). Depending on the context in which a user-defined bytecode is encountered, the secure element uses the corresponding mapping table to convert it back into standard bytecode sequences. This mechanism allows the secure element to dynamically and efficiently allocate free bytecode according to the specific requirements of each context. Once the bytecode has served its purpose and can be interpreted or executed, the mapping table ensures that it is converted back into standard bytecode. This improves memory utilization and increases the performance and flexibility of the secure element.

[0060] According to one embodiment, the secure element can be configured to identify various contexts using the mapping table, including i) the operating system of the secure element and / or ii) the applet and / or iii) the package and / or iv) the class and / or the type of the method. This enables specific assignment of the free bytecodes with user-defined bytecodes.

[0061] As mentioned earlier, a context can be the secure element's operating system, an applet loaded onto the secure element, a package containing the bytecode, or a class or method type containing the bytecode. Each of these contexts may have specific requirements, and the specific implementation assigned to the bytecode may vary depending on the context.

[0062] The mapping table supports this process by converting user-defined bytecode, which is allocated for optimal memory usage depending on the context, back into standard bytecode sequences whose individual bytecodes are defined in the programming language. The mapping table also distinguishes between these different contexts and enables specific implementations based on the specific requirements of a particular context.

[0063] For example, optimized bytecode used in the context of an operating system may be mapped to a different standard bytecode or bytecode sequence than the same optimized bytecode used in the context of an applet or a specific class. This context-dependent mapping makes the system flexible and can lead to efficient memory usage and better overall performance.

[0064] According to one embodiment, the secure element may be configured to perform combined storage of the mapping table on the secure element, regardless of whether the actual storage location is in the context's memory area, in order to enable faster access to the bytecodes. In this context, the term "combined" refers to the way the mapping tables are stored on the secure element. Combined storage refers to a consolidated or unified form of storage in which mapping tables relating to different contexts are not scattered or stored separately in the memory areas of the respective contexts, but are consolidated in a central location on the secure element.

[0065] While a mapping table can be associated with a specific context, this does not necessarily mean that its actual storage location must be within the context's memory space. Instead, combined storage can occur within the secure element, which is beneficial for faster access. This means that the secure element is designed so that the mapping tables that help convert custom bytecodes into standard bytecodes are stored together on the map and not scattered across different contexts. This allows for faster access to the mapping tables and, consequently, to the bytecodes, resulting in faster execution and better overall performance.

[0066] According to one embodiment, the Secure Element may be configured to provide a separate mapping table for each applet when multiple applets are deployed, to improve memory utilization and avoid incompatible combinations of operating system and applets. This extends the concept of using context-aware mapping tables and applies it to a scenario involving multiple applets, each with its own requirements and behavior. To handle such a scenario efficiently and effectively, the Secure Element may be configured to provide a separate mapping table for each applet, allowing each applet to map its context-specific, custom bytecodes to standard bytecodes.

[0067] This enables improved memory utilization. Since each applet receives its own mapping table tailored to its specific requirements, the custom bytecodes can be mapped optimally and in a memory-efficient manner, as each mapping table only handles the specific contexts relevant to its applet.

[0068] Separate mapping tables make it possible to avoid incompatible combinations of operating system and applets, as the risk or likelihood of incompatibilities between the operating system and applets is reduced. The mapping tables of individual applets can be independent of each other, ensuring that the bytecode optimizations used in the operating system and in the individual applets are different and specifically tailored to the needs of each applet. This means that no applets optimized specifically for each operating system are required, eliminating or at least reducing the risk of mismatches.

[0069] According to one embodiment, the mapping table may include difference tables. Changes in bytecode mappings can be captured relative to a master mapping table. This can improve memory efficiency, since maintaining a complete mapping table in every context is not practical for storage reasons. Each entry in this table can occupy 3-6 bytes, which in turn must be saved through corresponding storage space savings in the actual bytecode of the package, class, etc. To improve memory efficiency, mapping tables are therefore stored as difference tables.

[0070] A difference table is a version of the mapping table that stores only changes or differences from a master mapping table, which is a mapping table of a higher-level context. This means that the difference tables do not store the complete mapping information for each context, but only the changes made in that specific context compared to a more general or master context.

[0071] This approach improves storage efficiency by reducing the amount of information that needs to be stored for each context. Only the differences or changes compared to the more general, parent context / master context are stored, not the entire mapping information.

[0072] This approach allows the smart card to detect changes in bytecode mappings. The difference tables allow for quick comparison with the master mapping table or the higher-level context mapping table. If a difference exists, it can be easily detected and corrected.

[0073] According to one embodiment, the master mapping table may be a basic mapping table comprising a set of user-defined bytecode mappings valid for different contexts. The master mapping table may serve as a base or standard set of mappings that may be valid for multiple contexts. It is essentially a collection of mappings of user-defined bytecodes to the corresponding standard bytecodes, designed to save memory space.

[0074] This allows the master mapping table to be valid across contexts. Consequently, bytecode mappings defined in this mapping table can be used in different contexts, unless a specific context has a difference table that overrides these mappings. This approach enables a generalized solution for bytecode execution across the entire secure element, providing basic functionality that can be specialized for different contexts as needed. It contributes to optimal memory efficiency by avoiding the repetition of common bytecode mappings across different contexts.

[0075] According to one embodiment, a difference table may be configured to replace, for a context subordinate to the master mapping table (a more specific context or a context nested within another context), the user-defined bytecode with a bytecode that provides greater memory efficiency in that context.

[0076] If a bytecode in a specific context, such as a class within an applet, is replaced with another bytecode that is more memory efficient in that context, this change is noted in the difference table for that context. Replacing bytecode serves to achieve greater memory efficiency in the respective context. This ensures that each context is individually optimized, resulting in better overall memory utilization across the entire secure element.

[0077] The advantage of this approach is that it enables local optimization. Each context can adjust its bytecode mapping to achieve the best possible memory efficiency, while still relying on the master mapping table for general cases. This ensures a balance between memory efficiency and maintainability of the bytecode mappings.

[0078] According to one embodiment, the difference table may be configured as a dense array, wherein the dense array defines a first bytecode value and a last bytecode value that is overwritten with respect to the next higher context, with bytecode values ​​in between also being overwritten. A dense array may be a data structure in which all elements between the first and last are explicitly defined. In the context of the difference table, this means that all bytecode values ​​between the first and last are overwritten.

[0079] The first and last bytecode values ​​refer to the range of bytecodes that are redefined or overwritten in a given context relative to the next higher context. All bytecode values ​​within this range are also overwritten.

[0080] Using a dense array for the difference table has several advantages. First, because all values ​​are explicitly defined and stored contiguously, lookup operations on such an array can be performed quickly, which is crucial for the performance of a secure element. Second, by defining a specific range of bytecodes to be overwritten in a context and storing these mappings in a dense array, the secure element can achieve optimal storage space savings. Thus, dense arrays have advantages in terms of storage space and (above all) runtime over other known solutions.

[0081] Designing the difference table as a dense array thus enables faster access and better memory utilization when executing bytecode in different contexts.

[0082] According to one embodiment, the dense array may comprise elements, each with 1-byte indices pointing to an array storing the data for the user-defined bytecodes, thereby implementing an efficient redirection mechanism. According to this programming technique, the value of a variable is not used for its direct content, but rather as a reference or pointer to another location containing the actual data or value.

[0083] In the context of the difference table, this means that each element of the dense array does not directly contain the user-defined bytecode, but rather a 1-byte index pointing to the location where the actual bytecode is stored. This type of redirection allows the system to efficiently manage and access the data associated with the optimized bytecodes, as the indexes provide a direct and fast path to retrieving the relevant data and minimize the storage space required to store each index. This mechanism contributes to improved performance and memory optimization when operating the Secure Element.

[0084] According to one embodiment, the secure element can be configured to use a prioritized mapping process, in which, for a given context, the respective bytecode mapping difference table is first checked and, if no specific mapping is found, the master mapping table is used. This process begins with the context-specific difference table and accesses the master mapping table if necessary.

[0085] The secure element's operating system has a layered mapping structure with context-specific difference tables and a master mapping table. These mapping tables provide mappings from the optimized bytecode to the standard bytecode.

[0086] For a specific context, the difference table can first be searched. This table contains mappings optimized specifically for that context. If a mapping for the respective bytecode is found in this table, it is used. If no specific mapping for the bytecode is found in the context-specific difference table, the master mapping table is used. This table contains a base set of user-defined bytecode mappings that are valid for different contexts.

[0087] This approach allows the system to use optimized bytecode mappings, which can lead to more efficient operation. At the same time, it ensures that a valid mapping can always be determined, even if no optimized mapping is available in the context-specific mapping table, thus maintaining the functionality and compatibility of the secure element across different contexts.

[0088] This can ensure improved memory savings within one, preferably each, context, since for each context only the difference of the bytecode mappings compared to the master table needs to be stored, instead of storing a complete mapping table for each context.

[0089] According to one embodiment, the secure element can be implemented as a secure element module or as a chip card module or as a smart card or as a secure element module implemented in a housing of a different design than a secure element.

[0090] According to one embodiment, the secure element may comprise an operating system, in particular a chip card operating system or a Java Card operating system or a native operating system.

[0091] According to one embodiment, the programming language may be MULTOS Executable Language (MEL) or .NET Common Intermediate Language (CIL). Short description of the characters

[0092] In the following, the invention is explained in more detail using exemplary embodiments and with reference to the drawing, in which: Fig. 1 the structure of an optimized bytecode (OBC) table of a chip card according to the state of the art; Fig. 2 the structure of the inventive concept; Fig. 3 the representation of the “override” of OBCs at different structural levels; Fig. 4 the structure of an inventive OBC table (Optimized Bytecode Definition); Fig. 5 the block diagram of the method according to the invention. Detailed description of implementation examples

[0093] A well-known approach to bytecode optimization is for the virtual machine (VM) itself to use as little additional memory as possible to execute the additional functions defined for "free" bytecodes. The free bytecodes simply define shortened forms of longer bytecodes. This represents an optimization, which is why such bytecodes are also called "optimized bytecodes" (OBC).

[0094] An example of this is incrementing a counter by 1, which is equivalent to adding 1. This occurs frequently. Therefore, an "optimized bytecode" can be used to save memory (SINC) as follows: - “Increase a value by 1” (1 byte) - Index of the variable to be incremented (1 byte)

[0095] In the VM, the special bytecode (SINC) is recognized and mapped back to the execution of the aforementioned general addition of a value to a variable. Thus, there is no special code in the VM to execute the special bytecode—which would in turn consume memory space—but rather, the special bytecode is "simply" mapped back to a general standard bytecode, which is done using existing resources / code in the VM.

[0096] For the example above, this means that the “optimized bytecode” SINC is reduced to an IINC with the value 1.

[0097] In general, an optimized bytecode can represent a sequence of multiple standard bytecodes instead of a single standard bytecode, as described in the example above. This further increases the potential memory savings.

[0098] In practice, an operating system typically contains 32 kbytes to 100 kbytes of Java bytecode. A Java applet can have between 20 kbytes and 70 kbytes of bytecode (less or more is always possible). The bytecode optimization used today saves about 8% of this memory, which is a very significant contribution to memory savings.

[0099] The above procedure (see Fig. 1) has a disadvantage in that the operating system and applets, which should be completely independent of each other, are not independent. An applet that wants to use optimized bytecode must use the same "free" bytecode that the operating system uses. In practice, this means that the memory savings are often limited, since it has been shown that the operating system and applets would largely (approximately 60%) replace different bytecodes to achieve the best possible optimization.

[0100] The aforementioned disadvantage leads to another disadvantage: If an applet is optimized with regard to bytecode, it may only be installed on an OS that implements exactly the same optimized bytecode. Otherwise, the applet will not work. Therefore, throughout product management and the entire (SAP) background system, it is essential to ensure that the applet that exactly matches the OS used is used when generating variants. Therefore, multiple applet versions must always be maintained and kept available. These only differ in the type of bytecode optimization, but are completely identical in functionality.

[0101] This means increased effort in maintaining and managing the applets, as well as additional tests to ensure the correct interaction between the OS and the applet (although, especially with Java, everything should simply work with everything else).

[0102] If bytecode optimization is particularly effective for an applet (e.g., because it's very large), it may be necessary for business reasons to reverse the entire process: The applet, not the OS, specifies the optimized bytecodes. An OS is created that uses and implements the applet's optimized bytecodes to achieve the maximum possible memory savings (OS + applet) using this method.

[0103] The present invention overcomes the above disadvantages and provides a concept for efficient bytecode optimization, especially within the application of Java to secure elements. The concept is based on the use of "optimized bytecode" located in the range [0xCA..0xFF], preferably [0xCB..0xFD], a range specified as unused in the Java specification.

[0104] Fig. Figure 1 shows a general bytecode architecture for a chip card according to the state of the art with the areas suitable for bytecode optimization.

[0105] Fig. Figure 2 illustrates the inventive concept using an example of a card's bytecode architecture. The basic idea is to make the optimized bytecodes "context-dependent." As shown in Fig. As shown in Figure 2, contexts can be determined by various factors, such as whether a bytecode belongs to the card's operating system or to an applet stored on the card, which Java package a bytecode is located in, or which class a bytecode is located in. Other context information might include the type of a method (constructor, regular method, or class method) or specific method names where certain bytecode instructions are frequently used. Fig. 2 illustrates the use of optimized bytecodes depending on the respective contexts. Fig. The OBC table shown in Figure 2 is created for all Java code in the optimized structure. It is always present.

[0106] The numbered notes in Fig. 2 are to be understood as follows: A2: Java platform classes like java.lang classes are often implemented as native functions, so there isn't much bytecode to optimize. Therefore, an additional OBC table is usually pointless and is omitted. B2: For some specific packages, which, for example, work a lot with calls to security check functions, an optimized OBC may be useful. D2: In many cases, an applet consists of only one package, so specific OBCs are defined for the entire package, i.e. the entire applet. E2: If there is a class that defines many constants, a special OBC table is useful because only a few bytecodes are heavily used that are otherwise rarely used. Q2: No additional OBCs are required for the other classes of the package because the definition at the package level is detailed enough.

[0107] Fig. Figure 3 illustrates the use of mapping tables to implement these context-dependent bytecodes. Each context has an associated table that specifies which optimized bytecodes are mapped to which standard bytecodes or standard bytecode sequences. Each table is context-specific but does not necessarily have to be located in the memory area of ​​the respective context.

[0108] The numbered notes in Fig. 3 are to be understood as follows: A3: In the com.gi_de.globalplatform package, the OBCs 0xE3..0xFA replace the OBCs of the "chip card". In the java.lang package, all OBCs of the "chip card" are available; none are replaced, because the java.lang package does not replace any OBCs. B3: It is very important that all OBCs in a definition are a "block," in this case 0xE3..0xFA. This is necessary for the VM to find the appropriate OBC in minimal time (complexity O(1)) and thus keep execution speed as high as possible. C3: These OBCs (0xD9..0xE0) are available within the CConstants class of the com.gi_de.applets package. Additionally, the OBCs of the com.gi_de.applets package are available within the CConstants class, but only 0xE1..0xF8, since 0xD9..0xE0 have been replaced by those of the CConstants class. The "Card" OBCs 0xCB..0xD8 and 0xF9..0xFD are also available within CConstants.

[0109] The mapping tables include "difference tables." These contain bytecodes that offer only small memory savings and are replaced by those that offer greater savings in the respective context. Fig. Figure 4 shows such a difference table and illustrates the storage efficiency.

[0110] In terms of memory management, it would be impractical to store a complete mapping table for each context. Therefore, the tables are implemented as difference tables, which results in significantly smaller sizes. This table structure allows for a quick check to see if a specific bytecode is contained in the table, as in Fig. 4 shown.

[0111] The numbered notes in Fig. 4 are to be understood as follows: A4: Index of the first bytecode contained in this table. B4: Index of the last bytecode contained in this table. C4: The first index is 8, so 8 is added to the address of the index field to get the first OBC definition (0xD9). D4: The reason for adding the index value to the address of the index field (instead of an absolute value from the beginning of the OBC table) is as follows: a larger area can be addressed with only one byte. E4: These bytes contain the optimized bytecode definition for 0xD9. F4: These bytes contain the optimized bytecode definition for 0xDA. G4: This is where the bytecode definition for 0xDB (and so on) begins. H4: Each byte is an offset to the respective optimized bytecode definition. The offset is added to the address of the index byte. The index of the offset corresponds to the bytecode value. Byte -> Bytecode 0xD9, 2nd Byte -> Bytecode 0xDA ... 8th Byte -> Bytecode 0xE0 This method can achieve O(1) when accessing the variable-length fields in the bytecode definition. I4: The 2nd index is 0x0B, so 11 is added to the address of the index field to get the second OBC definition (0xDA).

[0112] In Fig. Figure 5 illustrates the inventive method for executing bytecode in a runtime environment and / or a smart card applet. The numbered references shown here are to be understood as follows: A5: a free bytecode in a bytecode range that is unused according to the programming language specification is allocated an implementation that depends on a context in which the free bytecode is located, B5: to assign the free bytecode to a user-defined bytecode to save memory space.

[0113] The presented bytecode optimization approach offers several advantages. By using specific contexts and adapting the bytecodes to these contexts, a high degree of memory efficiency is achieved on the secure element, such as a chip card. This is made possible in particular by the use of "optimized bytecodes" and difference tables, which ensure efficient use of available memory.

[0114] Another advantage is the independence of the optimized bytecodes. This means that the bytecodes of the operating system (OS) and applets, or between any two contexts, can be designed individually. This significantly increases flexibility, as all components no longer need to be precisely coordinated. They can be flexibly combined without difficulty, which significantly simplifies the generation of the operating system and all customer variants.

[0115] In addition, the overhead, i.e., the additional memory space required by the optimized bytecodes, is very low. This is illustrated by an example: If only a single optimized bytecode is defined in an OBC table, only about 6-8 additional bytes are required. Therefore, memory savings can be achieved very quickly.

[0116] Finally, the approach offers the possibility of combining multiple bytecodes into a single bytecode. This goes beyond simply regressing an unused bytecode to a standard bytecode. It opens up the potential for even greater memory efficiency and execution speed by combining consecutive bytecodes in the operating system and applets into a single bytecode. This functionality simply requires extending the format of the "OBC definition" in the OBC table.

[0117] These advantages together provide a significant advance in space optimization and flexibility of bytecode management on secure elements. QUOTES CONTAINED IN THE DESCRIPTION

[0000] This list of documents submitted by the applicant was generated automatically and is included solely for the convenience of the reader. This list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions. Cited patent literature

[0000] US 5,905,895 A

[0008]

Claims

[1] Secure element, in particular a chip card, configured to execute bytecode in a runtime environment and / or an applet, wherein the secure element is configured - to allocate a free bytecode in a bytecode area that is unused according to the programming language specification as a user-defined bytecode, - and for providing a mapping table for converting the user-defined bytecode into a standard bytecode sequence comprising at least one standard bytecode, depending on the context of use of the user-defined bytecode. [2] Secure Element according to claim 1, wherein the programming language is Java, in particular wherein the unused bytecode range is a hexadecimal value range between 0xCA and 0xFF, preferably between 0xCB and 0xFD, preferably where the user-defined bytecode is referred to as optimized bytecode due to the memory savings, and / or the secure element is a Java Card, and / or the runtime environment is a Java runtime environment, and / or the programming language specification is a Java specification. [3] Secure Element according to one of claims 1 or 2, wherein the context is determined by the bytecode being located in an operating system of the Secure Element or in an applet loaded on the Secure Element. [4] Secure Element according to one of claims 1 to 3, wherein the context comprises a packet in which the bytecode is located, and / or includes a class to which the bytecode belongs, and / or is determined by the type of a method in which the bytecode is located, preferably where the method is an instance method, a constructor, or a static method. [5] Secure element according to one of claims 1 to 4, arranged to identify by means of the mapping table different contexts, including i) the operating system of the secure element, and / or ii) the applet, and / or iii) the package, and / or iv) the class and / or the type of the method, thereby enabling a specific interpretation and implementation of the bytecode. [6] Secure element according to one of claims 1 to 5, arranged to perform a combined storage of the mapping table on the secure element, regardless of whether the actual storage location is in the memory area of ​​the context, in order to enable faster access to bytecodes. [7] Secure element according to one of claims 1 to 6, arranged to provide a separate allocation table for each applet in the case of a plurality of applets in order to improve memory utilization and to prevent incompatible combinations of operating system and applets. [8] Secure element according to one of claims 1 to 7, wherein the mapping table comprises difference tables to improve memory efficiency, wherein changes in the bytecode assignments relative to a master mapping table are detected, and / or the master mapping table is a basic table containing a set of user-defined bytecode mappings valid for different contexts, and / or a difference table is designed to replace the user-defined bytecode for a subordinate context of the master mapping table with a bytecode that offers greater memory savings in the respective context. [9] Secure element according to one of claims 1 to 8, wherein the difference table is formed as a dense array, wherein the dense array defines a first bytecode value and a last bytecode value which is overwritten with respect to the next higher context, wherein bytecode values ​​in between are also overwritten, [10] The secure element of any one of claims 1 to 9, wherein the dense array comprises elements each having 1-byte indices pointing to a field storing the data for the user-defined bytecodes, thereby implementing an efficient redirection mechanism. [11] Secure element according to one of claims 1 to 10, arranged to use a prioritized allocation process, wherein for a given context the respective difference table for the bytecode allocation is first checked and, if no specific allocation is found, the master allocation table is used, thereby ensuring improved storage space saving within one, preferably each, context. [12] Secure element according to one of claims 1 to 11, comprising a Java Card operating system or a native operating system, preferably wherein the secure element is configured as a secure element module or as a chip card or as a smart card or as a secure element module implemented in a housing other than a secure element, in particular where the programming language is MULTOS Executable Language (MEL) or .NET Common Intermediate Language (CIL). [13] A method for executing bytecode in a runtime environment and / or an applet of a smart card, wherein a free bytecode in a bytecode area unused according to the programming language specification is allocated as a user-defined bytecode, and a mapping table is provided for converting the user-defined bytecode into a standard bytecode sequence comprising at least one standard bytecode, wherein the conversion is carried out depending on the context of use of the user-defined bytecode. [14] A computer program or applet which carries out the method according to the preceding claim when loaded in a secure element according to any one of claims 1 to 12 and / or running on the secure element.

Images