Secure element comprising a set of logical secure elements, virtual machine architecture accessing a corresponding secure element and corresponding method for operating the secure element

Abstract

A Secure Element (14), operating with a Java Card platform, accessible by at least a host (11), said Secure Element (14) comprising a set of Logical Secure Elements (1421...142n) and a set of Shareable Interfaces applets, said Secure Element (14) comprising a further Logical Secure Element which is an administrative Logical Secure Element (141) configured to perform administrative commands (T12, T31, T32), said administrative Logical Secure Element (141) further storing the Shareable Interface applets shared by the Logical Secure Elements (141, 1421...142n) of said set of Logical Secure Elements (141, 1421...142n), said Secure Element comprising one or more stored client applet (147) within one or more of said Logical Secure Element in said set of Logical Secure Elements (1421...142n) configured to, when requesting a service from a Shareable Interface applet (1461, 148), perform first (T1) search of said Shareable Interface applet (1461, 148) in the Logical Secure Element (1421) storing said client applet (147), then a further search (T2) in the administrative Logical Secure Element (141) if said Shareable Interface applet (1461, 148) is not found in said Logical Secure Element (1421) storing said client applet (147).

Description

[0001] "Secure Element comprising a set of Logical Secure Elements, Virtual Machine Architecture accessing a corresponding Secure Element and corresponding method for operating the Secure Element"

[0002] ★ ★ ★ ★

[0003] Technical field

[0004] The description relates to a Secure Element accessible by at least a host comprising a set of Logical Secure Elements and at least shareable interface.

[0005] One more embodiment may apply to a host comprising a set of guest virtual machines supervised by a hypervisor running on a host computer, on which respective instances of a guest operative system, in particular Linux or Linux-Android operative system, are executed, such Secure Element being accessible by said set of virtual machines.

[0006] One or more embodiments can be applied to Secure Elements in integrated circuit cards such as, for instance, Universal Integrated Circuit Cards, UICCs or embedded UICCs, eUICCs.

[0007] Background

[0008] A Secure Element, i.e., a tamper-resistant platform (typically a one chip secure microcontroller) capable of securely hosting applications and their confidential and cryptographic data, in particular in accordance with the rules and security requirements set forth by a set of well-identified trusted authorities, may be accessed by a host, such as user terminal, e.g. a mobile phone. The host may access to different Logical Secure Elements (LSE) defined in such Secure Element, as for instance per the specification ETSI TS 102 221, better discussed in the following.

[0009] As to the host, in technical fields such as the automotive field, the Android architecture is requested to support multiple instances of Linux (or Linux- Android) executing in parallel.

[0010] A virtual machine architecture, i.e. an architecture comprising a set of virtual machines hosted, or supervised, i.e. managed, by a so-called hypervisor, i.e. a virtual machine monitor, on which respective instances of an operative system are executed, may be used. In this environment, if at least a Secure Element, i.e., a tamper-resistant platform (typically a one chip secure microcontroller) capable of securely hosting applications and their confidential and cryptographic data, in particular in accordance with the rules and security requirements set forth by a set of well-identified trusted authorities, is comprised in the architecture, a same Secure Element shall be accessible, in terms of cryptographic services and cryptographic keys storing services, by different virtual machines.

[0011] To this regard in figure 1 a virtual machine architecture 10 is shown schematically, which comprises a host 11, e.g., a processing unit, comprising for instance a CPU and volatile and non-volatile memory, then the host 11 hosts a virtual machine monitor 12, also called hypervisor, i.e. a virtual machine monitor which supervises the virtual machines, i.e. it may create and manage the virtual machines. The host 11 in particular corresponds to a processing unit which runs an operating system which runs the hypervisor, i.e. virtual machine monitor 12.

[0012] The hypervisor 12, in a manner known per se, by the virtualization process is able to create a set of guest virtual machines each running an instance 131...135 of an operative system for instance Android. A set refers here to a group of one or more elements, e.g., one or more virtual machines.

[0013] A Secure Element 14 is shown associated to the host instance by an UICC.

[0014] Such architecture 10 comprising a set of virtual machines may refer to a terminal, as host, e.g. a user terminal, which is interfaced to an integrated circuit card, e.g. a UICC as mentioned, by a terminal-card, or terminal-UICC interface. In this case, the UICC is assimilated to such Secure Element 14, i.e. embodies such Secure Element 14. Alternatively, embedded UICC (eUICC) or integrated UICC (iUICC) can embody the Secure Element 14, which also may be embodied by an eSE (embedded Secure Element) or an iSE (integrated Secure Element) .

