Secure element with heap memory
Patent Information
- Application Number
- EP2023726272
- Authority / Receiving Office
- EP · EP
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2022-05-12
- Filing Date
- 2023-05-09
- Publication Date
- 2025-03-19
AI Technical Summary
Existing secure elements, such as JavaCard-based microprocessors, face inefficiencies in managing transient objects due to the persistence of object headers in non-volatile memory, requiring explicit deletion mechanisms and limited capacity for temporary objects.
Implementing a volatile heap memory within the secure element that stores both object data fields and headers for a limited session duration, allowing for efficient creation and deletion of temporary objects without explicit header deletion, and enabling flexible segment sizes and lifespans.
This solution enhances memory management by allowing targeted creation and deletion of objects with varying lifespans, preventing dangling references and optimizing memory usage, while eliminating the need for explicit header deletion.
Smart Images
Figure 1.1
Abstract
Description
[0001] Secure Element with Heap Memory
[0002] Field of the invention
[0003] The invention relates to secure elements, in particular to a JavaCard-based microprocessor device. JavaCard is a reduced version of the Java programming language that specifically addresses the limitations of secure elements such as smart cards or differently shaped or packaged counterfeit-proof security chips. Examples of secure elements are payment cards and virtualized payment cards hosted in software. Further examples of secure elements are subscriber identity modules (SIMs) of any form factor, in particular SIM cards or UICCs, solderable eUICCs, and iUICCs integrated into a chipset. A JavaCard-based microprocessor device in the form of a chip card is commonly referred to as a JavaCard, as the most original form factor of such a secure element.
[0004] State of the art
[0005] The document [1] JCCRE_3-l_Feb-2O21 - Java Card™ Platform Runtime Environment Specification, Classic Edition, Version 3.1, February 2021 is one of the fundamental specifications for JavaCard technology. The document [1] addresses secure elements, such as smart cards and other tamper-evident security chips (preface).
[0006] Document [1] JCCRE_3-1 discloses that JavaCard objects are generally created on a persistent heap memory, which is retained when the JavaCard is reset (see Chapter 2 - Lifetime of the Java Card Virtual Machine, and Chapter 5 - Memory Model). However, document [1] JCCRE_3-1, Chapter 5, also discloses two types of non-persistent objects, namely transient objects in Chapter 5.1, and temporary objects in Chapter 5.2, in particular array views (Chapter 5.3) as a special case of temporary objects. As explained in Chapter 5.1, only the contents of the data fields of transient objects are transient in nature, in that they are stored in volatile RAM memory, and not in non-volatile EEPROM memory.The contents of the data fields of a transient object are cleared when an event occurs, which is either a RESET (resetting the secure element) or a DESELECT (deselecting a selected applet containing the transient object). Document [1] JCCRE_3-1 lists two types of transient objects, namely CLEAR_ON_RESET transient objects and CLEAR_ON_DESELECT transient objects.
[0007] The headers of transient objects, on the other hand, are stored in the heap memory of the secure element, which is provided in the non-volatile memory NVM (e.g. EEPROM).
[0008] If a transient object is to be completely removed, it is not sufficient to trigger the required event, such as deselecting the applet containing the object or resetting the secure element. The header in the non-volatile heap memory remains even after a deselect or reset and must be actively removed if necessary, for example, using a garbage collection mechanism.
[0009] It would be desirable to have a storage architecture for objects that are only needed temporarily, for example until the next reset of the secure element or until the next deselect of the applet containing the object, that enables efficient management, in particular creation and / or deletion, of the objects.
[0010] The temporary objects described in Chapters 5.2 and 5.3 are short-lived objects that can only be referenced by the current program execution flow and can only be referenced by the execution stack as local variables. This means that only a very limited number of objects can be created as temporary objects, namely (i) some special entry point objects, (ii) global arrays, and (iii) array views.
[0011] Prior art document US7702872B2 discloses a secure element comprising a virtual machine implemented in a non-volatile system memory, a non-volatile application memory and a volatile main memory, and further comprising a variable storage area for global variables provided in a volatile main memory.
[0012] Summary of the invention
[0013] The invention is based on the object of creating a secure element that has a memory architecture that enables efficient management, in particular creation and / or deletion, of objects that are only needed temporarily.
[0014] The object is achieved by a secure element according to claim 1. Advantageous embodiments of the invention are specified in the dependent claims.
[0015] The secure element according to claim 1 comprises: - a virtual machine; - a non-volatile heap memory configured in a non-volatile memory and configured for persistent storage of objects; and - a volatile main memory configured for non-persistent storage of data. The secure element is characterized by: a volatile heap memory configured in the volatile main memory, which contains at least one volatile heap memory segment configured to keep objects stored only for a limited time period of a session of the volatile heap memory segment. The session is limited in time by a start and an end of the session. An object in the volatile heap memory segment has a limited lifespan corresponding to the limited time period of the session.
[0016] Object headers are stored in heap memory and therefore conventionally in non-volatile heap memory. The volatile heap memory implemented in the volatile main memory according to the invention enables the storage of not only object data fields but also object headers in volatile memory. This makes not only the data fields but also the object headers of an object volatile. More precisely, the lifetime of the entire object, including object data fields and object headers, can be defined with a lifetime limited to the duration of a session. Even more precisely, the lifetime of an entire object can be limited according to the session properties of the volatile heap memory segment on which the object header is created. Explicit deletion of object headers of volatile objects created in this way is no longer necessary.
[0017] Therefore, according to claim 1, a secure element is created which has a memory architecture that enables efficient management, in particular creation and / or deletion, of objects that are only needed temporarily.
[0018] An object in the context of the invention preferably comprises an object header and one or more object data fields. The volatile heap memory or the volatile heap memory segment of the volatile heap memory is then configured to store both the object header and the object data fields of an object. As a result, the limited duration of a session of the volatile heap memory segment of the volatile heap memory affects both the object header and the object data fields of an object. As a result, the entire object has a uniform limited lifetime, which is limited to the duration of the session. Optionally, the volatile heap memory is configured, in whole or in part, as:
[0019] - Clear-on-Reset Heap, where the end of the session is effected by resetting the Secure Element; or / and
[0020] - Clear-on-Deselect Heap is configured, whereby the end of the session is effected by deselecting an application from which one or more objects are stored on the volatile heap memory (RAM heap); and / or
[0021] - Clear-on-Session-Deactivation Heap, where the end of the session is effected by a command directed to the secure element to terminate a currently running session.
[0022] The session will commence in one of the following ways:
[0023] - starting the Secure Element; or / and
[0024] - selecting an application of which one or more objects are stored on the volatile heap memory (RAM heap);
[0025] - activation of the or a volatile heap memory segment, in particular activation by an application, or alternatively by the operating system or otherwise.
[0026] Optionally, the beginning and end of a session are triggered by similar events, for example: -Start by starting and ending by resetting (or shutting down) the secure element; -Start by selecting and ending by deselecting an application; -Start by activating and ending by deactivating a volatile heap memory segment.
[0027] Alternatively, the start and end of a session are triggered by different types of events, for example: - Start by selecting an application and end by resetting (or shutting down) the secure element.
[0028] Optionally, the volatile heap memory is segmented into at least two or more volatile heap memory segments, wherein at least some of the volatile heap memory segments have different time-limited durations of a session of the volatile heap memory segment and correspondingly different lifetimes of objects on the respective volatile heap memory segment. This embodiment of the invention enables a targeted creation of complete objects with differently designed lifetimes by creating the objects on volatile heap memory segments with different time durations of the session. For example, a first object is created on a first volatile heap memory segment that is designed as a clear-on-reset heap, so that the first object is only deleted upon a reset of the secure element, in accordance with the invention comprising deleting data fields and headers of the first object.A second object is created on a second volatile heap memory segment, which is configured as a clear-on-deselect heap, so that the second object is deleted upon deselecting the application containing the object, according to the invention including deleting data fields and the header of the second object. However, the second object is also deleted if the secure element is reset without first deselecting the application, either by a targeted reset or by accidentally interrupting and restoring the power supply.
[0029] Optionally, at least some of the volatile heap memory segments, or each volatile heap memory segment, are designed so that references to an object stored in the respective volatile heap memory segment can only be stored in the volatile heap memory segment in which the object itself is stored. This prevents dangling references from remaining after an object has been deleted by session expiration, i.e., after the session of the heap memory segment storing the object has been terminated (expired). If, however, the reference were stored in a different heap memory segment that has a longer session duration than the heap memory segment on which the object referenced by the reference is located, the reference would remain alive longer than the object, thus leaving a dangling reference.
[0030] The secure element can optionally be designed as a JavaCard-based microprocessor device. In this case, the objects are JavaCard objects, and the heap memory is JavaCard heap memory, which, in the case of the volatile heap memory, is stored in volatile main memory.
[0031] The Secure Element can be designed as a payment card, virtual payment card, mobile subscriber identity module (SIM; eUlCC, UICC, SIM card, etc.), ID module (passport, identity card), health card.
[0032] Optionally, each volatile heap memory segment has a segment size, whereby the segment size for at least some or all of the volatile heap memory segments can be changed during the lifetime of the heap memory segment. This embodiment of a volatile heap memory segment allows the segment size to be flexibly adapted to current memory requirements, thus using as little memory space as possible while providing sufficient memory space. Optionally, an object has an object size, whereby the object size includes the data fields and the header. Optionally, the segment size of the volatile heap memory segment is set equal to the object size. If the object size is changed, for example, by adding or removing data fields, the segment size of the volatile heap memory segment is also changed according to the changed object size.
[0033] Optionally, the secure element further comprises an object stored in the volatile heap memory, which object comprises an object header and object data fields stored in the volatile heap memory. Optionally, the secure element further comprises a transient object, which object header is stored in the non-volatile heap memory and one or more data fields are stored in the volatile heap memory, so that, in particular, the transient object serves or can serve as the root object for objects stored in the volatile heap memory.
[0034] In contrast to the objects created according to the invention entirely on the volatile heap memory, where the header of the object is also deleted when the object is deleted and which could therefore be described as volatile objects, in the case of a transient object the header remains stored after the object has been deleted because the header has been stored in the non-volatile conventional heap memory.
[0035] A method according to the invention for memory management in a secure element comprising a virtual machine, a non-volatile memory, and a volatile main memory comprises creating, in a heap memory of the secure element, an object comprising an object header and object data. The method is characterized in that the object is created in a volatile heap memory segment: - which is contained in a volatile heap memory set up in the volatile main memory; and - on which the object is stored only for a maximum of the time-limited duration of a session of the volatile heap memory segment, wherein the session is time-limited by a start and an end of the session, such that the object has a time-limited lifetime on the volatile heap memory segment corresponding to the time-limited duration of the session.
[0036] The method is optionally applied such that at least two or more objects are created on at least two or more volatile heap memory segments of the volatile heap memory, wherein at least some of the volatile heap memory segments have different session durations of the volatile heap memory segment, so that objects with different limited lifetimes are created on the respective volatile heap memory segment. Furthermore, heap memory segments with variable segment sizes can optionally be created, as already described above.
[0037] According to embodiments of the invention, the object is created on a volatile heap memory segment optionally in one of the following ways:
[0038] (a) direct allocation to the volatile heap memory segment - this directly creates a volatile object whose object header and data fields for object data are both located in the non-volatile heap memory;
[0039] (b) Creating the object on a memory other than the volatile heap memory segment, in particular on the non-volatile heap memory, and subsequently copying the object into the volatile heap memory segment - this copies an initially non-volatile or transient object into a volatile one.
[0040] Optionally, the created object is created by a creating object, where the creating object is optionally designed as one of the following:
[0041] (a) as a transient object comprising an object header in non-volatile heap memory and one or more data fields for object data in volatile memory, where the created object is created in one or more of the data fields of the creating object - since the created object is entirely within the scope of the object data of the creating object, the created object is automatically a volatile object in which the object header and the object data are volatile;
[0042] (b) as a volatile object, which includes an object header and one or more data fields in volatile memory, where the created object is created in one or more of the data fields of the creating object. An object created by a volatile object is automatically a volatile object again. By creating a created object by a transient or volatile object, the created object can implicitly be given the class "volatile" as a parameter, which is not explicitly possible in JavaCard, since JavaCard does not allow class types to be passed as parameters.
[0043] Short description of the drawings
[0044] In the following, the invention is explained in more detail using exemplary embodiments and with reference to the drawing, in which:
[0045] Fig. 1 is a schematic representation of a heap memory arrangement of a secure element, according to an embodiment of the invention.
[0046] Detailed description of implementation examples
[0047] Fig. 1 shows a schematic representation of a heap memory arrangement of a secure element, according to one embodiment of the invention. The following pattern coding is used in Fig. 1. Free memory areas are shown in white. Memory areas occupied by object data are shown in dotted lines. Memory areas occupied by object headers are shown in striped lines. The heap memory arrangement of the secure element comprises a non-volatile heap memory, NVM heap, which can optionally be designed like a non-volatile heap memory known from the prior art, and a volatile main memory RAM. The non-volatile heap memory, NVM heap, is configured to store persistent objects P, in which both the object header H and the object data D are stored in object data fields in the non-volatile heap memory, NVM heap.An oval P schematically indicates a persistent object P in the non-volatile heap memory (NVM heap). The non-volatile heap memory (NVM heap) can also, in conjunction with the main memory (RAM), store transient data. The object header is stored in the non-volatile heap memory (NVM heap), and the object data is stored in the object data fields in the volatile main memory (RAM). Two ovals T schematically indicate two transient objects T. The object header is stored in the non-volatile heap memory (NVM heap), and the object data or object data fields are stored in a largely arbitrary available area of the volatile main memory (RAM).
[0048] According to the invention, the secure element further comprises a volatile heap memory (RAM heap) configured in the volatile main memory (RAM), which is configured to store entire objects, and not just parts of objects, such as only the object data fields with the object data or only the object headers. The volatile heap memory (RAM heap) shown in Fig. 1 is segmented into several heap memory segments S1, S2, S3, ... Sn. In connection with the invention, the term "volatile object" is introduced here, which refers to an object in which both the object data and the object header are stored in the volatile heap memory (RAM heap) according to the invention.
[0049] An oval V indicates a volatile object whose object data fields with the object data, as well as the object headers, are both stored in the volatile heap memory, RAM heap, more precisely in a heap memory segment Sl.
[0050] To clarify that the object data of transient objects need not be stored in the RAM heap according to the invention, a small section of the volatile RAM is schematically shown to illustrate one transient object T, with a free area (white) and an area occupied by object data (dotted). A second transient object has an object header in the non-volatile heap memory, NVM heap, and object data (object data fields) in a heap memory segment S3 of the volatile heap memory, RAM heap.
[0051] Cited prior art
[0052] [1] [JCCRE_3-1] JCCRE_3-l_Feb-2021 - Java Card™ Platform Runtime Environment Specification, Classic Edition, Version 3.1, February 2021
Claims
Patent claims 1. Secure Element comprehensive: - a virtual machine; - a non-volatile heap (NVM heap) set up in a non-volatile memory (NVM) and configured for the persistent storage of objects; and - a volatile working memory (RAM) configured for non-persistent storage of data; characterized by: a volatile heap memory (RAM heap) configured in the volatile working memory (RAM) which contains at least one volatile heap memory segment (SI, S2, S3, ... Sn) configured to keep objects stored only for a limited duration of a session of the volatile heap memory segment (SI, S2, S3, ... Sn), wherein the session is limited by a beginning and an end of the session, such that an object on the volatile heap memory segment (SI, S2, S3, ... Sn) has a lifetime limited by the limited duration of the session.
2. Secure Element according to claim 1, wherein an object comprises an object header and one or more object data fields, and wherein the volatile heap memory (RAM heap) is configured to store both the object header and the object data fields of an object.
3. Secure Element according to claim 1 or 2, wherein the volatile heap memory (RAM heap) is wholly or partially configured as: - Clear-on-Reset Heap, where the session ends by resetting the Secure Element; and / or - Clear-on-Deselect Heap is configured, whereby the end of the session is achieved by deselecting an application from which one or more objects are stored on the volatile heap memory (RAM heap); and / or - Clear-on-Session-Deactivation Heap, where the end of the session is achieved by a command directed to the Secure Element to terminate a currently running session.
4. Secure Element according to any of the preceding claims, wherein the start of the session is effected by any of the following: - starting the Secure Element; and / or - a selection of an application from which one or more objects are stored on the volatile heap memory (RAM heap); - activating one or more volatile heap memory segments (SI, S2, S3, ... Sn), - Activation of one or more volatile heap memory segments (SI, S2, S3, ... Sn) by an application, by the operating system, or by another instance in or under the control of the Secure Element.
5. Secure Element according to any of the preceding claims, wherein the volatile heap memory (RAM heap) is segmented into at least two, or more, volatile heap memory segments (SI, S2, S3, ... Sn), wherein at least some of the volatile heap memory segments (SI, S2, S3, ... Sn) have different time-limited durations of a session of the volatile heap memory segment (SI, S2, S3, ... Sn) and corresponding different lifetimes of objects on the respective volatile heap memory segment (SI, S2, S3, ... Sn).
6. Secure Element according to one of the preceding claims, at least some of the volatile heap memory segments (SI, S2, S3, ... Sn), or each volatile heap memory segment, is designed such that references to an object stored in the respective volatile heap memory segment (SI, S2, S3, ... Sn) can only be stored in that volatile heap memory segment (SI, S2, S3, ... Sn) in which the object itself is stored.
7. Secure Element according to any of the preceding claims, designed as a JavaCard-based microprocessor device.
8. Secure Element according to any of the preceding claims, designed as a payment card or virtual payment card, or as a subscriber identity module or as an identification module or as a health card.
9. Secure Element according to any of the preceding claims, wherein each volatile heap memory segment (SI, S2, S3, ... Sn) has a segment size, and wherein for at least some or all of the volatile heap memory segments (SI, S2, S3, ... Sn) the segment size can be changed during the lifetime of the heap memory segment (SI, S2, S3, ... Sn).
10. Secure Element according to any of the preceding claims, further comprising an object stored on the volatile heap memory (RAM heap) which includes an object header and object data fields that are stored in the volatile heap memory (RAM heap).
11. Secure Element according to claim 10, further comprising a transient object comprising an object header stored in non-volatile heap memory (NVM heap) and comprising one or more data fields stored in volatile heap memory (RAM heap), such that in particular the transient object serves as a root object for objects stored in volatile heap memory (RAM heap).
12. A method for memory management in a Secure Element comprising a Virtual Machine, Non-Volatile Memory (NVM) and Volatile Memory (RAM), the method comprising: creating, on a heap memory of the Secure Element, an object, referred to as the created object, comprising an object header and object data, characterized by the fact that the object is stored on a volatile heap memory segment (SI, S2, S3, ... Sn), - which is contained in a volatile heap memory (RAM heap) set up in volatile working memory (RAM), and - on which the object is stored only for a maximum of the limited duration of a session of the volatile heap memory segment (SI, S2, S3, ... Sn), the session being limited by a beginning and an end of the session, so that the object on the volatile heap memory segment (SI, S2, S3, ... Sn) has a lifetime limited by the limited duration of the session.
13. The method of claim 12, wherein at least two, or more, objects are placed on at least two or more volatile heap memory segments (SI, S2, S3, ... Sn) of the volatile heap memory (RAM heap), wherein at least some of the volatile heap memory segments (SI, S2, S3, ... Sn) have different session durations of the volatile heap memory segment (SI, S2, S3, ... Sn), so that objects with differently limited lifetimes are placed on the respective volatile heap memory segment (SI, S2, S3, ... Sn).
14. Method according to claim 12 or 13, wherein the placement of the object on a volatile heap memory segment (SI, S2, S3, ... Sn) is optionally carried out in one of the following ways: (a) direct allocation to the volatile heap memory segment (SI, S2, S3, ... Sn); (b) Storing the object in a memory location other than the volatile heap memory segment (SI, S2, S3, ... Sn), in particular the non-volatile heap memory, and subsequently copying the object into the volatile heap memory segment (SI, S2, S3, ... Sn).
15. Method according to any one of claims 12 to 14, wherein the created object is created by a generating object, wherein the generating object is optionally designed as one of the following: (a) as a transient object comprising an object header in non-volatile heap memory and one or more data fields for object data in volatile memory, wherein the created object is created in one or more of the data fields of the creating object; (b) as a volatile object comprising an object header and one or more data fields in volatile memory, wherein the created object is created in one or more of the data fields of the creating object.