Security element with stack memory
By setting a volatile heap memory segment in the volatile working memory of the JavaCard microprocessor device, the time-limited storage and automatic clearing of objects are achieved, and the problem of inconvenience in object management in the prior art is solved and the object is improved creation and deletion efficiency and avoid dangling references.
Patent Information
- Application Number
- CN202380038711.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2022-05-12
- Filing Date
- 2023-05-09
- Publication Date
- 2024-12-20
AI Technical Summary
The prior art is difficult to effectively manage objects that are only temporarily needed, especially in JavaCard microprocessor devices, which leads to inconvenience in storing and deleting objects and has problems with dangling references.
By setting the volatile heap memory segment in the volatile working memory, limiting the storage time of the object, the data fields and headers of the object are stored in the volatile memory, and the object is automatically cleared by using the start and end events of the session to avoid Explicitly delete the header to achieve a time-limited service life of the object.
It realizes rapid creation and deletion of objects, avoids dangling references, improves the efficiency of object management and storage space utilization, and adapts to the needs of different session durations.
Smart Images
Figure CN119173851A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to a security element, in particular a JavaCard-based microprocessor device. JavaCard forms a simplified version of the programming language Java, which specifically takes into account the limitations of security elements such as smart cards or differently shaped or packaged anti-counterfeiting security chips. Examples of security elements are payment transaction cards and virtualized payment transaction cards stored in software. Other examples of security elements are subscriber identity modules (SIM) of any form factor, in particular SIM cards or UICCs, solderable eUICCs, iUICCs integrated into chipsets. JavaCard-based microprocessor devices in the form of chip cards are widely referred to as JavaCards as the original form factor of such security elements. Background Art
[0002] Document [1] JCCRE_3-1_Feb-2021-Java Card TM Platform Runtime EnvironmentSpecification(Java Card TM Platform Runtime Environment Specification, Classic Edition, Version 3.1, February 2021) is one of the basic specifications of JavaCard technology. The document [1] relates to secure elements, such as smart cards and other anti-counterfeit security chips (preface).
[0003] Document [1] JCCRE_3-1 discloses that JavaCard objects are usually created on persistent heap memory, which is preserved when the JavaCard is reset (see Chapter 2 "Lifetime of the Java Card Virtual Machine" and Chapter 5 "Memory Model"). However, Chapter 5 of document [1] JCCRE_3-1 also discloses two types of non-persistent objects, namely transient objects in Chapter 5.1 and temporary objects in Chapter 5.2, especially array views (Chapter 5.3) as a special case of temporary objects.
[0004] As described in Chapter 5.1, only the content of the data field of a transient object has a transient nature in that it is stored in the volatile RAM memory instead of in the non-volatile EERPOM memory. The content of the data field of a transient object is deleted when an event occurs, which is a reset (RESET), i.e., resetting the security element, or a deselection (DESELECT), i.e., deselecting the selected application (Applet) containing the transient object. Document [1] JCCRE_3-1 mentions two types of transient objects, namely CLEAR_ON_RESET transient objects and CLEAR_ON_DESELECT transient objects.
[0005] Instead, the headers of transient objects are stored on a heap memory of the secure element, which is provided in a non-volatile memory NVM, such as an EEPROM.
[0006] If a transient object is to be completely removed, it is not sufficient to trigger the required event, such as deselecting the application containing the object or resetting the secure element. Even after deselection or resetting, the header remains in the non-volatile heap memory and must be actively deleted, for example by means of a garbage collection mechanism, if necessary.
[0007] For objects that are only needed temporarily, for example until the next reset of the secure element or until the next deselection of the application containing the object, a memory architecture is desired that enables efficient management, in particular creation and / or deletion of the objects.
[0008] According to chapters 5.2 and 5.3, temporary objects 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. It can be seen 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.
[0009] Prior art document US Pat. No. 7,702,872 B2 discloses a secure element comprising a virtual machine implemented in a nonvolatile system memory, as well as a nonvolatile application memory and a volatile working memory, and a variable memory area for global variables provided in the volatile working memory. Summary of the invention
[0010] The object of the present invention is to provide a secure element having a memory structure which enables efficient management, in particular creation and / or deletion, of objects which are only temporarily required.
[0011] This object is achieved by a security element according to claim 1. Advantageous embodiments of the invention are specified in the dependent claims.
[0012] The security element according to claim 1 comprises: a virtual machine; a non-volatile heap memory arranged in a non-volatile memory for persistent storage of objects; and a volatile working memory arranged for non-persistent storage of data. The security element is characterized in that: the volatile heap memory arranged in the volatile working memory contains at least one volatile heap memory segment, which is arranged to keep the objects stored only for a maximum of the time-limited duration of a session of the volatile heap memory segment. In this case, the session is time-limited to the start and end of the session. The objects on the volatile heap memory segment have a time-limited service life corresponding to the time-limited duration of the session.
[0013] The object header is stored in the heap memory, and therefore traditionally in the non-volatile heap memory. The volatile heap memory provided in the volatile working memory according to the invention not only enables the storage of the data fields of the object in the volatile memory, but also enables the storage of the object header of the object in the volatile memory. As a result, both the data fields and the object header of the object are created quickly. More precisely, the service life of the entire object (including the object data fields and the object header) can be created with a service life that is time-limited to the duration of the session. More precisely, the service life of the entire object can be limited corresponding to the session attributes of the volatile heap memory segment on which the object header is created. It is no longer necessary to explicitly delete the object header of the volatile object created in this way.
[0014] According to claim 1 , a security element is thus provided which has a memory architecture which enables efficient management, in particular creation and / or deletion, of objects which are only temporarily required.
[0015] The object associated with the present invention preferably includes an object header and one or more object data fields. Then, the volatile heap memory or a volatile heap memory segment of the volatile heap memory is arranged to keep the object header and object data fields of the object stored. Thus, the limited duration of the session of the volatile heap memory segment of the volatile heap memory affects the object header and object data fields of the object. Thus, the entire object has a unified, limited service life, which is limited in time to the duration of the session.
[0016] Optionally, the volatile heap memory can be set up in whole or in part as:
[0017] - a clear-on-reset stack, wherein the end of the session is achieved by resetting the secure element; or / and
[0018] - Clear-on-Deselected heap, wherein the end of the session is achieved by deselecting an application, by which one or more objects are stored in a volatile heap memory (RAM-Heap); or / and
[0019] - A stack that is cleared on session deactivation (Clear-on-Session-Deactivation), wherein the end of the session is achieved by a command directed to the secure element, which is used to end the currently running session.
[0020] The start of a session can optionally be achieved in one of the following ways:
[0021] -activate the secure element; or / and
[0022] - Select an application, one or more objects of which are stored in the volatile heap memory (RAM-Heap);
[0023] - Activating the volatile heap memory segment or the volatile heap memory segment, in particular by an application program, or alternatively by an operating system or in some other way.
[0024] Optionally, the start and end of a session are achieved through the same type of events, for example: starting by starting the security element and ending by resetting (or shutting down) the security element; starting by selecting an application and ending by deselecting an application; starting by activating a volatile heap memory segment and ending by deactivating a volatile heap memory segment.
[0025] Alternatively, the start and end of a session are implemented through different types of events, for example: starting by selecting an application and ending by resetting (or shutting down) the secure element.
[0026] 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 sessions of the volatile heap memory segments and corresponding different service lives of objects on the corresponding volatile heap memory segments. This embodiment of the present invention enables targeted creation of complete objects with differently designed service lives by creating objects on volatile heap memory segments with different session durations. For example, a first object is created on a first volatile heap memory segment, which is designed as a heap that is cleared when reset, so that the first object is deleted only when the security element is reset (Reset), according to the present invention, including: deleting the data field and header of the first object. A second object is created on a second volatile heap memory segment, which is designed as a heap that is cleared when deselected, so that the second object is deleted when the application containing the object is deselected (Deselect), according to the present invention, including: deleting the data field and header of the second object. However, if the secure element is reset (optionally by a targeted reset or by unexpectedly interrupting and restoring power) without first deselecting the application, the second object will also be deleted.
[0027] Optionally, at least some of the volatile heap memory segments or each volatile heap memory segment is designed so that a reference to an object stored in the corresponding volatile heap memory segment can only be stored in that volatile heap memory segment in which the object itself is stored. This prevents dangling references from remaining after the object has been deleted according to the invention by expiration of a session, i.e. after the session of the heap memory segment storing the object has ended (expired). If, on the other hand, the reference is stored on another heap memory segment whose session duration is longer than the heap memory segment in which the object referenced by the reference is located, the reference will remain active longer than the object, so that dangling references will remain.
[0028] Optionally, the security element is designed as a JavaCard-based microprocessor device. In this case, the object is a JavaCard object, and the heap memory is a JavaCard heap memory, but in the case of a volatile heap memory, the JavaCard heap memory is stored in a volatile working memory.
[0029] The security element can be optionally designed as: payment transaction card, virtual payment transaction card, mobile phone user identity module (SIM; such as eUICC, UICC, SIM card, etc.), certificate module (passport, ID card), health card.
[0030] Optionally, each volatile heap memory segment has a segment size, wherein, for at least some or all of the volatile heap memory segments, the segment size can change during the service life of the heap memory segment. This embodiment of the volatile heap memory segment allows the segment size to be flexibly adapted to the current memory requirements, thereby consuming as little memory space as possible on the one hand and providing sufficient memory space on the other hand. The object optionally has an object size, wherein the object size includes a data field and a header. Optionally, the segment size of the volatile heap memory segment is created to be equal to the object size. If the object size changes, for example by adding or removing data fields, the segment size of the volatile heap memory segment also changes according to the changed object size.
[0031] Optionally, the secure element further comprises an object stored in the volatile heap memory, the object comprising an object header and an object data field stored in the volatile heap memory.
[0032] Optionally, the security element also includes a transient object, which includes an object header stored in the non-volatile heap memory and includes one or more data fields stored in the volatile heap memory, so that in particular the transient object serves as or can be used as a root object for objects stored in the volatile heap memory.
[0033] Unlike objects created entirely on volatile heap memory according to the present invention (wherein the header of the object is also deleted when the object is deleted, and can therefore be called a volatil object), in a transient object, the header remains stored after the object is deleted because the header has been stored in non-volatile traditional heap memory.
[0034] The method for memory management in a security element according to the present invention includes creating an object on a heap memory of a security element, the object including an object header and object data, the security element including a virtual machine, a non-volatile memory and a volatile working memory. The method is characterized in that the object is created on a volatile heap memory segment: the volatile heap memory segment is contained in a volatile heap memory, the volatile heap memory is arranged in a volatile working memory; and in the volatile heap memory segment, the object is only stored at most during the time-limited duration of a session of the volatile heap memory segment, wherein the session is time-limited to the start and end of the session, so that the object on the volatile heap memory segment has a time-limited service life corresponding to the time-limited duration of the session.
[0035] Optionally, the method is applied such that at least two or more objects are created on at least two or more volatile heap memory segments of a volatile heap memory, wherein at least some of the volatile heap memory segments have different session durations of the volatile heap memory segments, such that objects with different limited lifetimes are correspondingly created on the respective volatile heap memory segments. Furthermore, heap memory segments with variable segment sizes may be selectively created, as described above.
[0036] According to an embodiment of the present invention, an object is optionally created on a volatile heap memory segment in one of the following ways:
[0037] (a) directly created on a volatile heap memory segment, thereby directly generating a volatile object whose object header and data fields for the object data are also located in non-volatile heap memory;
[0038] (b) Creating an object in a memory outside of a volatile heap memory segment, in particular a non-volatile heap memory, and subsequently copying the object into a volatile heap memory segment, thereby copying the originally non-volatile or transient object in a converted manner into a volatile object.
[0039] Optionally, the created object is created by a generating object, wherein the generating object is optionally designed as one of the following:
[0040] (a) a transient object, the transient object comprising an object header in non-volatile heap memory and one or more data fields of object data in volatile memory, wherein the created object is created in the one or more data fields of the object being created, because the created object is entirely located in the area of the object data of the object being created, the created object is automatically a volatile object, wherein both the object header and the object data are volatile;
[0041] (b) A mutable object, which includes an object header and one or more data fields in a volatile memory, wherein the created object is created in the one or more data fields of the object being generated, and the object created by the mutable object is automatically a mutable object.
[0042] By creating an object created by transient or volatile object, the created object can be implicitly given the category "volatile" as a parameter, which is not possible in an explicit way in JavaCard, because JavaCard does not provide for passing category types as parameters. BRIEF DESCRIPTION OF THE DRAWINGS
[0043] The invention is explained in more detail below using examples and with reference to the accompanying drawings, in which:
[0044] Figure 1 A schematic diagram showing a stack memory arrangement of a secure element according to an embodiment of the present invention is shown. DETAILED DESCRIPTION
[0045] Figure 1 A schematic diagram of a stack memory arrangement of a security element according to an embodiment of the present invention is shown. Figure 1 The following pattern encoding is used. Free memory areas are shown in white. Memory areas occupied by object data are shown in dots. Memory areas occupied by object headers are shown in stripes. The heap memory arrangement of the security element includes a non-volatile heap memory NVM-Heap (which can optionally be designed as a non-volatile heap memory as known in the prior art) and a volatile working memory RAM. The non-volatile heap memory NVM-Heap is designed to store persistent objects P, wherein the object header H and the object data D in the object data field are stored in the non-volatile heap memory NVM-Heap. The persistent object P in the non-volatile heap memory NVM-Heap is schematically represented by an oval P. The non-volatile heap memory NVM-Heap can also store transient data in conjunction with the working memory RAM, wherein the object header is stored in the non-volatile heap memory NVM-Heap, and the object data in the object data field is stored in the volatile working memory RAM. Two transient objects T are schematically represented by two ovals T, wherein 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 widely arbitrarily available area of the volatile working memory RAM.
[0046] According to the invention, the security element also has a volatile heap memory RAM-Heap arranged in the volatile working memory RAM, which is arranged to keep the entire object stored instead of only storing part of the object, such as only storing the object data field with the object data or only storing the object header. Figure 1 The volatile heap memory RAM-Heap shown is segmented into a plurality of heap memory segments S1, S2, S3, ... Sn. In connection with the present invention, the term "volatile object" is introduced here to denote an object whose object data and object header are stored in the volatile heap memory RAM-Heap according to the present invention. A volatile object is represented by an oval V, whose object data fields with object data and object header are stored in the volatile heap memory RAM-Heap, more precisely in the heap memory segment S1.
[0047] In order to make it clear that the object data of a transient object does not necessarily have to be stored in the RAM-Heap according to the invention, a small section of the volatile working memory RAM is schematically shown to illustrate a transient object T, which small section has a free area (white) and an area occupied by the object data (dotted). The second transient object has an object header in the non-volatile heap memory NVM-Heap and object data (object data field) in the heap memory segment S3 of the volatile heap memory RAM-Heap.
[0048] Prior Art Cited
[0049] [1][JCCRE_3-1]JCCRE_3-1_Feb-2021-Java Card TM Platform RuntimeEnvironment Specification(Java Card TM Platform Runtime Environment Specification, Classic, Version 3.1, February 2021).
Claims
1. A security element, comprising: - Virtual machines; a non-volatile heap memory (NVM-Heap) arranged in a non-volatile memory (NVM), the non-volatile heap memory being arranged for persistent storage of objects; and - a volatile working memory (RAM) which is provided for non-persistent storage of data; characterized in that: A volatile heap memory (RAM-Heap) is arranged in the volatile working memory (RAM), the volatile heap memory comprising at least one volatile heap memory segment (S1, S2, S3, ..., Sn), the volatile heap memory segment being arranged to keep objects stored only during a time-limited duration of a session of the volatile heap memory segment (S1, S2, S3, ..., Sn), wherein the session is time-limited to a start and an end of the session, so that the objects on the volatile heap memory segment (S1, S2, S3, ..., Sn) have a time-limited service life corresponding to the time-limited duration of the session.
2. The security element according to claim 1, wherein: The object comprises an object header and one or more object data fields, and wherein the volatile heap memory (RAM-Heap) is arranged to keep the object header and the object data fields of the object stored.
3. The security element according to claim 1 or 2, wherein: The volatile heap memory (RAM-Heap) is configured in whole or in part as follows: - a stack that is cleared on reset, wherein the end of the session is achieved by resetting the security element; or / and - a heap that is cleared on deselection, wherein the end of the session is achieved by deselecting an application, one or more objects being stored by the application on the volatile heap memory (RAM-Heap); or / and - A stack that is cleared when a session is deactivated, wherein the end of the session is achieved by a command directed to the secure element, the command being used to end the currently running session.
4. The security element according to any one of the preceding claims, wherein: The session is started by one of the following methods: - activating the security element; or / and - Select an application, one or more objects being stored by the application in a volatile heap memory (RAM-Heap); - activating the volatile heap memory segment or the volatile heap memory segments (S1, S2, S3, ..., Sn), - Activating the volatile heap memory segment or the volatile heap memory segment (S1, S2, S3, ..., Sn) by an application, by an operating system or by another entity that is in or controlled by the secure element.
5. The security element according to any one of the preceding claims, wherein: The volatile heap memory (RAM-Heap) is segmented into at least two or more volatile heap memory segments (S1, S2, S3, ..., Sn), wherein at least some of the volatile heap memory segments (S1, S2, S3, ..., Sn) have different temporally limited durations of sessions of the volatile heap memory segments (S1, S2, S3, ..., Sn) and corresponding different service lives of objects on the corresponding volatile heap memory segments (S1, S2, S3, ..., Sn).
6. According to the security element described in any of the above claims, at least some of the volatile heap memory segments (S1, S2, S3, ..., Sn) or each volatile heap memory segment is designed so that a reference to an object stored in the corresponding volatile heap memory segment (S1, S2, S3, ..., Sn) can only be stored in the volatile heap memory segment (S1, S2, S3, ..., Sn) in which the object itself is stored. 7 . The security element according to claim 1 , which is designed as a JavaCard-based microprocessor device.
8. The security element according to any one of the preceding claims, wherein the security element is designed as a payment transaction card or a virtual payment transaction card, or is designed as a user identity module or a certificate module or a health card.
9. The security element according to any one of the preceding claims, wherein: Each volatile heap memory segment (S1, S2, S3, ..., Sn) has a segment size, and wherein, for at least some or all of the volatile heap memory segments (S1, S2, S3, ..., Sn), the segment size is capable of changing during the service life of the heap memory segments (S1, S2, S3, ..., Sn).
10. The security element according to any one of the preceding claims, further comprising an object stored in the volatile heap memory (RAM-Heap), the object comprising an object header and an object data field stored in the volatile heap memory (RAM-Heap).
11. A security element according to claim 10, further comprising a transient object, the transient object comprising an object header stored in a non-volatile heap memory (NVM-Heap) and comprising one or more data fields stored in the volatile heap memory (RAM-Heap), so that in particular the transient object serves as a root object for objects stored in the volatile heap memory (RAM-Heap).
12. A method for memory management in a secure element, the secure element comprising a virtual machine, a non-volatile memory (NVM) and a volatile working memory (RAM), the method comprising: An object is created on the heap memory of the security element, referred to as a created object, the created object comprising an object header and object data, characterized in that: creating said object on a volatile heap memory segment (S1, S2, S3, ..., Sn), - the volatile heap memory segment is contained in a volatile heap memory (RAM-Heap), the volatile heap memory being arranged in the volatile working memory (RAM); and, -In the volatile heap memory segment, the object remains stored only for at most during a time-limited duration of a session of the volatile heap memory segment (S1, S2, S3, ..., Sn), wherein the session is time-limited to a start and an end of the session, so that the objects on the volatile heap memory segment (S1, S2, S3, ..., Sn) have a time-limited service life corresponding to the time-limited duration of the session.
13. The method according to claim 12, wherein: At least two or more objects are created on at least two or more volatile heap memory segments (S1, S2, S3, ..., Sn) of the volatile heap memory (RAM-Heap), wherein at least some of the volatile heap memory segments (S1, S2, S3, ..., Sn) have different session durations of the volatile heap memory segments (S1, S2, S3, ..., Sn), so that objects with different limited service lives are correspondingly created on the corresponding volatile heap memory segments (S1, S2, S3, ..., Sn).
14. The method according to claim 12 or 13, wherein: The object is optionally created on a volatile heap memory segment (S1, S2, S3, ..., Sn) in one of the following ways: (a) directly created on the volatile heap memory segment (S1, S2, S3, ..., Sn); (b) creating the object in a memory outside the volatile heap memory segment (S1, S2, S3, ..., Sn), in particular a non-volatile heap memory, and then copying the object to the volatile heap memory segment (S1, S2, S3, ..., Sn).
15. The method according to any one of claims 12 to 14, wherein: The created object is created by a generated object, wherein the generated object is optionally designed as one of the following: (a) a transient object comprising an object header in the non-volatile heap memory and one or more data fields of object data in the volatile memory, wherein the created object is created in the one or more data fields of the generated object; (b) a volatile object comprising an object header and one or more data fields in the volatile memory, wherein the created object is created in the one or more data fields of the generated object.