[0015] The hypervisor 12 used to host multiple virtual machines, may comprise, in the automotive field, e.g., one virtual machine hosting an instance 13± of the operative system for each display (e.g., dashboard / inf otainment ) .

[0016] The hypervisor 12 may run for instance on a System On Chip (SoC) which represents the host 11, interfaced to a Secure Element or card 14. This in particular in an automotive embodiment, although in general the terminal corresponding to the host 11 can be another device with a processing unit or microcontroller.

[0017] In particular a virtual machine architecture as just described represents a multi-application capable terminal, i.e. a terminal that can support more than one first level application with possibly separate user verification requirements for each application. The applications seen by the terminal are first level applications (e.g. SIM, USIM) . As mentioned above, as defined for instance in the specification ETSI TS 102 221, in this context, i.e., of Secure Elements, e.g., integrated circuit cards or Secure Elements, Logical Secure Element (LSE) are Secure Element functionalities, applications and files grouped together to act like an independent Secure Element (e.g. UICC) . This happens in particular when multiple Logical Secure Element interfaces are supported, A Logical Secure element Interface (LSI) is instead a logical connection between an endpoint in the terminal, e.g. SoC, running the hypervisor, and one Logical Secure Element or LSE . More specifically each LSE is connected to a LSI. LSI selection may be performed using the command MANAGE LSI by the host. Thus, the LSIs operate as external interfaces .

[0018] A mechanism to select multiple application instances at the same time is represented by logical channels, for instance as defined in ISO / IEC 7816-4. To take advantage of multi-session functionality Applets can interoperate from different logical channels and can be selected multiple times in different channels (Multiselectable Applets) . For example, the card, or the Secure Element, might handle security information on one logical channel, while data is accessed on a second logical channel, while the third logical channel takes care of data encoding operations. By following this design, it is possible to access information owned by a different applet without having to deselect the currently selected applet that is handling session information. ISO (and then ETSI) defines a maximum of 20 logical channel.

[0019] Thus, for instance within the environment of the specification ETSI TS 102 221 it is possible to operate with multiple instances of applets and Multiselectable Applets. It is in particular possible to create multiple instances of an Applet with different AIDs (Application Identifiers) . An AID is the Application Identifier associated with the applet, i.e. a sequence of bit as defined for instance in ISO 7816-5. As mentioned, Multiselectable Applets are Applets having the capability of being selected on multiple logical channels at the same time.

[0020] In the specification ETSI TS 102 221 is introduced a solution with the Logical Secure Interfaces (LSI) and Logical Secure Element (LSE) , which defines a clear division between the various Logical Secure Elements. Each Logical Secure Element acts and is handled by the terminal / host like a separate Secure Element. Each Logical Secure Element operates logically independently from the others.

[0021] Thus, it is known to use logical channels, where one instance of an applet is shared among all logical channels, and multiple instances of the Applet, one for each user. There is a unique application java context. Logical channel context is not the application context.

[0022] For the multiple instances, Java card context is associated to package. So it is the same for all instances. Instances must have a different AID (Application Identifier) , which is a problem as the fixed AID is handled by the Hardware Abstraction Layer front and back ends in the terminal which provides software routines that provide programs with access to the hardware resources represented by the Secure Element.

[0023] The Logical Secure Element may solve the context and AID problem, but introduces a memory footprint problem due to loading same ELF (Executable Load File) multiple times (in different LSE) . The ELF is the container in the Secure Element of the executable code of the applications, which are instead Executable Modules .

[0024] In other words, there is a waste of resources in case the same binary (Executable Load File) is loaded in each Logical Secure Element (footprint problem) , the Logical Secure Element mechanism being thus sufficient to deliver the product but is not efficient. Also there is no division of roles between the entity which provides the shared content (ELF Provider) , capable of loading / updating / deleting ELFs and the entity that receives the shared content, here called an Operational Logical Secure Element, linked to the shared ELF.

[0025] Also, LSEs, as defined for instance in ETSI 102 221, which gives the possibility to have one physical Secure Element and more Logical Secure Element (LSE) , require in general, to be handled by the host or terminal like a separate Secure Element, a strong division, each LSE needing to have its environment, packages, applications, etc.

