EP4523084A1 - Secure element mit heap-speicher - Google Patents

Secure element mit heap-speicher

Info

Publication number
EP4523084A1
EP4523084A1 EP23726272.0A EP23726272A EP4523084A1 EP 4523084 A1 EP4523084 A1 EP 4523084A1 EP 23726272 A EP23726272 A EP 23726272A EP 4523084 A1 EP4523084 A1 EP 4523084A1
Authority
EP
European Patent Office
Prior art keywords
volatile
heap
heap memory
memory
session
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP23726272.0A
Other languages
English (en)
French (fr)
Inventor
Thomas Stocker
Ingeborg FLADÉE
Jörn TREGER
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Giesecke and Devrient ePayments GmbH
Original Assignee
Giesecke and Devrient ePayments GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Giesecke and Devrient ePayments GmbH filed Critical Giesecke and Devrient ePayments GmbH
Publication of EP4523084A1 publication Critical patent/EP4523084A1/de
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
    • G06F9/4488—Object-oriented
    • G06F9/4493—Object persistence
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
    • G06K19/00—Record carriers for use with machines and with at least a part designed to carry digital markings
    • G06K19/06—Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the kind of the digital marking, e.g. shape, nature, code
    • G06K19/067—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components
    • G06K19/07—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components with integrated circuit chips
    • G06K19/073—Special arrangements for circuits, e.g. for protecting identification code in memory
    • G06K19/07309—Means for preventing undesired reading or writing from or onto record carriers
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
    • G06F12/023—Free address space management
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0875—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches with dedicated cache, e.g. instruction or stack
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/14—Protection against unauthorised use of memory or access to memory
    • G06F12/1416—Protection against unauthorised use of memory or access to memory by checking the object accessibility, e.g. type of access defined by the memory independently of subject rights
    • G06F12/1425—Protection against unauthorised use of memory or access to memory by checking the object accessibility, e.g. type of access defined by the memory independently of subject rights the protection being physical, e.g. cell, word, block
    • G06F12/1441—Protection against unauthorised use of memory or access to memory by checking the object accessibility, e.g. type of access defined by the memory independently of subject rights the protection being physical, e.g. cell, word, block for a range
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/10—Providing a specific technical effect
    • G06F2212/1052—Security improvement
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/10—Providing a specific technical effect
    • G06F2212/1056—Simplification
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/15—Use in a specific computing environment
    • G06F2212/151—Emulated environment, e.g. virtual machine
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/20—Employing a main memory using a specific memory technology
    • G06F2212/205—Hybrid memory, e.g. using both volatile and non-volatile memory

