MANAGING MEMORY OF A SECURE ELEMENT DOMAIN, ELECTRONIC DEVICE AND METHOD

20230325096 · 2023-10-12

    Inventors

    Cpc classification

    International classification

    Abstract

    It is described an electronic device, comprising a secure element domain that further comprises: i) a physical memory region configured to store a plurality of data sets; and ii) a control device, coupled to the physical memory region, and configured to transfer at least one data set away from the physical memory region, wherein transferring the data set comprises at least one of: a) transferring the data set as a first data blob to a virtual memory region of the secure element domain; b) off-loading the data set as a second data blob to an external domain.

    Claims

    1-15. (canceled)

    16. An electronic device, comprising a secure element domain that further comprises: a physical memory region configured to store a plurality of data sets; and a control device, coupled to the physical memory region, and configured to: transfer at least one data set of the plurality of data sets away from the physical memory region, wherein transferring the data set comprises at least one of: transferring the data set as a first data blob to a virtual memory region of the secure element domain; and off-loading the data set as a second data blob to an external domain.

    17. The electronic device according to claim 16, wherein the control device comprises an object manager.

    18. The electronic device according to claim 17, wherein the object manager is configured to register the position of the first data blob in the virtual memory region.

    19. The electronic device according to claim 17, wherein the object manager is configured to register the position of the second data blob in the external domain.

    20. The electronic device according to claim 16, wherein a security hierarchy of the security domain is independent of at least one of transferring and off-loading.

    21. The electronic device according to claim 16, wherein the data set comprises at least one of a secure element application, a profile, a plurality of pages.

    22. The electronic device according to claim 16, wherein transferring the first data blob to the virtual memory region comprises compressing the data set to obtain a compressed first data blob.

    23. The electronic device according to claim 22, wherein transferring the first data blob to the virtual memory region comprises transferring the compressed first data blob to the virtual memory region.

    24. The electronic device according to claim 22, wherein the control device is further configured to de-compress only a part of the compressed first data blob, wherein the part is smaller than the first data blob.

    25. The electronic device according to claim 16, wherein the control device is further configured to allocate the physical memory region against required virtual memory region for the first data blob.

    26. The electronic device according to claim 16, wherein the control device is further configured to reload the off-loaded second data blob from the external domain.

    27. The electronic device according to claim 26 wherein reloading is via an external interface and free of an additional secure channel.

    28. The electronic device according to claim 16, wherein the external domain is configured to store the off-loaded second data blob in a further physical memory region.

    29. The electronic device according to claim 28, wherein the external domain comprises at least one of a host domain and an application control device.

    30. The electronic device according to claim 16, wherein the electronic device further comprises a contact-less communication domain coupled to the secure element domain via a domain interface.

    31. The electronic device according to claim 30, wherein the control device is further configured to off-load the second data blob from the secure element domain via the domain interface to the contact-less communication domain and via a communication-external interface to the external domain.

    32. The electronic device according to claim 30, wherein the control device is further configured to reload the second data blob from the external domain via the communication-external interface to the contact-less communication domain and via the domain interface to the secure element domain.

    33. The electronic device according to claim 30, wherein the contact-less communication domain and the secure element domain are integrated into a common integrated circuit.

    34. A mobile device comprising the electronic device according to claim 16, wherein the mobile device is one of a smart card and a mobile phone.

    35. A method of managing a secure element domain that comprises a physical memory region with a plurality of data sets, the method comprising: analyzing the data sets stored in the physical memory region with respect to a data transfer criterium, and, in case that the data transfer criterion is fulfilled for a data set of the plurality of data sets; and transferring said data set away from the physical memory region, wherein transferring the data set comprises at least one of: transferring the data set as a first data blob to a virtual memory region of the secure element domain; and off-loading the data set as a second data blob to an external domain.

    Description

    BRIEF DESCRIPTION OF THE DRAWINGS

    [0047] FIG. 1 illustrates an exemplary embodiment of an electronic device with a secure element domain according to an exemplary embodiment of the disclosure.

    [0048] FIG. 2 illustrates an exemplary embodiment of the memory of the secure element domain according to an exemplary embodiment of the disclosure.

    [0049] FIG. 3 illustrates an exemplary embodiment of transferring a data set as a data blob in the context of the secure element domain according to an exemplary embodiment of the disclosure.

    [0050] FIG. 4 illustrates an exemplary embodiment of off-loading and re-loading the second data blob between physical memory region and external memory according to an exemplary embodiment of the disclosure.

    [0051] FIG. 5 illustrates an exemplary embodiment of off-loading and re-loading the second data blob via a contact-less communication domain according to an exemplary embodiment of the disclosure.

    [0052] FIG. 6 illustrates an exemplary embodiment of transferring and re-transferring the first data blob with respect to the virtual memory region according to an exemplary embodiment of the disclosure.

    [0053] The illustrations in the drawings are schematic. In different drawings, similar or identical elements are provided with the same reference signs.

    DESCRIPTION OF EMBODIMENTS

    [0054] Before, referring to the drawings, exemplary embodiments will be described in further detail, some basic considerations will be summarized based on which exemplary embodiments of the disclosure have been developed.

    [0055] According to an exemplary embodiment, there is described an efficient utilization of the SE NVM (physical memory region) by off-loading or compressing less frequently used SE application, without impacting the security hierarchy and hence not requiring access to security domains/keys and to re-run secure installation procedures. The SE logical (virtual) memory to physical memory region mapping (transfer) scheme can be extended with an object management function which manages the objects (data sets/blobs). Objects corresponding to individual (SE) applications could be ‘available’ (physically on card (SE domain)) or ‘off-loaded’ (off-card) or ‘compressed’ (compressed on-card) destinations (theoretically off-card compressed is also possible). Criteria (transfer criterium) can be defined for deciding to offload or compress applications, e.g. less frequently used applets can be securely offloaded or deactivated, while a mobile SIM profile can be compressed. An SE system or SE application fulfilling the defined criteria, is applied for secure offloading or compression on the physical pages of the mapped virtual NVM. The object management (object manager) map is then updated to indicate content present but ‘off-loaded’ or ‘compressed’ mapping (transfer). The physical memory region is then freed up for usage for other applications. Typically, the virtual memory region size is many multiples of physical memory region and this allows to retain the allocated virtual memory region structure even though the physical memory region is freed up. This allows to keep the complete installed security hierarchy to be untouched by off-loading or compressing procedure. On access to an application indicated as ‘offloaded’ or ‘compressed’ in the object management mapping, the corresponding data blob is fetched/uncompressed back to the SE NVM and virtual mapping is restored to the (new) physical NVM mapping.

    [0056] FIG. 1 illustrates an electronic device 100 according to an exemplary embodiment, e.g. a smart card, a PDA, or a smart phone. The electronic device 110 comprises an integrated circuit 130 which comprises a contact-less communication domain 140 and a secure element domain 150 with at least one interface (in particular, a secure element in the secure element domain 150 comprises one or more interfaces). The contact-less communication domain 140 and the secure element domain 150 are hereby integrated onto the same chip 130 and are connected via a domain interface 190. The contact-less communication domain 140 comprises an NFC controller and an NFC (antenna) interface 142 connected to an NFC antenna 143. The contact-less communication domain 140 further comprises an NFC interface 142 and a communication external interface 145 to an application control device 110 of the electronic device 100. The application control device 110 comprises a host domain (SE external domain) 120 that can be connected to the contact-less communication domain 140 via the communication external interface 145 and/or to the security element domain 150 via a (secure) external interface 158. The secure element domain 150 comprises a physical memory region with a plurality of data sets 160, in particular secure element applications.

    [0057] FIG. 2 illustrates an exemplary embodiment of the organization of the memory of the secure element domain 150 according to an exemplary embodiment of the disclosure. The physical memory region 152 is split into flash pages of for example 512 bytes. These pages can be mapped (transferred) as needed from empty page pool of the physical memory region 152 into virtual regions of the virtual memory region 154. The secure element domain 150 comprises a number of virtual regions, and each region can have for example 512 kilobytes of virtual space. These regions can be distributed within the logical address space, for example a 2.5 megabyte physical memory region can be mapped to a 128 megabyte virtual memory region. Large virtual region allows clustering of related memory in virtual contiguous space without the concern of physical memory region fragmentation, dynamic growth etc. Such a virtual mapping (transfer to virtual memory region) mechanism can provide a basis for applying the efficient utilization method proposed to maximize the possible logical address space.

    [0058] FIG. 3 illustrates an exemplary embodiment of transferring a data set 160 as a data blob 162, 164 in the context of the secure element domain 150 according to an exemplary embodiment of the disclosure. As an example, the “eSE Package B” is used as the data set 160 to be transferred. To release the used physical memory region 152a, the data set 160 is transferred away, thereby leaving free physical memory region space 152b. An object manager 155 of the secure element domain 150 is configured to up-date and store the position of each transferred data set 160. For example, the object manager 155 can indicate based on meta/link-data if a specific data set 160 is off-loaded or transferred to virtual memory region, compressed and/or secured.

    [0059] Transferring the data set 160 comprises in one example transferring the data set 160 as a first data blob 162 to the virtual memory region 154 of the secure element domain 150. Hereby, data set 160 is compressed to form a compressed first data blob 162 that is transferred to the virtual memory region 154, while the object manager 155 is up-dated to store this transfer.

    [0060] Transferring the data set 160 comprises in another example off-loading the data set 160 (from the secure element domain 150) as a second data blob 164 to an exterior domain 120, in particular a host domain. The data set 160 is optionally secured by encryption and is then transferred to the external domain 120, while the object manager 155 is up-dated to store this transfer.

    [0061] In a detailed example, the following steps are performed. In addition to virtual to physically mapping, a new object management mechanism (structure and flow) is defined, wherein the object management structure stores three types of mappings: [0062] i) object is mapped to physical memory region, [0063] ii) object is off-loaded as self-secure data blob to an off-card memory (for off-loaded type additional off-loaded info like size, security parameters (identifier, encryption type, keys, etc.) are stored), [0064] iii) object is compressed and mapped to virtual memory region holding compressed data blob (for compressed type additional compression info like compressed virtual address, size, security params (identifier, encryption type, keys, etc.) is stored). [0065] The object management structure also stores info (ex. usage count/frequency) which is used as criteria for triggering one of the physical memory region utilization improvement process. Additional meta data may describe compressed and uncompressed sizes.

    [0066] FIG. 4 illustrates an exemplary embodiment of off-loading and re-loading a data blob 164 between the physical memory region 152 and the external memory 121 of the external domain 120 according to an exemplary embodiment of the disclosure.

    [0067] In a detailed example, the following steps can be performed during (secure) off-loading: certain objects could be marked for initial offloading, during production after the installation of application in the security hierarchy, the corresponding objects are marked as off-loaded, the physical mapped memory is released, and the secure off-load data blob is provided to be stored on host.

    [0068] In a further detailed example, the following steps can be performed during (secure) off-loading: the card OS periodically checks for available free memory, when reaching pre-defined threshold, the card OS analyzes through object mapping criteria for off-loading (e.g. the usage count), identifies objects for off-loading, creates a secure off-load data blob, the corresponding objects are marked as off-loaded, and the secure offload blob is off-loaded to host and physical mapped memory is released.

    [0069] In a further detailed example, the following steps can be performed during (secure) re-loading: the object management identifies access to object data that is off-loaded, the object management checks the physical memory region availability to re-load the data blob, the object management sends request to host to fetch the off-loaded secure data blob, the object management receives the off-loaded secure data blob, the object management verifies integrity (the data blob is self-secure, no secure channel required from host), the object management allocates physical memory region against required virtual memory region for the data blob, and the object management loads content to physical memory region and updates the object mapping.

    [0070] FIG. 5 illustrates an exemplary embodiment of off-loading and reloading the data blob 164 via a contact-less communication domain 140 according to an exemplary embodiment of the disclosure. In a first example, the data blob 164 is off-loaded the secure element domain 150 and the external domain 120 through the secure external domain 158. In a further, example a notification is send through the secure external domain 158 (direct SE interface) that an off-loading through the contact-less communication domain 140 will be performed.

    [0071] In a second example, off-loading the data blob 164 is done from the secure element domain 150 via the domain interface 190 to the contact-less communication domain 140 and further via a communication-external interface 145 to the external domain 120. In the same manner, reloading the data blob 164 is done from the external domain 120 via the communication-external interface 145 to the contact-less communication domain 140 and via the domain interface 190 to the secure element domain 150.

    [0072] FIG. 6 illustrates an exemplary embodiment of transferring and re-transferring the first data blob 162 between physical memory region 152 and virtual memory region 154 according to an exemplary embodiment of the disclosure. Hereby, the data set 160 is compressed to obtain a compressed first data blob 162.

    [0073] In a detailed example, compression and transfer comprises the following steps: certain objects could be marked for initial compression, during production after the installation of application in the security hierarchy, the corresponding objects are marked as compressed, the compressed data blob is stored on card and the compressed link info is updated, and the physical mapped memory is then released.

    [0074] In a further detailed example, compression and transfer comprises the following steps: the card OS is updated periodically for condition to initiate compression, e.g. an eUICC profile is deactivated or more than ‘n’ profiles installed (e.g >3), objects are identified for compressing, thereby creating a compressed data blob, which is stored on card and the compressed link info is up-dated, the corresponding objects are marked as compressed, and the physical mapped memory is released.

    [0075] In a further detailed example, de-compression and re-transfer comprises the following steps: the object management identifies the data blob (e.g. profile such as eUICC profile or package) requested for activation is compressed, the object management checks physical memory region availability to de-compress the profile, the object management may decide to compress other profile/data first to gain necessary free memory, the object management allocates physical memory region against required virtual memory region for the de-compressed profile, the object management de-compresses the secure data blob to physical memory region, up-dates the virtual memory region mapping, and the compressed block memory is released.

    [0076] In this specification, example embodiments have been presented in terms of a selected set of details. However, a person of ordinary skill in the art would understand that many other example embodiments may be practiced which include a different selected set of these details. It is intended that the following claims cover all possible example embodiments.

    REFERENCE NUMERALS

    [0077] 100 Electronic device [0078] 110 Application processor [0079] 120 External domain, host domain [0080] 121 Further memory [0081] 130 Integrated circuit [0082] 140 Contact-less communication domain [0083] 142 NFC interface [0084] 143 NFC antenna [0085] 145 Communication interface [0086] 150 Secure element domain [0087] 152 Physical memory region [0088] 152a Used physical memory region [0089] 152b Free physical memory region [0090] 154 Virtual memory region [0091] 155 Control device, object manager [0092] 158 External interface [0093] 160 Data set [0094] 162 First blob [0095] 164 Second blob [0096] 190 Domain interface