[0026] Among the features defined in the Java Card API there are shareable interfaces, which enable applet interaction .

[0027] A shareable interface defines a set of shared interface methods. These interface methods can be invoked from one Java card context, in particular application or applet context, even if the object implementing them is owned by an applet in another context, e.g., a server applet that provides custom cryptographic algorithms.

[0028] The mechanism of Shareable Interface has visibility only in the Logical Secure Element in which it is defined .

[0029] However, this leads to a waste of resources in case the same applet with Shareable Interface feature is loaded in each LSE, i.e., there is a memory footprint problem.

[0030] The standard solution in the specification ETSI 102 221 does not provide a solution to this problem as it is duplicated the javacard Shareable Interface mechanism to all LSEs.

[0031] Object and summary An obj ect of one or more embodiments is to contribute in providing solutions reducing the memory footprint due to the shareable interfaces while using a set of Logical Secure Elements with a host , in particular a virtual machine architecture .

[0032] According to one or more embodiments , that obj ect is achieved via a Secure Element having the features set forth in the claims that follow .

[0033] One or more embodiments concern a corresponding virtual machine architecture and a corresponding method of managing a Secure Element .

[0034] The claims are an integral part of the technical teaching provided in respect of the embodiments .

[0035] Solutions as described herein include a A Secure Element , operating with a Java Card platform, accessible by at least a host, said Secure Element comprising a set of Logical Secure Elements and a set of Shareable Interfaces applets , said Secure Element comprising a further Logical Secure Element which is an administrative Logical Secure Element configured to perform administrative commands , said administrative Logical Secure Element further storing all the Shareable Interface applets shared by Logical Secure Elements of said set of Logical Secure Elements , said Secure Element comprising one or more stored client applet within one or more of said Logical Secure Element in said set of Logical Secure Elements configured to , when requesting a service from a Shareable Interface applet , perform first search of said Shareable Interface applet in the Logical Secure Element storing said client applet , then a further search in the administrative Logical Secure Element i f said Shareable Interface applet is not found in said Logical Secure Element storing said client applet . In various embodiments , said Secure Element comprises a method which argument is an Application identi fier of the Shareable Interface applet , of the Logical Secure Element itsel f , said client applet performing said search operations by said method which is configured to search first the Shareable Interface applet in the Logical Secure Element storing said client applet , then in the administrative Logical Secure Element i f said Shareable Interface applet is not found in the Logical Secure Element storing said client applet .

[0036] In various embodiments , at least a Logical Secure Element in said set of Logical Secure Elements is configured to define a subset of applets within said Logical Secure Element , which are forbidden to access services within said administrative Logical Secure Element .

[0037] In various embodiments , in said administrative Logical Secure Element configured to perform administrative commands , and in which is uploaded a shared Java Card package , said administrative commands performing operations of extradition of instances of applications in said shared Java Card package in other Logical Secure Elements in said set of Logical Secure Elements and managing said application instances in said package and extradited,

[0038] Solutions as described herein refer also to a virtual machine architecture comprising a set of guest virtual machines supervised by a hypervisor running on a host , on which respective instances of a guest operative system, in particular Android operative system, are executed, said architecture comprising at least a Secure Element accessible by said set of virtual machines according to any of claims 1 to 5 .

[0039] Solutions as described herein refer also to a method for operating a Secure Element comprising a set of Logical Secure Elements and a set of Shareable Interfaces applets in said Secure Element , providing in said Secure Element a further Logical Secure Element which is an administrative Logical Secure Element , the method comprising performing at the administrative Logical Secure Element administrative commands , uploading a shared Java Card package in said administrative Logical Secure Element , said administrative commands performing operations of extradition of instances of applications in said shared Java Card package in other Logical Secure Elements in said set , managing said application instances in said package and extradited, further storing in said Secure Element stored one or more client applets within one or more of said Logical Secure Element which, when requesting a service from a Shareable Interface applet , perform first search of said Shareable Interface applet in the Logical Secure Element storing said client applet , then a further search in the administrative Logical Secure Element i f said Shareable Interface applet is not found in the other Logical Secure Element .

[0040] Solutions as described herein refer also to a method for operating a Secure Element according to embodiments .

[0041] Solutions as described herein facilitate maintaining a low memory footprint in the LSEs .

[0042] Brief description of the figures

[0043] One or more embodiments will now be described, by way of example only, with reference to the annexed figures , wherein :