Definitions

  • the invention relates to secure elements, in particular a JavaCard-based microprocessor device.
  • JavaCard is a reduced version of the Java programming language that specifically takes into account the limitations of secure elements such as smart cards or differently shaped or packaged tamper-proof security chips.
  • Examples of secure elements are payment cards and virtualized payment cards stored in software.
  • Further examples of secure elements are subscriber identity modules or subscriber identity modules - SIMs - of any form factor, in particular SIM cards or UICCs, solderable eUlCCs, 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 original form factor of such a secure element.
  • JCCRE_3-l_Feb-2O21 - Java CardTM Platform Runtime Environment Specification, Classic Edition, Version 3.1, February 2021 is one of the basic specifications for JavaCard technology.
  • the document [1] addresses secure elements, such as smart cards and other forgery-proof security chips (preface “Preface”).
  • JCCRE_3-1 discloses that JavaCard objects are generally created on a persistent heap memory that is retained when the JavaCard is reset (see Chapter 2 - Lifetime of the Java Card Virtual Machine, and Chapter
  • 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. temporary objects"), in particular Array Views (Chapter 5.3) as a special case of temporary objects.
  • transient objects in Chapter 5.1
  • temporary objects temporary objects
  • Array Views Chapter 5.3
  • JCCRE_3-1 mentions two types of transient objects, namely CLEAR_ON_RESET transient objects and CLEAR_ON_DESELECT transient objects.
  • the headers of transient objects are stored on the heap memory of the Secure Element, which is provided in the non-volatile memory NVM (e.g. EEPROM).
  • NVM non-volatile memory
  • 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 eliminated if necessary, for example using a garbage collection mechanism.
  • the temporary objects according to Chapter 5.2, 5.3 are short-lived objects that can only be referenced by the current program execution flow, and can only be referenced as local variables by the execution stack. It follows 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.
  • US7702872B2 discloses a secure element comprising a virtual machine implemented in a non-volatile system memory, as well as a non-volatile application memory and a volatile memory, and further a variable storage area for global variables provided in a volatile memory.
  • the invention is based on the object of creating a secure element that has a storage architecture that enables efficient management, in particular creation and/or deletion, of objects that are only needed temporarily.
  • the secure element according to claim 1 comprises: - a virtual machine; - a non-volatile heap memory set up in a non-volatile memory and designed to persistently store objects; and - volatile memory designed to store data non-persistently.
  • the secure element is characterized by: a volatile heap memory set up in volatile memory, which contains at least one volatile heap memory segment that is designed to only store objects for a maximum of a time-limited duration of a session of the volatile heap memory segment to keep stored.
  • the session is limited in time by a start and an end of the session. Has an object on the volatile heap memory segment a limited lifespan corresponding to the time-limited duration of the session.
  • Object headers are stored in heap memory and therefore traditionally in non-volatile heap memory.
  • the volatile heap memory set up in the volatile main memory according to the invention enables not only data fields of objects, but also object headers of objects, to be stored in the volatile memory. This means that not only the data fields but also the object headers of an object are created fleetingly. More precisely, the lifespan of the entire object, including object data fields and object headers, can be set with a lifespan limited to the duration of a session. The lifetime of an entire object can be limited even more precisely according to the session properties of the volatile heap memory segment on which the object header is created. It is no longer necessary to explicitly delete object headers of volatile objects created in this way.
  • a secure element is created that has a storage architecture that enables efficient management, in particular creation and/or deletion, of objects that are only needed temporarily.
  • An object in connection with 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 set up to store both the object header and the object data fields of an object.
  • 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. This means that the entire object has a uniform, limited lifespan that is limited to the duration of the session.
  • the volatile heap memory can be set up in whole or in part as:
  • RAM heap volatile heap memory
  • an activation of the or a volatile heap memory segment in particular activation by an application, or alternatively by the operating system or otherwise.
  • start and end of a session are effected by similar events, for example: -Start by starting and ending by resetting (or shutting down) the Secure Element; - Start by selecting and end by deselecting an application; - Start by activating and end by deactivating a volatile heap memory segment.
  • start and end of a session are caused by different types of events, for example: - Start by selecting an application and end by resetting (or shutting down) the Secure Element.
  • the volatile heap memory is segmented into at least two, or more, volatile heap memory segments, with at least some of the volatile heap memory segments having different time-limited durations of a session of the volatile heap memory segment and corresponding different lifetimes of objects on the respective volatile heap memory segment.
  • This embodiment of the invention enables targeted creation of complete objects with different lifespans by creating the 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 clear-on-reset heap, so that the first object is only deleted when the secure element is reset, comprising, according to the invention, deletion of data fields and header of the first object.
  • a second object is created on a second volatile heap memory segment, which is designed as a clear-on-deselect heap, so that the second object is deleted when the application in which the object is contained is deselected, according to the invention comprehensively deleting data fields and headers of the second object.
  • 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.
  • 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 are stored only in that volatile heap memory segment can in which the object itself is stored.
  • the reference would be stored on a different heap memory segment that has a longer session duration than the heap memory segment on the If the object referenced by the reference lies, the reference would remain alive longer than the object, thus leaving behind a dangling reference.
  • the Secure Element is optionally designed as a JavaCard-based microprocessor device.
  • the objects are JavaCard objects
  • heaps are JavaCard heaps, but in the case of volatile heaps, they are stored in volatile memory.
  • the secure element can be designed as: payment card, virtual payment card, mobile phone subscriber identity module (SIM; e.g. eUlCC, UICC, SIM card, etc.), ID module (passport, ID card), health card.
  • SIM mobile phone subscriber identity module
  • ID module passport, ID card
  • each volatile heap memory segment has a segment size, and for at least some or all of the volatile heap memory segments, the segment size may 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 the current memory requirement, thereby consuming as little memory space as possible on the one hand and providing enough memory space on the other.
  • An object optionally has an object size, with the object size including the data fields and the header.
  • 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, then the segment size of the volatile heap memory segment is also changed in accordance with the changed object size.
  • the secure element further includes an object stored in the volatile heap, which includes an object header and object data fields stored in the volatile heap.
  • the secure element further comprises a transient object that includes an object header stored in the non-volatile heap memory and that includes one or more data fields stored in the volatile heap memory, so that in particular the transient object as Root object serves or can serve for objects stored in the volatile heap memory.
  • the Header stored because the header has been stored in non-volatile traditional heap memory.
  • a method for memory management in a secure element that includes a virtual machine, a non-volatile memory and a volatile main memory includes creating, on a heap memory of the secure element, an object that includes an object header and object data.
  • the method is characterized in that the object is created on 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 kept stored only for a maximum of the time-limited duration of a session of the volatile heap memory segment, the session being time-limited by a start and an end of the session, so that the object is stored on the volatile heap memory segment.
  • Memory segment has a limited lifespan corresponding to the time-limited duration of the session.
  • the method is optionally applied so that at least two, or more, objects on at least two or more volatile heap memory segments of the volatile heap memory are created, with at least some of the volatile heap memory segments having different durations of the session of the volatile heap memory segment, so that objects with different limited lifespans are created on the respective volatile heap memory segment.
  • heap memory segments with variable segment sizes can optionally be created, as already described above.
  • the object is created on a volatile heap memory segment in one of the following ways:
  • the created object is created by a creating object, whereby the creating object is optionally designed as one of the following:
  • Fig. 1 is a schematic representation of a heap memory arrangement of a secure element, according to an embodiment of the invention.
  • Fig. 1 shows a schematic representation of a heap memory arrangement of a secure element, according to an 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 stripes.
  • the heap memory arrangement of the secure element includes 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 designed to store persistent objects P, where both the object header H and the object data D are in object data fields in the non-volatile heap memory, NVM heap , are stored.
  • a persistent object P in the non-volatile heap memory, NVM heap is schematically indicated by an oval P.
  • the non-volatile heap memory, NVM heap can also work in conjunction with the main memory, RAM, to store transient data in which 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 transient objects T are schematically indicated, in which 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 are.
  • the secure element further has a volatile heap memory, RAM heap, set up in the volatile main memory RAM, which is set up to store entire objects and not just parts of objects such as only the object data fields the object data or just the object headers.
  • the volatile heap memory, RAM heap, shown in FIG. 1 is segmented into several heap memory segments SI, S2, S3, ... Sn.
  • 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.
  • 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.
  • a small section of the volatile main memory RAM is shown schematically to illustrate the one transient object T, with a free area (white) and one occupied by object data Area (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.
  • JCCRE_3-1 JCCRE_3-l_Feb-2021 - Java CardTM Platform Runtime Environment Specification, Classic Edition, Version 3.1, February 2021

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Memory System (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Storage Device Security (AREA)

Abstract

Die Erfindung schafft ein Secure Element umfassend: - eine Virtuelle Maschine; - einen in einem nichtflüchtigen Speicher (NVM) eingerichteten, und zum persistenten Speichern von Objekten eingerichteten, nichtflüchtigen Heap-Speicher (NVM- Heap); und - einen zum nicht-persistenten Speichern von Daten eingerichteten flüchtigen Arbeitsspeicher (RAM). Das Secure Element ist gekennzeichnet durch: einen im flüchtigen Arbeitsspeicher (RAM) eingerichteten flüchtigen Heap-Speicher (RAM-Heap), der mindestens ein flüchtiges Heap-Speicher-Segment (SI, S2, S3,... Sn) enthält, das dazu eingerichtet ist, Objekte nur höchstens während einer zeitlich begrenzten Dauer einer Sitzung des flüchtiges Heap-Speicher-Segments (SI, S2, S3,... Sn) gespeichert zu halten, wobei die Sitzung zeitlich begrenzt ist durch einen Beginn und ein Ende der Sitzung, so dass ein Objekt auf dem flüchtigen Heap-Speicher-Segment (SI, S2, S3,... Sn) eine entsprechend der zeitlich begrenzten Dauer der Sitzung zeitlich begrenzte Lebensdauer hat. Die Erfindung schafft weiter ein Verfahren zur Speicherverwaltung in einem Secure Element, umfassend ein Anlegen eines Objekts, das einen Objekt-Header und Objektdaten umfasst, auf einem solchen flüchtigen Heap-Speicher-Segment (SI, S2, S3,... Sn).

Description

Secure Element mit Heap-Speicher
Gebiet der Erfindung
Die Erfindung betrifft Secure Element, insbesondere eine JavaCard-basierte Mikro- prozessoreinrichtung. JavaCard bildet eine reduzierte Version der Programmiersprache Java, die speziell die Beschränkungen Secure Elements wie Smartcards oder anders geformten oder gehäusten fälschungssicheren Sicherheitschips berücksichtigt. Beispiele für Secure Elements sind Zahlungsverkehrskarten und in Software vorgehaltene virtualisierte Zahlungsverkehrskarten. Weitere Beispiele für Secure Elements sind Teilnehmeridentitätsmodule oder Subscriber Identity Modules - SIMs - jeden Formfaktors, insbesondere SIM-Karten oder UICCs, einlötbare eUlCCs, in ein Chipset integrierte iUICCs. Eine JavaCard-basierte Mikroprozessoreinrichtung in Form einer Chipkarte wird verbreitet als JavaCard bezeichnet, als der ursprünglichste Formfaktor eines solchen Secure Element.
Stand der Technik
Das Dokument [1] JCCRE_3-l_Feb-2O21 - Java Card™ Platform Runtime Environment Specification, Classic Edition, Version 3.1, February 2021 ist eine der grundlegenden Spezifikationen zur JavaCard Technologie. Das Dokument [1] adressiert Secure Elements, wie beispielsweise Smartcards und andere fälschungssichere Sicherheitschips (Vorwort „Preface").
Das Dokument [1] JCCRE_3-1 offenbart, dass JavaCard Objekte generell auf einem persistenten Heap-Speicher angelegt werden, der beim Zurücksetzen („reset") der JavaCard erhalten bleiben (siehe Kapitel 2 - Lifetime of the Java Card Virtual Machine, und Kapitel 5 - Memory Model). Dokument [1] JCCRE_3-1, Kapitel 5, offenbart allerdings auch zwei Arten von nicht-persistenten Objekten, und zwar in Kapitel 5.1 transiente Objekte („transient objects"), und in Kapitel 5.2 temporäre Objekte („temporary objects"), insbesondere Array Views (Kapitel 5.3) als ein Sonderfall temporärer Objekte. Wie in Kapitel 5.1 ausgeführt ist, sind nur die Inhalte der Datenfelder der transienten Objekte eine transiente Natur, indem sie in einem flüchtigen RAM Speicher gespeichert sind, und nicht etwa in einem nichtflüchtigen EERPOM Speicher. Die Inhalte der Datenfelder eines transienten Objektes werden gelöscht, wenn ein Ereignis („event") eintritt, das entweder ein RESET, also ein Zurücksetzen des Secure Element, oder ein DESELECT, also ein Entwählen („deselect") eines ausgewählten („selected") Applet, in dem das transiente Objekt enthalten ist. Dokument [1] JCCRE_3-1 nennt zwei Typen von transienten Objekten, und zwar CLEAR_ON_RESET transiente Objekte und CLEAR_ON_DESELECT transiente Objekte.
Die Header transienter Objekte sind dagegen auf dem Heap-Speicher des Secure Element gespeichert, der im nichtflüchtigen Speicher NVM (z.B. EEPROM) vorgesehen ist.
Wenn ein transientes Objekt vollständig entfernt werden soll, reicht es nicht aus, das erforderliche Ereignis („event") auszulösen, wie beispielsweise Entwählen („deselect") des das Objekt enthaltenden Applet, oder Zurücksetzen („reset") des Secure Element. Der Header im nichtflüchtigen Heap-Speicher verbleibt auch nach einem Deselect oder Reset, und muss bei Bedarf aktiv beseitigt werden, beispielsweise mittels eines Garbage Collection Mechanismus.
Es wäre wünschenswert, für Objekte, die nur vorübergehend benötigt werden, beispielsweise bis zum nächsten Zurücksetzen (Reset) des Secure Element, oder bis zum nächsten Entwählen (Deselect) des das Objekt enthaltenden Applet, eine Speicherarchitektur zu haben, die ein effizientes Verwalten, insbesondere Anlegen oder / und Löschen, der Objekte ermöglicht.
Die temporären Objekte gemäß Kapitel 5.2, 5.3 sind kurzlebige Objekte, die nur durch den aktuellen Programmausführungsfluss referenziert werden können, und nur vom Ausführungsstapelspeicher („execution stack") als lokale Variablen refe- renziert werden können. Hieraus folgt, dass nur eine sehr begrenzte Anzahl von Objekten als temporäre Objekte angelegt werden können, und zwar (i) einige spezielle Entry Point Objekte, (ii) Global Arrays, und (iii) Array Views.
Das Dokument US7702872B2 aus dem Stand der Technik offenbart ein Secure Element umfassend eine Virtuelle Maschine, die in einem nichtflüchtigen Systemspeicher implementiert ist, sowie einen nichtflüchtigen Applikationsspeicher und einen flüchtigen Arbeitsspeicher, und des Weiteren einen Variabienspeicherbereich für globale Variablen, der in einem flüchtigen Arbeitsspeichervorgesehen ist.
Zusammenfassung der Erfindung
Der Erfindung liegt die Aufgabe zu Grunde, ein Secure Element zu schaffen, das eine Speicherarchitektur hat, die ein effizientes Verwalten, insbesondere Anlegen oder / und Löschen, von Objekten ermöglicht, die nur vorübergehend benötigt werden.
Die Aufgabe wird gelöst durch ein Secure Element nach Anspruch 1. Vorteilhafte Ausgestaltungen der Erfindung sind in den abhängigen Ansprüchen angegeben.
Das Secure Element nach Anspruch 1 umfasst: - eine Virtuelle Maschine; - einen in einem nichtflüchtigen Speicher eingerichteten, und zum persistenten Speichern von Objekten eingerichteten, nichtflüchtigen Heap-Speicher; und - einen zum nicht-persistenten Speichern von Daten eingerichteten flüchtigen Arbeitsspeicher. Das Secure Element ist gekennzeichnet durch: einen im flüchtigen Arbeitsspeicher eingerichteten flüchtigen Heap-Speicher, der mindestens ein flüchtiges Heap-Speicher- Segment enthält, das dazu eingerichtet ist, Objekte nur höchstens während einer zeitlich begrenzten Dauer einer Sitzung des flüchtiges Heap-Speicher-Segments gespeichert zu halten. Hierbei ist die Sitzung zeitlich begrenzt durch einen Beginn und ein Ende der Sitzung. Ein Objekt auf dem flüchtigen Heap-Speicher-Segment hat eine entsprechend der zeitlich begrenzten Dauer der Sitzung zeitlich begrenzte Lebensdauer.
Objekt-Header werden im Heap-Speicher gespeichert und daher herkömmlicherweise im nicht-flüchtigen Heap-Speicher. Der erfindungsgemäße im flüchtigen Arbeitsspeicher eingerichtete flüchtige Heap-Speicher ermöglicht ein Speichern nicht nur von Datenfeldern von Objekten, sondern auch von Objekt-Headern von Objekten, im flüchtigen Speicher. Hierdurch sind nicht nur die Datenfelder sondern auch die Objekt-Header eines Objekts flüchtig angelegt. Genauer lässt sich die Lebensdauer des kompletten Objekts, umfassend Objekt-Datenfelder und Objekt-Header, mit einer auf die Dauer einer Sitzung zeitlich begrenzten Lebensdauer anlegen. Noch genauer lässt sich die Lebensdauer eines kompletten Objekts entsprechend den Sitzungs-Eigenschaften des flüchtigen Heap-Speicher-Segments, auf dem der Objekt-Header angelegt wird, begrenzen. Ein explizites Löschen von Objekt-Headern derartig angelegter flüchtiger Objekte ist nicht mehr erforderlich.
Daher ist gemäß Anspruch 1 ein Secure Element geschaffen, das eine Speicherarchitektur hat, die ein effizientes Verwalten, insbesondere Anlegen oder / und Löschen, von Objekten ermöglicht, die nur vorübergehend benötigt werden.
Ein Objekt im Zusammenhang mit der Erfindung umfasst vorzugsweise einen Objekt-Header und ein oder mehrere Objekt-Datenfelder. Der flüchtige Heap-Speicher bzw. das flüchtige Heap-Speicher-Segments des flüchtigen Heap-Speichers ist dann dazu eingerichtet, sowohl den Objekt-Header als auch die Objekt-Datenfelder eines Objekts gespeichert zu halten. Hierdurch wirkt die sich begrenzte Dauer einer Sitzung des flüchtiges Heap-Speicher-Segments des flüchtigen Heap-Speichers sowohl auf den Objekt-Header als auch die Objekt-Datenfelder eines Objekts aus. Hierdurch hat das komplette Objekt eine einheitliche begrenzte Lebensdauer hat, die auf die Dauer der Sitzung zeitlich begrenzt ist. Wahlweise ist der flüchtige Heap-Speicher ganz oder teilweise eingerichtet als:
- Clear-on-Reset Heap, wobei das Ende der Sitzung durch ein Zurücksetzen (Reset) des Secure Element erwirkt wird; oder/und
- Clear-on-Deselect Heap eingerichtet ist, wobei das Ende der Sitzung durch ein Ent- wählen (Deselect) einer Applikation erwirkt wird, von der ein oder mehrere Objekte auf dem flüchtigen Heap-Speicher (RAM-Heap) gespeichert sind; oder/und
- Clear-on-Session-Deactivation Heap, wobei das Ende der Sitzung durch ein an das Secure Element gerichtetes Kommando zur Beendigung einer aktuell laufenden Sitzung erwirkt wird.
Der Beginn der Sitzung wird wahlweise durch eines der folgenden erwirkt:
- ein Starten des Secure Element; oder/und
- ein Auswählen (Select) einer Applikation, von der ein oder mehrere Objekte auf dem flüchtigen Heap-Speicher (RAM-Heap) gespeichert sind;
- ein Aktivieren des oder eines flüchtigen Heap-Speicher-Segments, insbesondere Aktivieren durch eine Applikation, oder aber auch alternativ durch das Betriebssystem oder anderweitig.
Wahlweise werden Beginn und Ende einer Sitzung durch gleichartige Ereignisse erwirkt, beispielsweise: -Beginn durch Starten und Ende durch Zurücksetzen (oder Herunterfahren) des Secure Element; - Beginn durch Auswählen (Select) und Ende durch Entwählen (Deselect) einer Applikation; - Beginn durch Aktivieren und Ende durch Deaktivieren eines flüchtigen Heap-Speicher-Segments.
Alternativ werden Beginn und Ende einer Sitzung durch unterschiedlich geartete Ereignisse erwirkt, beispielsweise: - Beginn durch Auswählen (Select) einer Applikation und Ende durch Zurücksetzen (oder Herunterfahren) des Secure Element.
Wahlweise ist der flüchtige Heap-Speicher in mindestens zwei, oder mehrere, flüchtige Heap-Speicher-Segmente segmentiert, wobei zumindest manche der flüchtigen Heap-Speicher-Segmente unterschiedliche zeitlich begrenzte Dauern einer Sitzung des flüchtigen Heap-Speicher-Segments und entsprechende unterschiedliche Lebensdauern von Objekten auf dem jeweiligen flüchtigen Heap-Speicher-Segment haben. Diese Ausführungsform der Erfindung ermöglicht ein zielgerichtetes Anlegen von kompletten Objekten mit unterschiedlich gestalteten Lebensdauern, indem die Objekte auf flüchtigen Heap-Speicher-Segmenten mit unterschiedlichen zeitlichen Dauern der Sitzung angelegt werden. Beispielsweise wird ein erstes Objekt auf einem ersten flüchtigen Heap-Speicher-Segment angelegt, das als Clear-On-Reset Heap gestaltet ist, so dass das erste Objekt erst bei einem Zurücksetzen (Reset) des Secure Element gelöscht wird, erfindungsgemäß umfassend Löschen von Datenfeldern und Header des ersten Objekts. Ein zweites Objekt wird auf zweiten flüchtigen Heap-Speicher-Segment angelegt, das als Clear-On-Deselect Heap gestaltet ist, so dass das zweite Objekt bereits bei einem Entwählen (Deselect) der Applikation gelöscht wird, in welcher das Objekt enthalten ist, erfindungsgemäß umfassend Löschen von Datenfeldern und Header des zweiten Objekts. Das zweite Objekt wird allerdings auch gelöscht, wenn ein Zurücksetzen des Secure Element erfolgt, ohne dass zuvor die Applikation entwählt (deselected) wird, wahlweise durch gezielten Reset, oder durch versehentliches Unterbrechen und Wiederherstellen der Spannungsversorgung.
Wahlweise sind zumindest manche der flüchtigen Heap-Speicher-Segmente, oder jedes flüchtige Heap-Speicher-Segment, dazu gestaltet, dass Referenzen auf ein in dem jeweiligen flüchtigen Heap-Speicher-Segment gespeichertes Objekt nur in demjenigen flüchtigen Heap-Speicher-Segment gespeichert werden können in dem das Objekt selbst gespeichert ist. Hierdurch wird verhindert, dass bezugslose Referenzen („dangling references") Zurückbleiben, nachdem ein Objekt erfindungsgemäß durch Sitzungsablauf gelöscht worden ist, also nachdem die Sitzung des das Objekt speichernden Heap-Speicher-Segment beendet worden ist (abgelaufen ist). Wäre die Referenz hingegen auf einem anderen Heap-Speicher-Segment gespeichert, das eine längere Sitzungsdauer hat als das Heap-Speicher-Segment auf dem das durch die Referenz referenzierte Objekt liegt, würde die Referenz länger am Leben bleiben als das Objekt, und somit eine bezugslose Referenz („dangling reference") Zurückbleiben.
Das Secure Element ist wahlweise als JavaCard-basierte Mikroprozessoreinrichtung gestaltet. In diesem Fall sind die Objekte JavaCard Objekte, und Heap-Speicher sind JavaCard Heap-Speicher, die im Fall des flüchtigen Heap-Speicher jedoch im flüchtigen Arbeitsspeicher angelegt sind.
Das Secure Element ist wahlweise gestaltet als: Zahlungsverkehrskarte, virtuelle Zahlungsverkehrskarte, Mobilfunk-Teilnehmeridentitätsmodul (SIM; z.B. eUlCC, UICC, SIM-Karte etc.), Ausweismodul (Pass, Personalausweis), Gesundheitskarte.
Wahlweise hat jedes flüchtige Heap-Speicher-Segment eine Segmentgröße, wobei für zumindest manche oder alle der flüchtigen Heap-Speichersegmente die Segmentgröße während der Lebensdauer des Heap-Speicher-Segments verändert werden kann. Diese Ausführungsform eines flüchtigen Heap-Speicher-Segments erlaubt es, die Segmentgröße auf den aktuellen Speicherbedarf flexibel anzupassen, und dadurch einerseits so wenig Speicherplatz wie möglich zu verbrauchen, und andererseits genügend Speicherplatz bereit zu stellen. Wahlweise hat ein Objekt eine Objektgröße, wobei von der Objektgröße die Datenfelder und der Header umfasst sind. Wahlweise wird die Segmentgröße des flüchtigen Heap-Speicher-Segments gleich der Objektgröße angelegt. Wird die Objektgröße verändert, beispielsweise indem Datenfelder hinzugefügt oder entfernt werden, dann wird die Segmentgröße des flüchtigen Heap-Speicher-Segments entsprechend der veränderten Objektgröße ebenfalls verändert.
Wahlweise umfasst das Secure Element weiter ein auf dem flüchtigen Heap-Speicher gespeichertes Objekt, das einen Objekt-Header und Objekt-Datenfelder umfasst, die im flüchtigen Heap-Speicher gespeichert sind. Wahlweise umfasst das Secure Element weiter ein transientes Objekt, das einen Objekt-Header umfasst, der im nichtflüchtigen Heap-Speicher gespeichert ist, und das ein oder mehrere Datenfelder umfasst, die im flüchtigen Heap-Speicher gespeichert sind, so dass insbesondere das transiente Objekt als Root-Objekt für im flüchtigen Heap-Speicher gespeicherte Objekte dient oder dienen kann.
Im Unterschied zu den erfindungsgemäß komplett auf dem flüchtigen Heap-Speicher angelegten Objekten, bei denen beim Löschen des Objekts auch der Header des Objekts gelöscht wird, und die somit als volatile Objekte bezeichnet werden könnten, verbleibt bei einem transienten Objekt nach dem Löschen des Objekts der Header gespeichert, da der Header im nicht-flüchtigen herkömmlichen Heap-Speicher gespeichert worden ist.
Ein erfindungsgemäßes Verfahren zur Speicherverwaltung in einem Secure Element, das eine Virtuelle Maschine, einen nichtflüchtigen Speicher und einen flüchtigen Arbeitsspeicher umfasst, umfasst ein Anlegen, auf einem Heap-Speicher des Secure Element, eines Objekts, das einen Objekt-Header und Objektdaten umfasst. Das Verfahren ist dadurch gekennzeichnet, dass das Objekt auf einem flüchtigen Heap-Speicher-Segment angelegt wird: - welches in einem im flüchtigen Arbeitsspeicher eingerichteten flüchtigen Heap-Speicher enthalten ist; und - auf welchem das Objekt nur höchstens während der zeitlich begrenzten Dauer einer Sitzung des flüchtiges Heap-Speicher-Segments gespeichert gehalten wird, wobei die Sitzung zeitlich begrenzt ist durch einen Beginn und ein Ende der Sitzung, so dass das Objekt auf dem flüchtigen Heap-Speicher-Segment eine entsprechend der zeitlich begrenzten Dauer der Sitzung zeitlich begrenzte Lebensdauer hat.
Das Verfahren wird wahlweise so angewandt, dass mindestens zwei, oder mehrere, Objekte auf mindestens zwei oder mehr flüchtigen Heap-Speicher-Segmenten des flüchtigen Heap-Speichers angelegt werden, wobei zumindest manche der flüchtigen Heap-Speicher-Segmente unterschiedliche Dauern der Sitzung des flüchtigen Heap-Speicher-Segments haben, so dass entsprechend Objekte mit unterschiedlich begrenzten Lebensdauern auf dem jeweiligen flüchtigen Heap-Speicher-Segment angelegt werden. Zudem können wahlweise Heap-Speicher-Segmente mit variabler Segmentgröße angelegt werden, wie weiter oben bereits beschrieben wurde.
Gemäß Ausführungsformen der Erfindung erfolgt das Anlegen des Objekts auf einem flüchtigen Heap-Speicher-Segment wahlweise auf eine der folgenden Weisen:
(a) direktes Anlegen auf dem flüchtigen Heap-Speicher-Segment - hierdurch wird direkt ein volatiles Objekt erzeugt, dessen Objekt-Header und Datenfelder für Objektdaten gleichermaßen im nichtflüchtigen Heaps-Speicher gelegen sind;
(b) Anlegen des Objekts auf einem anderen Speicher als dem flüchtigen Heap-Spei- cher-Segment, insbesondere auf dem nichtflüchtigen Heap-Speicher, und nachfolgendes Kopieren des Objekts in das flüchtige Heap-Speicher-Segment - hierdurch wird ein zuerst nichtflüchtiges oder transientes Objekt umwandelnd in ein volatiles kopiert.
Wahlweise wird das angelegte Objekt durch ein erzeugendes Objekt angelegt, wobei das erzeugende Objekt wahlweise als eines der folgenden gestaltet ist:
(a) als transientes Objekt, das einen Objekt-Header im nichtflüchtigen Heap-Spei- cher und ein oder mehrere Datenfelder für Objektdaten im flüchtigen Speicher umfasst, wobei das angelegte Objekt in einem oder mehreren der Datenfelder des erzeugenden Objekts angelegt wird - da das erzeugte Objekt vollständig im Bereich der Objektdaten des anlegenden Objekts liegt, ist das erzeugte Objekt automatisch ein volatiles Objekt, bei dem der Objekt-Header und die Objektdaten flüchtig sind;
(b) als volatiles Objekt, das einen Objekt-Header und ein oder mehrere Datenfelder im flüchtigen Speicher umfasst, wobei das angelegte Objekt in einem oder mehreren der Datenfelder des erzeugenden Objekts angelegt wird - ein durch ein volatiles Objekt angelegtes Objekt ist automatisch wieder ein volatiles Objekt. Indem ein angelegtes Objekt durch ein transientes oder volatiles Objekt angelegt wird, kann dem angelegten Objekt implizit die Klasse „volatil" als Parameter mitgegeben werden, was explizit in JavaCard nicht möglich ist, da JavaCard nicht vorsieht, Klassentypen als Parameter zu übergeben.
Kurze Beschreibung der Zeichnungen
Im Folgenden wird die Erfindung an Hand von Ausführungsbeispielen und unter Bezugnahme auf die Zeichnung näher erläutert, in der zeigt:
Fig. 1 eine schematische Darstellung einer Heap-Speicher Anordnung eines Secure Element, gemäß einer Ausführungsform der Erfindung.
Detaillierte Beschreibung von Ausführungsbeispielen
Fig. 1 zeigt eine schematische Darstellung einer Heap-Speicher Anordnung eines Secure Element, gemäß einer Ausführungsform der Erfindung. In Fig. 1 ist folgende Muster-Codierung verwendet. Freie Speicherbereiche sind weiß dargestellt. Durch Objektdaten belegte Speicherbereiche sind gepunktet dargestellt. Durch Objekt- Header belegte Speicherbereiche sind gestreift dargestellt. Die Heap-Speicher Anordnung des Secure Element umfasst einen nicht-flüchtigen Heap-Speicher, NVM- Heap, der wahlweise wie ein aus dem Stand der Technik bekannter nicht-flüchtigen Heap-Speicher gestaltet sein kann, und einen flüchtigen Arbeitsspeicher RAM. Der nicht-flüchtige Heap-Speicher, NVM-Heap, ist dazu eingerichtet, persistente Objekte P zu speichern, bei denen sowohl der Objekt-Header H als auch die Objektdaten D in Objekt-Datenfeldern im nicht-flüchtigen Heap-Speicher, NVM-Heap, gespeichert sind. Durch ein Oval P ist ein persistentes Objekt P im nicht-flüchtigen Heap-Speicher, NVM-Heap, schematisch angedeutet. Der nicht-flüchtige Heap-Speicher, NVM-Heap, vermag zudem in Zusammenwirken mit dem Arbeitsspeicher, RAM, transiente Daten zu speichern, bei denen der Objekt-Header im nicht-flüchtigen Heap-Speicher, NVM-Heap, gespeichert ist, und die Objektdaten in den Objekt- Datenfeldern im flüchtigen Arbeitsspeicher RAM gespeichert sind. Durch zwei Ovale T sind zwei transiente Objekte T schematisch angedeutet, bei denen der Objekt-Header im nicht-flüchtigen Heap-Speicher, NVM-Heap, gespeichert ist, und die Objektdaten bzw. Objekt-Datenfelder in einem weitgehend beliebigen verfügbaren Bereich des flüchtigen Arbeitsspeichers RAM gespeichert sind.
Gemäß der Erfindung weist das Secure Element weiter einen im flüchtigen Arbeitsspeicher RAM eingerichteten flüchtigen Heap-Speicher, RAM-Heap, auf, der dazu eingerichtet ist, ganze Objekte gespeichert zu halten, und nicht nur Teile von Objekten wie beispielsweise nur die Objekt-Datenfelder mit den Objektdaten oder nur die Objekt-Header. Der in Fig. 1 dargestellte flüchtige Heap-Speicher, RAM-Heap, ist in mehrere Heap-Speicher-Segmente SI, S2, S3, ... Sn segmentiert. Im Zusammenhang mit der Erfindung wird hier der Begriff des volatilen Objekts eingeführt, der ein Objekt bezeichnet, bei dem sowohl die Objektdaten als auch der Objekt-Header im erfindungsgemäßen flüchtigen Heap-Speicher, RAM-Heap, gespeichert sind.
Durch ein Oval V ist ein volatiles Objekt angedeutet, dessen Objekt-Datenfelder mit den Objektdaten, sowie die Objekt-Header, beide im flüchtigen Heap-Speicher, RAM-Heap, gespeichert sind, genauer in einem Heap-Speicher-Segment Sl.
Um zu verdeutlichen, dass die Objektdaten transienter Objekte nicht im erfindungsgemäßen RAM-Heap gespeichert sein müssen, ist zur Veranschaulichung des einen transienten Objekts T ein kleiner Ausschnitt des flüchtigen Arbeitsspeichers RAM schematisch dargestellt, mit einem freien Bereich (weiß), und einem durch Objektdaten belegten Bereich (gepunktet). Ein zweites transientes Objekt hat einen Objekt-Header im nicht-flüchtigen Heap-Speicher, NVM-Heap, und Objektdaten (Objekt-Datenfelder) in einem Heap-Speicher-Segment S3 des flüchtigen Heap-Spei- chers, RAM-Heap.
Zitierter Stand der Technik
[1] [JCCRE_3-1] JCCRE_3-l_Feb-2021 - Java Card™ Platform Runtime Environment Specification, Classic Edition, Version 3.1, February 2021

Claims

P a t e n t a n s p r ü c h e
1. Secure Element umfassend:
- eine Virtuelle Maschine;
- einen in einem nichtflüchtigen Speicher (NVM) eingerichteten, und zum persistenten Speichern von Objekten eingerichteten, nichtflüchtigen Heap-Speicher (NVM- Heap); und
- einen zum nicht-persistenten Speichern von Daten eingerichteten flüchtigen Arbeitsspeicher (RAM); gekennzeichnet durch: einen im flüchtigen Arbeitsspeicher (RAM) eingerichteten flüchtigen Heap-Speicher (RAM-Heap), der mindestens ein flüchtiges Heap-Speicher-Segment (SI, S2, S3, ... Sn) enthält, das dazu eingerichtet ist, Objekte nur höchstens während einer zeitlich begrenzten Dauer einer Sitzung des flüchtiges Heap-Speicher-Segments (SI, S2, S3, ... Sn) gespeichert zu halten, wobei die Sitzung zeitlich begrenzt ist durch einen Beginn und ein Ende der Sitzung, so dass ein Objekt auf dem flüchtigen Heap-Spei- cher-Segment (SI, S2, S3, ... Sn) eine entsprechend der zeitlich begrenzten Dauer der Sitzung zeitlich begrenzte Lebensdauer hat.
2. Secure Element nach Anspruch 1, wobei ein Objekt einen Objekt-Header und ein oder mehrere Objekt-Datenfelder umfasst, und wobei der flüchtige Heap-Speicher (RAM-Heap) dazu eingerichtet ist, sowohl den Objekt-Header als auch die Objekt- Datenfelder eines Objekts gespeichert zu halten.
3. Secure Element nach Anspruch 1 oder 2, wobei der flüchtige Heap-Speicher (RAM-Heap) ganz oder teilweise eingerichtet ist als:
- Clear-on-Reset Heap, wobei das Ende der Sitzung durch ein Zurücksetzen (Reset) des Secure Element erwirkt wird; oder/und
- Clear-on-Deselect Heap eingerichtet ist, wobei das Ende der Sitzung durch ein Ent- wählen (Deselect) einer Applikation erwirkt wird, von der ein oder mehrere Objekte auf dem flüchtigen Heap-Speicher (RAM-Heap) gespeichert sind; oder/und - Clear-on-Session-Deactivation Heap, wobei das Ende der Sitzung durch ein an das Secure Element gerichtetes Kommando zur Beendigung einer aktuell laufenden Sitzung erwirkt wird.
4. Secure Element nach einem der vorangehenden Ansprüche, wobei der Beginn der Sitzung durch eines der folgenden erwirkt wird:
- ein Starten des Secure Element; oder/und
- ein Auswählen (Select) einer Applikation, von der ein oder mehrere Objekte auf dem flüchtigen Heap-Speicher (RAM-Heap) gespeichert sind;
- ein Aktivieren des oder eines flüchtiges Heap-Speicher-Segment (SI, S2, S3, ... Sn),
- Aktivieren des oder eines flüchtiges Heap-Speicher-Segment (SI, S2, S3, ... Sn) durch eine Applikation, durch das Betriebssystem oder durch eine andere Instanz im oder unter Kontrolle des Secure Element.
5. Secure Element nach einem der vorangehenden Ansprüche, wobei der flüchtige Heap-Speicher (RAM-Heap) in mindestens zwei, oder mehrere, flüchtige Heap-Spei- cher-Segmente (SI, S2, S3, ... Sn) segmentiert ist, wobei zumindest manche der flüchtigen Heap-Speicher-Segmente (SI, S2, S3, ... Sn) unterschiedliche zeitlich begrenzte Dauern einer Sitzung des flüchtigen Heap-Speicher-Segments (SI, S2, S3, ... Sn) und entsprechende unterschiedliche Lebensdauern von Objekten auf dem jeweiligen flüchtigen Heap-Speicher-Segment (SI, S2, S3, ... Sn) haben.
6. Secure Element nach einem der vorangehenden Ansprüche, zumindest manche der flüchtigen Heap-Speicher-Segmente (SI, S2, S3, ... Sn), oder jedes flüchtige Heap-Speicher-Segment dazu gestaltet ist, dass Referenzen auf ein in dem jeweiligen flüchtigen Heap-Speicher-Segment (SI, S2, S3, ... Sn) gespeichertes Objekt nur in demjenigen flüchtigen Heap-Speicher-Segment (SI, S2, S3, ... Sn) gespeichert werden können in dem das Objekt selbst gespeichert ist.
7. Secure Element nach einem der vorangehenden Ansprüche, gestaltet als Ja- vaCard-basierte Mikroprozessoreinrichtung.
8. Secure Element nach einem der vorangehenden Ansprüche, gestaltet als Zahlungsverkehrskarte oder virtuelle Zahlungsverkehrskarte, oder als Teilnehmeridentitätsmodul oder als Ausweismodul oder als Gesundheitskarte.
9. Secure Element nach einem der vorangehenden Ansprüche, wobei jedes flüchtige Heap-Speicher-Segment (SI, S2, S3, ... Sn) eine Segmentgröße hat, und wobei für zumindest manche oder alle der flüchtigen Heap-Speichersegmente (SI, S2, S3, ... Sn) die Segmentgröße während der Lebensdauer des Heap-Speicher-Segments (SI, S2, S3, ... Sn) verändert werden kann.
10. Secure Element nach einem der vorangehenden Ansprüche, weiter umfassend ein auf dem flüchtigen Heap-Speicher (RAM-Heap) gespeichertes Objekt, das einen Objekt-Header und Objekt-Datenfelder umfasst, die im flüchtigen Heap-Speicher (RAM-Heap) gespeichert sind.
11. Secure Element nach Anspruch 10, weiter umfassend ein transientes Objekt, das einen Objekt-Header umfasst, der im nichtflüchtigen Heap-Speicher (NVM- Heap) gespeichert ist, und das ein oder mehrere Datenfelder umfasst, die im flüchtigen Heap-Speicher (RAM-Heap) gespeichert sind, so dass insbesondere das transiente Objekt als Root-Objekt für im flüchtigen Heap-Speicher (RAM-Heap) gespeicherte Objekte dient.
12. Verfahren zur Speicherverwaltung in einem Secure Element, das eine Virtuelle Maschine, einen nichtflüchtigen Speicher (NVM) und einen flüchtigen Arbeitsspeicher (RAM) umfasst, das Verfahren umfassend: ein Anlegen, auf einem Heap-Speicher des Secure Element, eines Objekts, bezeichnet als angelegtes Objekt, das einen Objekt-Header und Objektdaten umfasst, dadurch gekennzeichnet, dass das Objekt auf einem flüchtigen Heap-Speicher-Segment (SI, S2, S3, ... Sn) angelegt wird,
- welches in einem im flüchtigen Arbeitsspeicher (RAM) eingerichteten flüchtigen Heap-Speicher (RAM-Heap) enthalten ist, und
- auf welchem das Objekt nur höchstens während der zeitlich begrenzten Dauer einer Sitzung des flüchtiges Heap-Speicher-Segments (SI, S2, S3, ... Sn) gespeichert gehalten wird, wobei die Sitzung zeitlich begrenzt ist durch einen Beginn und ein Ende der Sitzung, so dass das Objekt auf dem flüchtigen Heap-Speicher-Segment (SI, S2, S3, ... Sn) eine entsprechend der zeitlich begrenzten Dauer der Sitzung zeitlich begrenzte Lebensdauer hat.
13. Verfahren nach Anspruch 12, wobei mindestens zwei, oder mehrere, Objekte auf mindestens zwei oder mehr flüchtigen Heap-Speicher-Segmenten (SI, S2, S3, ... Sn) des flüchtigen Heap-Speichers (RAM-Heap) angelegt werden, wobei zumindest manche der flüchtigen Heap-Speicher-Segmente (SI, S2, S3, ... Sn) unterschiedliche Dauern der Sitzung des flüchtigen Heap-Speicher-Segments (SI, S2, S3, ... Sn) haben, so dass entsprechend Objekte mit unterschiedlich begrenzten Lebensdauern auf dem jeweiligen flüchtigen Heap-Speicher-Segment (SI, S2, S3, ... Sn) angelegt werden.
14. Verfahren nach Anspruch 12 oder 13, wobei das Anlegen des Objekts auf einem flüchtigen Heap-Speicher-Segment (SI, S2, S3, ... Sn) wahlweise auf eine der folgenden Weisen erfolgt:
(a) direktes Anlegen auf dem flüchtigen Heap-Speicher-Segment (SI, S2, S3, ... Sn);
(b) Anlegen des Objekts auf einem anderen Speicher als dem flüchtigen Heap-Spei- cher-Segment (SI, S2, S3, ... Sn), insbesondere auf dem nichtflüchtigen Heap-Spei- cher, und nachfolgendes Kopieren des Objekts in das flüchtige Heap-Speicher-Seg- ment (SI, S2, S3, ... Sn).
15. Verfahren nach einem der Ansprüche 12 bis 14, wobei das angelegte Objekt durch ein erzeugendes Objekt angelegt wird, wobei das erzeugende Objekt wahlweise als eines der folgenden gestaltet ist:
(a) als transientes Objekt, das einen Objekt-Header im nichtflüchtigen Heap-Spei- eher und ein oder mehrere Datenfelder für Objektdaten im flüchtigen Speicher umfasst, wobei das angelegte Objekt in einem oder mehreren der Datenfelder des erzeugenden Objekts angelegt wird;
(b) als volatiles Objekt, das einen Objekt-Header und ein oder mehrere Datenfelder im flüchtigen Speicher umfasst, wobei das angelegte Objekt in einem oder mehre- ren der Datenfelder des erzeugenden Objekts angelegt wird.
EP23726272.0A 2022-05-12 2023-05-09 Secure element mit heap-speicher Pending EP4523084A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102022001682.6A DE102022001682A1 (de) 2022-05-12 2022-05-12 Secure Element mit Heap-Speicher
PCT/EP2023/025218 WO2023217412A1 (de) 2022-05-12 2023-05-09 Secure element mit heap-speicher

Publications (1)

Publication Number Publication Date
EP4523084A1 true EP4523084A1 (de) 2025-03-19

Family

ID=86604013

Family Applications (1)

Application Number Title Priority Date Filing Date
EP23726272.0A Pending EP4523084A1 (de) 2022-05-12 2023-05-09 Secure element mit heap-speicher

Country Status (5)

Country Link
US (1) US20250342334A1 (de)
EP (1) EP4523084A1 (de)
CN (1) CN119173851A (de)
DE (1) DE102022001682A1 (de)
WO (1) WO2023217412A1 (de)

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0955577B1 (de) * 1998-05-04 2011-11-30 International Business Machines Corporation Verfahren und Vorrichtung zum Erzeugen eines Objektes in einem nicht dauerhaften Speicher und/oder Halten des Zugangs zu besagtem Objekt
DE10320062A1 (de) 2003-05-06 2004-12-16 Giesecke & Devrient Gmbh Speicherverwaltung bei einem tragbaren Datenträger
DE10357257A1 (de) 2003-12-08 2005-06-30 Giesecke & Devrient Gmbh Java Smart Card Chip mit für globale Variablen reserviertem Speicherbereich
DE102004062245A1 (de) * 2004-12-23 2006-07-13 Giesecke & Devrient Gmbh Verwaltung von Datenobjekten in einem nichtflüchtigen überschreibbaren Speicher
US20070016628A1 (en) * 2005-07-14 2007-01-18 Lenevo (Singapore) Pte.Ltd. Classification system for versionable objects
EP2535832B1 (de) * 2011-06-17 2017-04-26 Simulity Labs Ltd Verfahren für den Betrieb einer virtuellen Maschine auf einem Dateisystem
CA2753626C (en) * 2011-09-30 2019-05-07 Ibm Canada Limited - Ibm Canada Limitee Packed data objects
US10747645B2 (en) * 2018-04-27 2020-08-18 Microsoft Technology Licensing, Llc Selectively tracing portions of computer process execution
US10645000B1 (en) * 2018-06-03 2020-05-05 Juniper Networks, Inc Apparatus, system, and method for improving convergence across virtual control and forwarding planes within network devices

Also Published As

Publication number Publication date
US20250342334A1 (en) 2025-11-06
WO2023217412A1 (de) 2023-11-16
CN119173851A (zh) 2024-12-20
DE102022001682A1 (de) 2023-11-16

Similar Documents

Publication Publication Date Title
DE69100005T2 (de) Verfahren zum anwenderprogrammladen in einem speicherkartenleser mit mikroprozessor sowie system zur durchfuehrung dieses verfahrens.
DE69127641T2 (de) Vorrichtung und Verfahren zum Verwalten von Chipkartentransaktionen
DE69316576T2 (de) IC Karte mit alterunggeschützten Daten und Programmen
DE19536169A1 (de) Multifunktionale Chipkarte
EP0849667A2 (de) System zum Austausch von Software
DE10308545A1 (de) Verfahren und Vorrichtung zum Aktualisieren eines verteilten Programms
DE1499182A1 (de) Elektrische Datenverarbeitungsanlage
WO2000070620A1 (de) Speicheranordnung mit adressverwürfelung
EP0811204B1 (de) Verarbeitung langer nachrichten in einer chipkarte
EP1314135B1 (de) Verfahren zur virtuellen vergrösserung des stacks eines tragbaren datenträgers
EP0224639A1 (de) Verfahren zum Kontrollieren eines Speicherzugriffs auf einer Chipkarte und Anordnung zur Durchführung des Verfahrens
DE102019102861A1 (de) Verfahren und Vorrichtung zur Abschätzung der Abnutzung eines nicht-flüchtigen Informationsspeichers
EP0813723A1 (de) Chipkarte mit geschütztem betriebssystem
DE3517087A1 (de) Verfahren zur vergroesserung der maximalanzahl moeglicher programmier-loesch-zyklen an einem elektrisch programmierbaren und loeschbaren festwertspeicher (eeprom) sowie einrichtung zur durchfuehrung des verfahrens
WO2023217412A1 (de) Secure element mit heap-speicher
DE10002203B4 (de) Verfahren zum Schutz eines Mikrorechner-Systems gegen Manipulation von in einer Speicheranordnung des Mikrorechner-Systems gespeicherten Daten
EP1623394A1 (de) Speicherverwaltung bei einem tragbaren datentrager
WO2002099809A2 (de) Verfahren und vorrichtung zum ausblenden von nicht funktionstüchtigen speicherzellen
DE10324384B3 (de) Behandlung eines Fehlerereignisses bei der Installation eines Anwendungsprogramms in einem tragbaren Datenträger
DE10141926B4 (de) Verfahren zur Sicherung der Daten eines Datenspeichers
DE102004040296B3 (de) Schreiben von Daten in einen nichtflüchtigen Speicher eines tragbaren Datenträgers
EP1055983A2 (de) Steuergerät mit mindestens zwei Steuereinheiten, davon eine mit externer Schnittstelle
EP1600855B1 (de) Erzeugen und Verwenden von Speicherbelegungsinformationen bei einem tragbaren Datenträger
EP1650649A1 (de) Übergabe von Variable zwischen Interpreter-basierten und nativen Programmcodeteilen
EP2131280A2 (de) Verwalten von Instanzen einer virtuellen Maschine in einem tragbaren Datenträger

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20241212

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC ME MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20251104