[0044] - Figure 1 has been described in the foregoing;

[0045] Figure 2 , shows schematically Logical Secure Elements in Secure Element operating in a virtual machine architecture , in a first configuration;

[0046] Figure 3 , shows schematically Logical Secure Elements in Secure Element operating in a virtual machine architecture , in a second configuration;

[0047] Figure 4 shows schematically Logical Secure Elements in Secure Element operating in a virtual machine architecture , in a third configuration;

[0048] - Figure 5 shows schematically a Secure Elements with shareable interface according to an embodiment of the solution here described .

[0049] Corresponding numerals and symbols in the di f ferent figures generally refer to corresponding parts unless otherwise indicated .

[0050] The figures are drawn to clearly illustrate the relevant aspects of the embodiments and are not necessarily drawn to scale .

[0051] The edges of features drawn in the figures do not necessarily indicate the termination of the extent of the feature .

[0052] Detailed description

[0053] In the ensuing description one or more speci fic details are illustrated, aimed at providing an in-depth understanding of examples of embodiments of this description . The embodiments may be obtained without one or more of the speci fic details , or with other methods , components , materials , etc . In other cases , known structures , materials , or operations are not illustrated or described in detail so that certain aspects of embodiments will not be obscured .

[0054] Reference to "an embodiment" or "one embodiment" in the framework of the present description is intended to indicate that a particular configuration, structure , or characteristic described in relation to the embodiment is comprised in at least one embodiment . Hence , phrases such as " in an embodiment" or " in one embodiment" that may be present in one or more points of the present description do not necessarily refer to one and the same embodiment .

[0055] Moreover, particular conf igurations , structures , or characteristics may be combined in any adequate way in one or more embodiments .

[0056] The headings / ref erences used herein are provided merely for convenience and hence do not define the extent of protection or the scope of the embodiments .

[0057] For simplicity and ease of explanation, throughout this description, and unless the context indicates otherwise , like parts or elements are indicated in the various figures with like reference signs , and a corresponding description will not be repeated for each and every figure .

[0058] With reference to figure 2 , the solution here described provides a solution providing in the Secure Element 14 , which is accessible by a host , by way of example the virtual machine architecture 10 of figure 1 a set of Logical Secure Elements , 141 , 142i...l 42n. Such set of Logical Secure Elements , 141 , 142i...l 42ncomprises an administrative logical Element 141 , while the other Logical Secure Elements are Operational Logical Secure Elements 142i...l 42n.

[0059] According to the solution here described the administrative logical Element 141 is configured to perform administrative commands . Also in such administrative logical Element 141 a shared Java Card package is uploaded ( indicated with 143 in figure 3 ) having instances extradited in the other Operational Logical Secure Elements 142i...l 42n. In this context , the abovementioned shared package 143 is a package comprising the executable code of the applications , in particular the ELF .

[0060] The administrative logical Element 141 has the same isolation properties as the other Operational Logical Secure Elements 142i...l42n, i.e. the administrative logical Element 141 acts and is handled by the terminal / host 11 like a separate Secure Element. However, each Operational Logical Secure Element

[0061] 142i...l42nalso operates logically independently from the others, as the Logical Secure Element defined in the Specification 102.221. All Logical Secure Elements, 141,

[0062] 1421...142nare thus accessed through respective Logical Secure Interface (LSI) , not shown in Figure 2.

[0063] The administrative logical Element 141 however as mentioned is configured to perform, i.e., execute, a set of administrative commands, in particular GlobalPlat form commands, which allow it to overcome the logical barrier defined between the Logical Secure Elements through the access through the LSI.

[0064] In particular, such set of administrative commands comprises the following three commands: a first command to perform the extradition application instances from said administrative Logical Secure Element 141 to the other Logical Secure Elements,

[0065] 1421...142n; this command may correspond to INSTALL [for extradition] such as defined in GlobalPlat form Card Specification 2.3.1; a second command for managing an upgrade on such package 143 in the administrative Logical Secure Element 141 having instances in other Logical Secure Elements

[0066] 1421...142n, i.e. for managing an upgrade of the ELF; this command may correspond to MANAGE ELF UPGRADE as per GlobalPlat form Executable Load File Upgrade 1.1; a third command for deleting said package in said administrative Logical Secure Element 141 and the corresponding application instances in said other Logical Secure Elements 142i...l42n. This also may be in the form of DELETE (object and related object) in GlobalPlat f orm Card Specification 2.3.1 (specifically in paragraph 5.2.1.2 and 11.2.2.2) . To this regard the Global Platform command DELETE can be performed on a package with option P2=0x80 which means: Delete object and related object. In this way, not only the package but also all Applications instantiated from it, are deleted .

[0067] Thus, this performs deletion of a shared package which delete also all the instances in all Logical Secure Elements 141, 142i...l42n, i.e. including the administrative Logical Secure Element 141.

[0068] The administrative Logical Secure Element 141 is then configured to operate the same other operations (e.g., SELECT, GET STATUS, etc.) as defined by the ETSI specification, i.e., its visibility is limited to its context (and not includes the other LSE) .

[0069] According to embodiment of the solution here described, the administrative Logical Secure Element 141 is the first Logical Secure Element installed on the Secure Element 14, and it is used to configure all the other LSEs as better explained with reference to figures 2-4.

[0070] Each LSE 141, 142i...l42nis associated with a Security Domain Root (LSE-SDR) 141S. As known, the Security Domain is an application which is installed at the beginning in the SE, or LSE in this case. While the Issuer Security Domain (ISD) manages the card content with respect to the issuer, in this case the LSE-SDR is the only entity in the LSEs to have a unique Application Identifier, e.g. OxAOOOOOOOOOl , indicated with 144, in figure 2, which allows the the administrative Logical Secure Element 141 to correctly extradite applications. LSE-SDR 141s are hidden by the high-level, or first level, of the operative systems 13i because the such first level only communicate with well-known AID application, i.e. applications with AID which are already known to the HAL, thus when a high level call from an Android application is managed by the corresponding HAL, the related AID is referenced.

[0071] LSEs-SDR 141a are used for Card Content Management.

[0072] Thus, the LSE-SDR 141s are not used by the guest operating systems 13i since such guest operating systems 13i communicate only first level applications, i.e., applet with an AID known to the first level. The unique AID 144 is an AID specifically defined for the operation of the administrative Logical Secure Element 141, not recognized by the first level of guest operating systems 13i .

[0073] The LSE-SDR 141s have a unique application identifier 144, since they are used to operate card content management of the Logical Secure Element 141,

[0074] 142.

[0075] In figure 2 it is shown as mentioned a first configuration of the Secure Element 14, e.g., an eUICC, associated to the host 11 and accessed by the virtual machines 131...135, which comprises the set of LSEs 141, 12, in a first install operation Til is installed an LSE_SDR IIS. In this case is used a conventional INSTALL [FOR INSTALL] GlobalPlat f orm command. Then a second operation of install for extradition T12 is performed inserting Instances of the LSE-SDR IIS in each of the n operational LSE, 142i...l42n.

[0076] Then, as shown in figure 3, a shared package, 143, is installed (T21) in the administrative LSE 141 by the host 11, e.g., an ELF, 143 installed, which instances are then extradited T22 in the other LSE 142i...l42n, using the unique AID 144 to access the respective LSE-SDR for managing the card (or SE) content.

[0077] In figure 4, it is shown that the shared package

[0078] 143 in the Administrative LSE 141 performs an upgrade of the ELF interacting T31 with LSE_SDR Administrative LSE 141 which then manages to apply the upgrading steps, defined for instance by GP 2.3 Arnd H spec, T32 to all the other LSE_SDR of LSEs 142 using the unique AID 144 to access the respective LSE-SDR for managing the card (or SE) content.

[0079] So it is managed the ELF upgrade which effect is reflected on all applet instances in LSEs 142.

[0080] The deletion, not shown in the figures, of a group of a shared packages deletes all the instances in all LSE 12.

[0081] Thus, in summary, the virtual machine architecture, e.g., 10, here described, comprising a set of guest virtual machines supervised by a hypervisor, e.g., 12 running on a host, e.g. the processor unit 11 or a microcontroller or a computer, on which respective instances of a guest operative system, e.g., 13±, in particular Linux or Android Linux operative system, are executed, such architecture comprising at least a Secure Element, in the example 14, such as a UICC or eUICC or eSE, accessible by said set of virtual machines, said architecture 10 comprising a set of Logical Secure Elements, , e.g., 141, 142i...l42nin said Secure Element 14, comprises among said Logical Secure Elements 141, 142i...l42nan administrative Logical Secure Element 141. Such administrative Logical Secure Element, with respect to the other Logical Secure Element is further configured to perform administrative commands, e.g., operations T12, T31, T32. In the administrative Logical Secure Element 141 is uploaded a shared Java Card package, e.g., an Executable Load File 143, said administrative commands performing operations of extradition, e.g., T21, T22, of instances of applications in said shared Java Card package 143 in other Logical Secure Elements, e.g., 142i...142n, in said set and managing, e.g. operations T32, T31, said application instances in said package 143 and extradited, i.e. the instances of the packages 143 installed by extradition in the other Logical Secure Elements, e.g., 142i...l42n.

[0082] Such operations of extradition comprise installing, e.g., T22, to extradite application instances from said administrative Logical Secure Element, 141 to other Logical Secure Elements, 142i...l42n, in said set, and performing said managing, e.g., T31, T32, comprises managing an upgrade, e.g., ELF UPGRADE, on said package, e.g. ELF 143) , in said administrative Logical Secure Element, 141, having application instances in other Logical Secure Elements 142i...l42n, and deleting said package, e.g., 143 in the administrative Logical Secure Element, 141 and the corresponding application instances in the other Logical Secure Elements, 142i...l42n.

[0083] According to another aspect of the solution the Secure Element, 14, is configured to perform an installation of LSE Security Domain roots, e.g., 141S, i.e. roots of specific Security Domain to operate with the administrative Logical Secure Element, by performing an installation of a LSE Security Domain roots, e.g., 141S, in the administrative Logical Secure Element then performing an installation for extradition of said LSE Security Domain root 141S in other Logical Secure Elements, e.g., 142i...l42n.

[0084] Also each Logical Secure Element, 142i...l42n, is associated with a Security Domain Root, e.g., 141S, with a unique application identifier, e.g., 144, which is not seen by the guest operating systems 13±. In other words, the identifier 144 can be reached even if LSE-SDR 141S is not known by the virtual machine as a first level application. This to allow the administrative Logical Secure Element, 141, to perform administrative operations, in particular, extradition of applications using the LSE Security Domain Root 141S corresponding to said unique application identi fier 144 , said Security Domain Root being configured to perform Card Content Management .

[0085] Then, in figure 5 , the Secure Element 14 it is shown, which comprises the administrative Logical Secure Element 141 and the other Operative Logical Secure Elements , 142i...l 42ncomprises a respective package 143 , for instance the Shared Package , and there are grouped, i . e . stored, all the Shareable Interface applets common between all the LSEs 141 , 142i...l42n, in particular is represented a server applet 148 with a shareable interface , belonging to a set of shareable interface stored in the administrative Logical Secure Element 141 .

[0086] The Logical Secure Element 142i includes a respective package 143i, i . e . , a package providing in general a framework of classes and interfaces for building, communicating with and working with Java Card technology-based applets , these classes and interfaces provide the minimum required functionality for a Java Card envi ronment , and a client applet 146 is shown by way of example , which in such example requests a service accessible through a shareable interface . The Logical Secure Element 142i in figure 1 it shown as comprising a respective local server applet 146i which may or not supply the requested service . Thus the client applet 146 requests a service from a Shareable interface applet , i . e . , searches in the Logical Secure Element 142i itsel f for the server applet 146i .

[0087] According to the method here described, the client applet 146 in the Logical Secure Element 142i is configured to perform a request procedure which comprises a first request Tl , by a lookup method or API , in particular by modi fying the Java Card lookupAID ( ) API or method, here indicated with lookupAID* ( ) , which argument is the Application identifier AID, in the server applet 146i of the Logical Secure Element 142i itself, then the lookupAID* () API is configured, if the request T1 does not obtain the service from the server applet 146i, i.e. differently from what shown in figure 5 the local server applet 146i is not present, to perform a second request T1 of the service to the server applet 148 of the administrative Logical Secure Element 141. As all the server applets 148 with shareable interface are stored in such administrative Logical Secure Element 141, this second request T2 returns the service requested to the client applet 147 even if it not present, differently from what shown in figure 5, in the Operative Logical Secure Element 142i.

[0088] Thus, while the known lookupAID() method of Java Card searches the AID of the server applet ,e.g. 146i, within the current LSE 142i that provides the service and returns it, the lookupAID* () method according the solution is modified and configured to search the AID first in the current Logical Secure Element, e.g., 142i, and then in the administrative Logical Secure Element 141, which stores all the shareable interfaces, the searched shareable interface server applet being represented by the server applet 148.

[0089] In a variant embodiments, a LSE, e.g. 142i...l42nconfigured, when needing a service from a Shareable Interface applet, e.g. 148 to perform a first search in the same Logical Secure Element, e.g. 142i...l42n, then a further search in the administrative Logical Secure Element 141 if no match is found, may be further configured to define a subset of applets 146 within such LSE, e.g. 142i, which are forbidden to access services within the administrative Logical Secure Element 141. In particular, to this end a new API, which for instance may be called getLSE ( ) , may be added, configured to return to server applet the information about the corresponding LSE where the request for a service in a shareable interface was started, i.e., has requested the Shareable Interface service. It is thus up to the logic of the application to decide whether the service can be provided to a specific LSE. The number of the LSE 142i...l42nmay be obtained through the operating system.

[0090] Thus, in summary, as described with reference to figure 5, the Secure Element, e.g., 14, accessible by at least a host 11, for instance a virtual machine architecture, but also any other host exploiting LSEs, said Secure Element, 14, thus comprising a set of Logical Secure Elements, 142i...l42nand a set of Shareable Interfaces, i.e. Shareable Interfaces applets, further provides an administrative Logical Secure Element 141. Such administrative Logical Secure Element, with respect to the set of Logical Secure Elements 142i...l42nis further configured to perform administrative commands, e.g., operations T12, T31, T32. In particular, in the administrative Logical Secure Element 141 is uploaded a shared Java Card package, e.g., an Executable Load File 143, said administrative commands performing operations of extradition, e.g., T21, T22, of instances of applications in said shared Java Card package 143 in the set of Logical Secure Elements, e.g., 142i...l42n, and managing, e.g. operations T32, T31, said application instances in said package 143 and extradited, i.e. the instances of the packages 143 installed by extradition in the other Logical Secure Elements, e.g., 142i...l42n.

[0091] Then, such administrative Logical Secure Element, e.g. 141, further stores, in particular grouped, the Shareable Interface applets, in the example only the one labelled 148 is shown, common between said Logical Secure Elements of said set, e.g., 142i...l42n, such Secure Element 14 comprising stored one or more client applet, e.g., 147, within one or more of said Logical Secure Element of said set, in the example 142i, configured to, when requesting a service from a Shareable Interface applet, in the example the local 146i or the server applet 148 in the administrative LSE 141, perform a first, e.g. Tl, search of said Shareable Interface applet, 146i if locally present, in the other Logical Secure Element, e.g. 142i, storing such client applet, e.g. 147, then a further search, indicated with T2 in figure 5, in the administrative Logical Secure Element 14) if such Shareable Interface applet 146i is not found in the other Logical Secure Element (142i) , i.e. the Shareable Interface applet 148 stored in the administrative Logical Secure Element 141 is found.

[0092] In particular such Secure Element comprises a method, i.e. lookupAID* () , which argument is an Application identifier of the Shareable Interface applet (146i, 148) , 146i of the Logical Secure Element 142i itself, said client applet performing such search operations, e.g. Tl, T2, by such method ( lookupAID () ) which is configured to the lookupAID () API is configured to search first, Tl, the Shareable Interface applet, in the example 146i, in the other Logical Secure Element 142i, i.e. locally, then, T2, in the administrative Logical Secure Element 14) if said Shareable Interface applet 146 is not found in the other Logical Secure Element 142i, i.e. locally. Such lookupAID* () method correspond to a modification of the Java Card lookupAID () method, i.e. they have in common the search Tl, while the second search T2 is added in the modified lookupAID* () method.

[0093] Solutions as described herein, allow to decrease the memory footprint, as there is a central point, the administrative LSE, where are located all the Shareable Interface applets that provides the services. Thus , it is avoided waste of memory in order to manage same Shareable Interface but in multiple LSEs .

[0094] It is possible to group common Shareable Interface applets that provide same services to all LSEs .

[0095] The above is obtained thanks to the introduction of the administrative Logical Secure Element , which introduces a privileged user that can perform administrative commands across all other Logical Secure Elements .

[0096] Without prej udice to the underlying principles , the details and the embodiments may vary, even signi ficantly, with respect to what has been described by way of example only without departing from the scope of the embodiments .

[0097] The whole (virtual machines and hypervisor ) architecture may comprise more than one Secure Element ( for example eUICC and eSE ) , which can be accessed by di f ferent subset of guest operating system running in corresponding virtual machines .

[0098] As mentioned the solution preferably applies to Secure Elements according to the speci fication ETS I TS 102 221 and may use commands within the meaning of GlobalPlat f orm Card Speci fication .

[0099] The solution can be applied to any Secure Element with multiple LSEs which are accessed by a host withing the meaning of the speci fication ETS I TS 102 221 , not necessarily with a virtual machines architecture .

[0100] The extent of protection is determined by the annexed claims .

Claims

CLAIMS1. A Secure Element (14) , operating with a Java Card platform, accessible by at least a host (11) , said Secure Element (14) comprising a set of Logical Secure Elements ( 142i...l42n) and a set of Shareable Interfaces applets , said Secure Element (14) comprising a further Logical Secure Element which is an administrative Logical Secure Element (141) configured to perform administrative commands (T12, T31, T32) , said administrative Logical Secure Element (141) further storing the Shareable Interface applets shared by the Logical Secure Elements (141, 142i...l42n) of said set of Logical Secure Elements (141, 142i...l42n) , said Secure Element comprising one or more stored client applet (147) within one or more of said Logical Secure Element in said set of Logical Secure Elements ( 142i...l42n) configured to, when requesting a service from a Shareable Interface applet (146i, 148) , perform first (Tl) search of said Shareable Interface applet (146i, 148) in the Logical Secure Element (142i) storing said client applet (147) , then a further search (T2) in the administrative Logical Secure Element (141) if said Shareable Interface applet (146i, 148) is not found in said Logical Secure Element (142i) storing said client applet ( 147 ) .

2. A Secure Element according to claim 1, wherein said Secure Element comprises a method ( lookupAID ( ) ) which argument is an Application identifier of the Shareable Interface applet (146i, 148) , 146i of the Logical Secure Element 142i itself, said client applet performing said search operations by said method ( lookupAID () ) which is configured to search first the Shareable Interface applet (146i, 148) in the Logical Secure Element (142i) storing said client applet (147) ,then in the administrative Logical Secure Element (141) if said Shareable Interface applet (146i, 148) is not found in the Logical Secure Element (142i) storing said client applet (147) .

3. A Secure Element according to claim 1 or 2, wherein at least a Logical Secure Element in said set of Logical Secure Elements (141, 142i...l42n) is configured to define a subset of applets (146) within said Logical Secure Element, which are forbidden to access services within said administrative Logical Secure Element (141) .

4. A Secure Element according to any of the previous claims, wherein in said administrative Logical Secure Element (141) configured to perform administrative commands (T12, T31, T32) , and in which is uploaded a shared Java Card package (143) , said administrative commands performing operations of extradition (T21, T22) of instances of applications in said shared Java Card package (143) in other Logical Secure Elements ( 142i...l42n) in said set of Logical Secure Elements (141,142i...l42n) and managing (T32, T31) said application instances in said package and extradited,5. A virtual machine architecture (10) comprising a set of guest virtual machines supervised by a hypervisor (12) running on a host (11) , on which respective instances of a guest operative system (13±) , in particular Android operative system, are executed, said architecture comprising at least a Secure Element (14) accessible by said set of virtual machines according to any of claims 1 to 5.

6. A method for operating a Secure Element (14) comprising a set of Logical Secure Elements (141,142i...l42n) and a set of Shareable Interfaces applets in said Secure Element (14) , providing in said Secure Element (14) a further Logical Secure Element which is an administrativeLogical Secure Element (141) , the method comprising performing at the administrative Logical Secure Element (141) administrative commands (T12, T31, T32) , uploading a shared Java Card package (143) in said administrative Logical Secure Element (141) , said administrative commands performing operations of extradition (T21, T22) of instances of applications in said shared Java Card package (143) in other Logical Secure Elements ( 142i...l42n) in said set, managing (T32, T31) said application instances in said package and extradited, further storing in said Secure Element stored one or more client applets (147) within one or more of said Logical Secure Element ( 142i...l42n) which, when requesting a service from a Shareable Interface applet (146i, 148) , perform first (Tl) search of said Shareable Interface applet (146i, 148) in the Logical Secure Element (142i) storing said client applet (147) , then a further search (T2) in the administrative Logical Secure Element (141) if said Shareable Interface applet (146i, 148) is not found in the other Logical Secure Element (142i) .

7. A method for operating a Secure Element (14) according any to claims 1 to 4.

Images