System and method for running multiple logical secure elements on same secure hardware

Abstract

Techniques for running multiple logical secure elements (LSEs) on the same physical secure element (SE) hardware are described herein. For example, embodiments may include running multiple logical Subscriber Identity Module (SIM) cards on the same physical SIM card or Universal Integrated Circuit Card (UICC). Additionally or alternatively, embodiments may include running other secure element applications and services on the same SE hardware. These techniques allow a mobile device user to access multiple secure services that may originate from different secure service providers (SSPs) using the same SE hardware in a secure manner without integrating multiple physical slots on the mobile device or physically swapping different cards within the same slot.

Description

Technical Field

[0001] The present disclosure generally relates to secure hardware design and implementation. In particular, the present disclosure relates to isolation and switching between multiple logical security elements running on the same secure hardware. Background Art

[0002] Mobile phones and other devices often contain secure elements, such as Subscriber Identity Module (SIM) cards and other forms of smart cards, to provide strong protection against unauthorized access to sensitive data. Secure elements typically include a security chip and dedicated software that can be used for a variety of applications, including payment processing, biometric authentication, and mobile network communications. In many cases, both the secure element chip and software are packaged as a single product and distributed by a security service provider (SSP).

[0003] Many mobile device users wish to use secure elements from different SSPs to access different secure applications and services. One approach to satisfying such users is for the mobile device to include a slot that allows the user to physically remove the secure element chip from the mobile device and insert another secure element chip from a different SSP. For example, a mobile phone may include a card slot that allows the user to quickly switch between different SIM cards. However, physically switching between different secure elements is often inconvenient for the end user, especially if the user frequently changes services. There is also the risk of misplacing and losing a card that is not currently in use.

[0004] In some cases, a mobile device may include multiple embedded security elements and / or expansion slots. SIM card manufacturers and mobile network operators (MNOs) have developed standards for embedded SIM (eSIM) cards and embedded universal integrated circuit cards (eUICCs). These standards define the purpose, format, functions, and associated profiles of eSIM / eUICCs. These components provide interfaces for receiving and responding to network and handheld terminal requests when integrated into a mobile handset. In addition, handset manufacturers may include at least one (usually multiple) physical expansion slots for using multiple removable SIM / UICCs. Integrating more than one physical slot for a SIM card is a huge cost factor for mobile device manufacturers, whether it is an expansion slot or an embedded physical slot. Each additional slot increases the footprint of the security element hardware, thereby taking up valuable space within the mobile device printed circuit board (PCB) and increasing the complexity of the hardware design.

[0005] The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, any approach described in this section should not be construed as qualifying as prior art merely by virtue of its inclusion in this section. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] In the figures of the accompanying drawings, embodiments are illustrated by way of example and not limitation. It should be noted that references to "an embodiment" or "one embodiment" in this disclosure do not necessarily refer to the same embodiment, and they mean at least one. In the drawings:

[0007] Figure 1 illustrates an example system architecture for a mobile device according to some embodiments;

[0008] Figure 2 illustrates an example set of logical security element (LSE) mappings according to some embodiments;

[0009] Figure 3 illustrates an example set of LSEs running on a physical security element (SE) according to some embodiments;

[0010] Figure 4 illustrates an example set of operations for performing a switching operation to change a currently activated LSE within a SE hardware platform according to some embodiments;

[0011] Figure 5 illustrates a set of operations for deriving and applying keys to enforce isolation between LSEs according to some embodiments;

[0012] Figure 6 illustrates an example set of operations for controlling access to an LSE according to some embodiments;

[0013] Figure 7 illustrates an example set of operations for applying an access control policy to an LSE according to some embodiments; and

[0014] Figure 8 A block diagram illustrating a computer system in accordance with one or more embodiments is shown. DETAILED DESCRIPTION

[0015] In the following description, for the purpose of explanation, many specific details are set forth in order to provide a thorough understanding. One or more embodiments may be practiced without these specific details. The features described in one embodiment may be combined with the features described in another embodiment. In some examples, well-known structures and devices are described with reference to block diagrams to avoid unnecessary confusion of the present invention. One or more operations shown in the figures and described herein may be modified, rearranged or omitted together. Accordingly, the specific order of operations shown in the figures and examples should not be interpreted as limiting the scope of one or more embodiments.

[0016] 1. General Overview

[0017] This article describes techniques for running multiple logical security elements (LSE) on the same physical security element (SE) hardware. For example, an embodiment may include running multiple logical subscriber identity module (SIM) cards on the same physical SIM card or universal integrated circuit card (UICC). Additionally or alternatively, an embodiment may include running other security element applications and services on the same SE hardware. These technologies allow mobile device users to use the same SE hardware to access multiple security services that may originate from different security service providers (SSPs) in a secure manner without integrating multiple physical slots on the mobile device or physically exchanging different cards in the same slot. Therefore, the space occupied and cost of the security element hardware in the mobile device can be significantly reduced while maintaining or increasing the number of security services accessible to the mobile device user.

[0018] Virtualizing multiple security elements on a single SE hardware platform is complicated by several factors. Compared with the main mobile processors in modern smartphones and the central processing unit (CPU) in portable computers, the hardware capabilities of SE hardware platforms are generally limited. For example, SE hardware platforms generally lack a memory management unit (MMU) or have a reduced version of the memory management unit. In addition, SE hardware platforms generally contain much slower processors to minimize power consumption and manufacturing costs, and may not be able to execute specialized instructions in the CPU instruction set architecture (ISA) that relies on large scalable resources. Therefore, it is generally not feasible to deploy virtualization solutions such as hypervisors on SE hardware platforms. Such virtualization solutions may also fail to maintain sufficient security certification levels expected by SE hardware platforms.

[0019] Embodiments herein include a firmware component that is executed on a SE hardware platform to efficiently route messages from a device host to a target LSE. The firmware component can process messages in a manner that enforces security and authentication levels for multiple LSEs running on the same SE hardware platform without the need to integrate more powerful hardware, such as a full-size MMU and a high-performance processor. Therefore, the cost and power consumption of SE hardware within a mobile device can be minimized.

[0020] In some embodiments, the firmware component accesses the LSE mapping table when routing a message to a target LSE. The LSE mapping table can store an identifier for each corresponding LSE and a mapping to hardware resources within the SE hardware platform that the corresponding LSE has access to. For example, the LSE mapping table can include a mapping to a memory segment storing LSE-specific code and data. When a message targeting an LSE is received, the firmware can reconfigure a switch register (SR) and reference an entry to be used in the LSE mapping table. The SE software stack code (SESS code) can then be executed using the entry specified by the SR to retrieve the address of the resource that the SESS code has access to from the LSE mapping table to process the message. The SESS code can be shared between LSEs, allowing the SE hardware to reuse the same SE software stack to efficiently run multiple LSEs.

[0021] While the SESS code may be common to multiple LSEs, the SESS data mapped to a given LSE may be unique. The SESS data may include application code and configuration that affects the runtime behavior of the LSE, which may also be unique to each LSE. For example, one LSE may host a network access application, and another LSE may run a JavaCard application. Additionally or alternatively, the LSE may run and host other security applications, which may vary depending on the type of security service and / or the SSP associated with the application.

[0022] The SE hardware platform may enforce security constraints on the hardware to maintain confidentiality and integrity isolation between LSEs running on the same hardware platform. In some embodiments, the mapping table contains a set of cryptographic keys that are used to encrypt and decrypt content stored in or read from a memory associated with the LSE. The cryptographic keys of the LSE may be derived based on one or more master keys stored by the SE hardware, an identifier associated with the LSE, the type of memory storing the encrypted data of the LSE, and / or other LSE properties.

[0023] In some embodiments, the firmware component implements access control that limits which entities can access a given LSE. When an inbound message attempts to switch to or otherwise access an LSE, the firmware component can determine whether the message is authorized to trigger the requested operation. For example, the firmware component can use a public key or a shared secret to verify the signature of the received message. If the message is successfully verified, the firmware protocol can trigger the switch and / or other requested operations. Otherwise, the firmware component can deny the operation.

[0024] Additionally or alternatively, access control policies may limit the behavior of LSEs running on SE hardware. In some embodiments, access control policies may constrain the load of LSEs on SE platform hardware and / or prioritize LSE access. For example, access control may define usage thresholds associated with a given LSE, such as maximum threshold memory, processor, and / or peripheral utilization. As another example, access control may limit the active time of an LSE to a threshold duration. Access control may be applied individually or to groups of LSEs. In the latter scenario, LSEs may be grouped by common attributes, including the type and / or SSP of (one or more) SE applications associated with the LSE.

[0025] One or more embodiments described in this specification and / or claimed may not be included in this general summary.

[0026] 2. System architecture

[0027] Figure 1 An example system architecture of a mobile device according to some embodiments is illustrated. Figure 1 As shown in FIG. 1 , the system architecture of the mobile device 100 includes a secure element (SE) hardware 102 and a device host hardware 128. The SE hardware 100 includes a SE processor 104, a hardware (HW)-based cryptographic module 106, a logical secure element (LSE) 108a-n, a SE software stack 110, and a SE memory 116. The device host hardware 128 includes a SE interface 130, a modem 132, a near field communication (NFC) controller 134, a host memory 136, and a host processor 140. The device host hardware can run a host application 138. The mobile device may include, for example, Figure 1 More or fewer components than those shown may be required, depending on the specific device architecture.

[0028] In some embodiments, the mobile device 100 is a mobile handheld terminal, such as a smart phone, which is configured to connect to one or more data communication networks, which may include wired and / or wireless data communication networks. Example data communication networks include Global System for Mobile Communications (GSM), Code Division Multiple Access (CDMA), Universal Mobile Telecommunications System (UMTS), Long Term Evolution (LTE), General Packet Radio Service (GPRS), Universal Mobile Telecommunications System (UMTS), Broadband Global Area Network (BGAN), Wireless Local Area Network (WLAN), Ethernet, etc. In other embodiments, the mobile device 100 may be a different device. For example, the mobile device 100 may be a tablet computer, a laptop computer, or a desktop computer. As another example, the mobile device 100 may be a complex smart card, such as a credit card or identity (ID) card with an embedded security element. As another example, the mobile device 100 may be a complex system, such as a networked car, which has an embedded security element for (a) connection, (b) vehicle-to-vehicle and / or vehicle-to-infrastructure monitoring, and / or (c) maintenance and / or service subscription.

[0029] In some embodiments, SE hardware 100 is a microprocessor-based chip that includes hardware components for protecting secure data from unauthorized access and running secure applications. SE hardware 100 may include a smart card, such as a universal integrated circuit card (UICC), which is a smart card that complies with the specifications defined by the European Telecommunications Standards Institute ETSI Smart Card Platform Project. A subscriber identity module (SIM) card is an example of a UICC. Additionally or alternatively, SE hardware 100 may include other types of integrated circuit cards (ICCs) and tamper-resistant security chips for controlling access to secure resources.

[0030] In some embodiments, the SE processor 104 is a microprocessor for executing the SE platform runtime environment and SE applications. An example SE platform runtime environment is the Java Card Runtime Environment (JCRE). The JCRE provides a lightweight version of the Java Runtime Environment (JRE) that is tailored for smart cards and other tamper-resistant security chips to allow these SE hardware platforms to host SE applications using Java technology.

[0031] The SE application hosted in the JCRE can be referred to as a Java Card applet. The JCRE includes a firewall mechanism that isolates different applets on the smart card, and a sharing mechanism that allows applets to explicitly provide objects to other applets. The JCRE also includes a Java Card virtual machine (JCVM) that runs bytecodes, which are generated using a coding mode different from that of the complete JRE. In general, the coding mode of the JCRE reduces the memory footprint of the application to optimize the application to be executed by the SE hardware 102, which typically includes many more constraints than the host hardware 128. For example, the size of the SE memory 116 may be much smaller than the host memory 136, and the speed of the SE processor 104 may be much slower than the host processor 140. In addition, the native instruction set architecture (ISA) of the SE processor 104 may be smaller or otherwise different than the ISA of the host processor 140. An optimization technique that takes these constraints into account is to divide the code of the application into packages that are smaller than a size threshold and limit the packages that are available in the environment that are constructed by the programming language. Although some examples described herein are with respect to JCRE, embodiments described herein may be implemented by other runtime environments executing on smart cards and other tamper-resistant chips.

[0032] The SE hardware 102 may include a HW-based cryptographic module 106 for encrypting and decrypting data stored by the secure element. In some embodiments, the HW-based cryptographic module 106 is implemented as part of the instruction set of the SE processor 104, thereby allowing the processor to encrypt and decrypt data without relying on software algorithms to perform encryption. In other embodiments, the HW-based cryptographic module 106 may be located outside the processor. For example, the HW-based cryptographic 106 may be an Advanced Encryption Standard (AES) chip or cryptographic accelerator located on the bus between the SE processor 104 and the SE memory 116.

[0033] The SE hardware 102 runs multiple LSEs 108a-n, which, from the perspective of the mobile device user, can operate as if multiple security element chips were installed in the mobile device 100. For example, the LSEs 108a-n can operate as if multiple embedded and / or removable SIM cards are currently operated in the mobile device 100. Therefore, the LSEs 108a-n can correspond to virtual SIM cards and / or other tamper-proof chips that are shared and run from the same SE hardware component. The SE hardware 102 and / or the firmware running therein can enforce isolation between different LSEs to prevent one LSE from accessing the applets and code of another LSE. The isolation mechanism can be separate and different from the firewall mechanism of the JCRE mentioned above. The firewall mechanism can be applied to a given LSE to maintain the separation between different applets installed on the same LSE. The isolation mechanism can be implemented at a lower level to maintain isolation between different LSEs, and each LSE can be configured with its own firewall.

[0034] SE software stack (SESS) 110 includes a collection of components for executing SE applications. SESS 110 may include code for executing applet and providing runtime environment for applet, referred to herein as SESS code. In some embodiments, SESS 110 includes protocol handler firmware 112 and access control module 114. Additionally or alternatively, SESS 110 may include other components, such as JCVM, Java Card API (JCAPI) code and / or other components of JCRE for hosting Java Card applications. In some embodiments, SESS code is different from the code of applet and LSE application. SESS code provides a program and runtime environment for executing LSE application code. For example, SESS code can provide a virtual machine for running LSE applet. Additionally or alternatively, SESS code can manage access to SE hardware components (such as cryptographic accelerators and memory segments), and / or perform memory management operations, including allocating runtime memory for applet currently running in the runtime environment. SESS code can be public for LSE 108a-n to optimize size and reduce processing overhead.

[0035] In some embodiments, the protocol handler firmware 112 is a low-level firmware that is used by the SESS code to manage operations for the LSEs 108a-n. In the case of a Java Card-based secure element, the protocol handler firmware 112 can be part of the JCRE. However, depending on the specific implementation, the firmware can be integrated into other runtime environments or integrated in a standalone manner.

[0036] In some embodiments, the protocol handler firmware 112 manages the routing of messages received from the device host hardware 128 to the target LSE. When routing messages, the protocol handler firmware 112 can trigger a switching operation to change the LSE that is currently active and running on the SE hardware 102. As further described below, the switching operation can include reassigning global addresses in the switching register. The switching operation can be performed by reconfiguring the SESS code without requiring extensive modifications.

[0037] The access control module 114 provides authentication to prevent unauthorized entities from triggering changes between LSEs and / or other operations to access LSE data. The access control module 114 may be a component of the protocol handler firmware 112, or may be a separate component, depending on the particular implementation. The access control module 114 may block the requested operation if it fails to successfully verify that the message originated from an entity authorized to trigger the requested operation.

[0038] In some embodiments, SE memory 116 securely stores data of LSEs 108a-n. SE memory 116 may include one or more types of volatile and / or non-volatile storage devices, such as read-only memory (ROM) 118, random access memory (RAM) 120, non-volatile memory (NVM) 124, and one-time programmable (OTP) memory 126. SE memory 116 may store data in an encrypted format. As further described below, encryption schemes (such as encryption algorithms and / or key locations) may differ between different LSEs to provide data integrity and isolation.

[0039] In some embodiments, the handover commands and other messages originate from the device host hardware 128. For example, the messages may be received wirelessly via the modem 132 and / or the NFC controller 134. The messages may be routed to the SE hardware 102 via the SE interface 130. The SE interface 130 may convert the wirelessly received messages into a format usable by the protocol handler firmware 112. Additionally or alternatively, the SE interface may include a bus or other communication system for transmitting messages from the device host hardware 128 to the SE hardware 102.

[0040] In some embodiments, modem 132 is a mobile broadband modem that sends and receives messages via a mobile broadband connection. For example, an operator (including a mobile network operator (MNO) and a mobile virtual network operator (MVNO)) can wirelessly send network messages to mobile phone 100 via a cellular network through modem 132. Different LSEs can be targeted based on the mobile phone operator that sends the message. SE hardware 100 can support multiple virtual SIM cards from different mobile phone operators. Additionally or alternatively, other messages received wirelessly by modem 132 can be targeted at different types of LSEs. Example LSE applications can include payment processing, biometric authentication, identity management, and mobile network communications.

[0041] In some embodiments, the NFC controller 134 receives near-field wireless messages from an external device. NFC communications can transmit data through inductive coupling between an antenna in the NFC controller 134 and an external device (when placed within a threshold distance). NFC messages can trigger operations in the LSE. For example, a payment terminal can generate an NFC message to extract credit card information and / or other data during a transaction. The target LSE can securely store the financial information of the mobile device user and include one or more applets for processing secure transactions initiated using a payment terminal. NFC messages can trigger other operations that may vary depending on the type of LSE application and the SSP associated with the application.

[0042] Additionally or alternatively, the device host hardware 128 may include other components for receiving messages through a wired or wireless interface. For example, the device host hardware 128 may include a Bluetooth module, a Zigbee chip, a Wi-Fi card, an infrared receiver, a universal serial bus (USB) controller, and / or a serial communication interface. Messages received through such hardware components may be used as external triggers to initiate operations to switch between LSEs 108a-n and access resources mapped to the LSEs.

[0043] The device host hardware 128 also includes a host memory 136 and a host processor 140 for executing host applications 138. For example, a smartphone may include a mobile processor and RAM for executing a mobile operating system and mobile phone applications. The processor 140 and the host memory 136 may be physically separated from the SE hardware 102 to prevent attacks when the security of the mobile device 100 is compromised. The SE hardware 102 may prevent the processor 140 from accessing secure data stored in the SE memory 116. Requests to access data may be routed through the protocol handler firmware 112.

[0044] In other embodiments, the device host hardware 128 may include more or fewer components. For example, some devices (such as smart credit cards and corporate badges) may not include a mobile processor, CPU, or memory outside the secure element. These devices may not execute applications other than applets hosted by the SE hardware 102. Therefore, the architecture of the device host hardware 128 may vary depending on the specific type of device in which the SE hardware 102 is integrated.

[0045] 3. Logical Security Element Mapping and Configuration

[0046] In some embodiments, the SE hardware 102 stores a mapping table that establishes a unique mapping for each of the LSEs 108a-n. The mapping for a given LSE can be used to identify attributes associated with the LSE and resources that have been bound to the LSE. For example, the mapping for a given LSE can identify cryptographic keys, global structures, and memory segments that are bound to the LSE. The protocol handler firmware 112 can access the mapping table to route messages from the device host to the target LSE.

[0047] Figure 2 An example set of LSE mappings according to some embodiments is illustrated. LSE mapping table 206 includes n table entries corresponding to n different LSEs, including table entry 208a and table entry 208n. LSE mapping table 206 can be allocated from SE memory 116 such as in NVM. NVM is a memory that can retain stored information even if power is removed. Examples of NVM include flash memory devices and electrically erasable programmable read-only memory (EEPROM).

[0048] Table entry 208a establishes a unique mapping for LSE 108a between LSE identification data 210a, global data registry 212a, and LSE key 214a. Table entry 208n establishes a unique mapping for LSE 108n between LSE identification data 210n, global data registry 212n, and LSE key 214n. The number of entries in the table may vary depending on the number of LSEs installed on SE hardware 102. In some embodiments, the number of LSEs and the number of corresponding entries in the table may be limited to a maximum threshold, which may be selected based on available hardware resources (such as the size of SE memory 116).

[0049] The LSE identification data 210a-n includes one or more identifiers for the LSEs. In some embodiments, the LSE identification data for a given LSE includes the following two identifier fields: (a) an ID field that depends on the protocol that allows the firmware component to select the given LSE, and (b) a UUID field that stores a universally unique identifier (UUID). The ID value assigned to the LSE may correspond to its position #n in the mapping table, or may be some other value assigned by the protocol handler firmware 112. For example, LSE #1 may correspond to the LSE mapped to the first entry in the mapping table, LSE #2 to the second entry, and LSE #n to the nth entry. LSE #n may have the same identifier on different devices.

[0050] The UUID value is a globally unique identifier, so that an LSE#n will not have the same UUID on different devices. The UUID may be generated based on a timestamp, a namespace identifier associated with the LSE, an identifier associated with the SE hardware 102, and / or other attributes associated with the LSE. For example, the UUID may be generated by applying a hash algorithm, such as the Secure Hash Algorithm (SHA) or the Message Digest Algorithm 5 (MD5), to a combination of one or more attributes that are unique to the combination of the LSE and SE hardware on which it is running. However, the attributes and algorithms used to generate the UUID value may vary depending on the particular implementation.

[0051] In some embodiments, global data registers 212a-n correspond to root global structures stored in NVM that can be dereferenced by SESS code 202 to access internal registers and states associated with the LSE. The LSE's global data registers can define memory boundaries and global states that persist across SE hardware 102 reset and power outage events. The global data structures can store or reference various data of the LSE, including:

[0052] A collection of memory segment entries bound to the LSE. A memory segment entry may identify the type of memory (e.g., ROM, OTP, NVM, RAM), a memory address identifying the start location of the memory segment, and the length of the memory segment.

[0053] Identify user customized and configured personalization data associated with the LSE.

[0054] - Memory management data, such as stack and frame pointers, which can be dereferenced to access parameters, local variables and other data used to execute one or more LSE applets.

[0055] • Application management data, such as a secure channel registry and an installed applications table, indicating which LSE applications (eg, Java Card applets) are installed on the LSE.

[0056] LSE keys 214a-n are a set of unique cryptographic keys bound to a device and an LSE. The value in the table entry may include the set of keys itself or a reference (e.g., memory type, address, and length) used to access the key. Different sets of keys may be bound to different LSEs to protect sensitive data and isolate LSEs from each other.

[0057] In some embodiments, the LSE keys for a given LSE include the following two fields: (a) an encryption key field for storing or referencing a cryptographic key bound to the LSE and used to encrypt and decrypt data of the LSE, and (b) an access verification key field for storing or referencing a public key or shared secret used to verify an entity attempting to access the LSE. Techniques for deriving and applying keys to enforce isolation and restrict access to the LSE are further described below in Section 5 entitled Isolation Enforcement and Section 6 entitled Access Control: Message Verification.

[0058] The SESS code 202 may dereference the root global structure to access the SESS data 216 bound to the LSE to process the inbound message 200 received via the I / O interface 218. As previously described, the SESS code 202 may be common to the LSEs 108a-n. However, the behavior of a given LSE may be unique based on the global data registry mapped to the LSE, the associated configuration of each LSE of the SESS code 202, and the specific application (e.g., JavaCard applet) running by the LSE.

[0059] In some embodiments, the switching memory region 204 is a dedicated NVM and / or RAM memory region that hosts the address of the current mapping table entry. The SESS code 202 can read the values ​​stored in the switching memory region 204 to retrieve the currently active mapping table and access the associated global data register. The switching memory region 204 can be used to efficiently switch between LSEs, as further described in Section 4 below entitled "Switching Processing".

[0060] Figure 3An example set of LSEs running on physical security elements according to some embodiments is illustrated. As shown, LSEs 300a-n are configured as different virtual SE chips. For example, LSE 300a operates as a virtual SIM card 302, and LSE 300b operates as a virtual SIM card 304. Each LSE may behave as if the mobile phone 100 has a SIM card from a different MNO embedded in the device or inserted into an expansion slot. However, each LSE can run from the same physical security element, which can be a SIM card, UICC, or other type of smart card.

[0061] To operate as a virtual SIM card, LSE 300a can be mapped to SIM profile data 310 and (one or more) SIM applets 310, and LSE 300b can be mapped to SIM profile data 312 and (one or more) SIM applets 312. The SIM profile data may include subscription credentials and / or other data to authenticate to the MNO and connect to the operator network. For example, the profile data may include an International Mobile Subscriber Identity (IMSI) number and a secret key to authenticate the virtual SIM card to the MNO according to an authentication and key negotiation protocol. However, the authentication mechanisms and profile data of different mobile operator networks and MNOs may be different. The SIM applets may perform various SIM-specific functions, such as connecting to the operator network, logging events (e.g., recent calls, call failures, etc.), and switching between available cellular networks.

[0062] With multiple virtual SIM cards, the mobile device 100 can provide services from multiple MNOs without installing multiple physical SIM cards. A mobile phone user can switch between different virtual SIM cards to connect to a cellular network, which may be advantageous when the coverage of a carrier network changes. For example, a mobile phone can select and change carrier networks based on which network provides stronger coverage within the geographic area where the user is currently located.

[0063] Additionally or alternatively, the LSE may represent other types of virtual smart cards. For example, the LSE 300c is used as a virtual secure payment chip 306. The LSE 300c may be mapped to payment service data 314 and (one or more) payment service applets 322. The payment service data 314 may include tokenized credit card information, billing address information, security codes, secret keys (e.g., token keys), and / or other information for performing payment transactions. The (one or more) payment service applets 322 may perform operations associated with performing payment transactions, such as connecting to a token service provider (TSP) to replace sensitive credit card numbers with token keys, initiating transactions using a payment service terminal, and tracking historical transactions.

[0064] Other LSEs including LSE 300n may similarly function as virtual smart cards. Each virtual smart card may be associated with secure service data and one or more service applets that affect the behavior of the LSE. For example, virtual smart card 308 is associated with secure service data 316 and (one or more) service applets 324 to execute one or more applications. Example applications may include payment processing, biometric authentication, identity management, mobile network communications, etc.

[0065] The SE hardware platform 326 may be a single secure element that hosts the LSE applications 300a-n. The SE hardware platform 326 may include SE hardware resources 102, such as Figure 1 . The LSEs 300a-n may share one or more of the hardware resources, including the SE processor 104, the hardware-based cryptographic module 106 (e.g., a cryptographic accelerator), and the SE memory 116. In addition, as previously described, the SESS code associated with the SE software stack 110 may be common to the LSEs. Thus, the shared resources may include, in whole or in part, a runtime environment (e.g., JCRE), a virtual machine (e.g., JCVM), a programming language API (e.g., a Java API), and / or a programming language library. One or more of these components may be customized for a particular LSE or a subset of LSEs. In this case, the SESS code may contain only the common portions across the LSEs, while the customized portions of the components are stored separately per LSE or per LSE group.

[0066] 4. Switching Process

[0067] In some embodiments, message 200 may trigger a switching operation that changes the currently active LSE on the SE hardware platform. Message 200 may explicitly request a switch, or protocol handler firmware 112 may infer a switch command from the message. For example, the operating system of the mobile phone may send an explicit command to protocol handler firmware 112 to switch SIM LSEs in response to receiving a request to change operators from a user. As another example, protocol handler firmware 112 may receive a message requesting to initiate a payment transaction with a payment security service via NFC controller 134. Protocol handler firmware 112 may infer a switch command based on the message to change the active LSE to LSE 300c.

[0068] In some embodiments, the protocol handler firmware 112 manages the LSE currently activated on the SE hardware 102. In particular, the protocol handler firmware 112 can maintain and update a state that identifies the LSE that is currently activated and configured to receive messages. The state information can correspond to an LSE index in a mapping table 206 that can be stored in the switching memory area 204. The protocol handler firmware 112 can modify the state information stored in the switching memory area 204, including the index, to switch the currently activated LSE.

[0069] As previously described, the protocol handler firmware 112 may redirect a message 200 received via the device host hardware 128 to a target LSE. If the received message is for an LSE that has been selected and configured to receive messages, the protocol handler firmware may forward the message to the SESS code 202 without performing a switching operation. However, if the received message is for another LSE, the protocol handler firmware 112 may switch the currently active LSE before forwarding the message.

[0070] Figure 4 An example set of operations for performing a switching operation to change a currently activated LSE within a SE hardware platform is illustrated in accordance with some embodiments. Figure 4 One or more operations shown in may be modified, rearranged or omitted altogether. Accordingly, Figure 4 The particular order of operations shown in the drawings should not be construed as limiting the scope of one or more embodiments.

[0071] refer to Figure 4 In operation 402, the protocol handler firmware 112 receives a message for a currently inactive LSE. Various protocols may be used to exchange messages between the device host and the SE hardware. The protocol handler firmware 112 may intercept messages from various interfaces, such as interfaces between the SE hardware and the modem 132, the NFC controller 134, and the host processor 140. The protocol handler firmware 112 may act as a master handler for the I / O interface, interpreting the I / O signals according to one or more protocols and inferring which LSE the message is for. The protocol handler firmware 112 may also filter messages from interfaces that are not intended for the LSE or are not authorized to trigger operations on the LSE.

[0072] In operation 404, the protocol handler firmware 112 determines which LSE the message is intended for. In some embodiments, the protocol handler firmware 112 may infer or deduce the target LSE based on the I / O interface that received the message. For example, the I / O interface 218 may include an inter-integrated circuit (I / O) interface. 2 C) Interface: contactless International Organization for Standardization (ISO) 14443 interface. 2The ISO 1443 interface includes a serial communication bus and protocol for transmitting data. The ISO 1443 interface defines a transmission protocol for transmitting messages via a contactless integrated circuit card (also known as a proximity card). The protocol handler firmware 112 can infer the 2 The message received through the contactless interface is for one LSE (e.g., LSE#1), and the message received through the contactless interface is for a different LSE (e.g., LSE#2). Additionally or alternatively, the I / O interface 218 may include other forms of I / O interfaces that may include different protocols and circuit systems, such as other types of contactless integrated circuit cards, wireless communication interfaces, and bus interfaces. For these interfaces, the protocol handler firmware 112 may similarly infer which LSE to activate based on the I / O interface through which the message is received.

[0073] Additionally or alternatively, the protocol handler firmware 112 may infer the target LSE based on information from other protocol layers. Example layers may include a physical layer, a data link layer, a transport layer, a session layer, and / or an application layer. For example, the protocol handler firmware 112 may infer the target LSE based on the physical link over which the message is received, the protocol used to transmit data frames between the host and SE hardware platforms, the open session associated with the message, the applet invoked by the message, and / or the content of the message.

[0074] In operation 406, the protocol handler firmware 112 parses the LSE mapping table 206 and accesses the mapping table entry for the LSE to which the message is intended. For example, if the message is intended for LSE 108a, the protocol handler firmware 112 may scan the table to identify table entry 208a; or if intended for LSE 108n, identify table entry 208n. The protocol handler firmware 122 may read or otherwise access the LSE identification data, global data register, and LSE key of the target LSE.

[0075] In operation 408, the protocol handler firmware 112 can perform access verification of the message. If the message is not successfully verified, the protocol handler firmware 112 can terminate the process and prevent the switching operation from completing. Therefore, the message targeted by the LSE will not be activated. Otherwise, the switching operation can proceed. Techniques for verifying messages are further described in Section 6 entitled "Access Control: Message Verification" and Section 7 entitled "Access Control: Usage-Based Restrictions" below. In other embodiments, message processing can continue without implementing access control.

[0076] In operation 410, the protocol handler firmware 112 reassigns the global address in the switching memory region 204 to the address of the mapping table entry of the target LSE. The address of the previously activated LSE may be overwritten by the new address. In some embodiments, the write access of the global address in the reassigned switching memory region 204 is exclusive to the protocol handler firmware 112. For example, if there is a memory protection unit (MPU) on the SE hardware platform, exclusivity can be enforced by using the unit. The MPU is a hardware component that protects memory intervals by limiting access to authorized entities. The MPU can be part of the SE processor 104 or a separate unit. The MPU can be configured to monitor write transactions to the switching memory region 204 and trigger a fault exception when the write access does not originate from the protocol handler firmware 112.

[0077] Additionally or alternatively, write access may be restricted by enforcing cryptographic signatures between the protocol handler firmware 112. The protocol handler firmware 112 may use a private key to sign the data written to the switch memory region 204. The SESS code 202 may then verify the signature of the switch memory region data using the corresponding public key. If the signature cannot be successfully verified, then writes that attempt to change the global address may be blocked.

[0078] In operation 412, the protocol handler firmware 112 forwards the message to the SESS code 202 for further processing. In some embodiments, the SESS code 202 dereferences the global data structure in the table entry pointed to by the memory address stored in the switch memory 202. The SESS code 202 can then access the global structure and memory segment bound to the requested LSE to process the request. For example, the SESS code 202 can access the internal registers and states associated with the target LSE, including personalized data, memory management data, and application management data. Based on the SESS data mapped to the LSE, the SESS code 202 can run one or more LSE applets to process and respond to the message.

[0079] 5. Isolation Enforcement

[0080] In some embodiments, the SE hardware platform enforces confidentiality and integrity isolation between LSEs 108a-n. For example, the protocol handler firmware 112 and / or SESS code 202 may prevent an LSE from determining other LSEs running on the same SE hardware platform, including which SSPs are associated with other LSEs and other applications currently being hosted. The protocol handler firmware 112 and / or SESS code 202 may also prevent an LSE from accessing a memory segment or operating on data bound to another LSE.

[0081] In some embodiments, the protocol handler firmware 112 derives a set of keys for each LSE to enforce confidentiality and integrity isolation. The SESS code 202 may use the LSE keys to enforce protection of sensitive secrets. For example, SE applications may use cryptographic keys to protect against hardware attacks such as by seeding random number generators and initializing keys for the global platform issuer security domain (ISD). Additionally or alternatively, the SE hardware platform may require keys to share memory with external entities.

[0082] Using an integrated SE chipset, the RAM and NVM memory of the SE can be shared with the system on chip (SoC) on which the SE is integrated. In this case, the isolation of the shared memory between the SE and the SoC can be performed by cryptographic operations that verify the authenticity and integrity of the data accessed by the SE. The SESS code 202 can manage the cryptographic operations and can use hardware-based mechanisms during access operations. Each LSE has a unique set of keys that allow the SESS code 202 to additionally enforce and verify data isolation between the LSEs.

[0083] Figure 5 Illustrated is a set of operations for deriving and applying keys to enforce isolation between LSEs in accordance with some embodiments. Figure 5 One or more operations shown in may be modified, rearranged or omitted altogether. Accordingly, Figure 5 The particular order of operations shown in the drawings should not be construed as limiting the scope of one or more embodiments.

[0084] refer to Figure 5 In operation 502, the protocol handler firmware 112 determines the UUID of the target LSE. As previously described, the UUID value is a globally unique identifier that can be generated based on one or more factors associated with the LSE so that LSE#n does not have the same value on different devices.

[0085] In operation 504, the protocol handler firmware 112 derives one or more cryptographic keys for the LSE based on the corresponding UUID and the SE master key. The SE master key can be a cryptographic key that is unique to the SE hardware and stored by the SE hardware. The SE master key can be used to encrypt the LSE key. In some embodiments, the protocol handler firmware 112 applies a secure hash algorithm (e.g., SHA-256) to a combination of the SE master key and the UUID to derive one or more cryptographic keys for the LSE. However, the algorithm for deriving the unique key of the LSE may vary depending on the specific implementation. For example, the protocol handler firmware 112 may apply a secure hash algorithm to other combinations of values, which may include table entry indexes and / or other LSE attributes of the LSE. Additionally or alternatively, the protocol handler firmware 112 may apply other cryptographic hash algorithms to derive the LSE key.

[0086] In operation 506, the protocol handler firmware 112 binds one or more cryptographic keys to the LSE. The protocol handler firmware 112 may verify that the key is unique to each LSE and store the key or a reference to the key in an entry of the LSE mapping table 206 linked to the LSE.

[0087] In operation 508, the SESS code 202 detects a read or write operation to an LSE. For example, the operation may request to read a memory segment bound to a given LSE or to store sensitive data on the LSE.

[0088] In operation 510, SESS code 202 identifies one or more cryptographic keys that have been bound to the target LSE. For example, SESS code 202 may resolve a table entry for the currently active LSE using the address stored in switch memory area 204. SESS code 202 may obtain the LSE key from the entry (if stored therein) or dereference a pointer to access the key.

[0089] In operation 512, the SESS code 202 encrypts and / or decrypts the data using one or more cryptographic keys bound to the target LSE. In some embodiments, the SESS code 202 may encrypt and / or decrypt the data using the keys using the HW-based cryptographic module 106. For example, the SESS code 202 may provide the keys to a cryptographic accelerator to encrypt data written to a memory segment bound to the LSE or to decrypt data read from the memory segment.

[0090] In some embodiments, the LSE key may be refreshed periodically or in response to receiving certain messages. For example, the protocol handler firmware 112 may generate and derive the key of the target LSE to activate the LSE during a handover operation. In this scenario, the protocol handler firmware 112 may derive the key between operations 406 and 410, such as Figure 4 Thus, the switching operation may include generating / refreshing the LSE key and writing the key to the memory segment referenced by the pointer in the mapping table entry of the LSE.

[0091] In some embodiments, the SESS code 202 may use a key to protect memory intervals bound to an LSE. For example, if an operation attempts to read or write a memory segment bound to one LSE using an LSE key bound to another LSE, the SESS code 202 may deny the operation. Thus, not only may the LSE be prevented from decrypting sensitive data, but it may also be prevented from accessing memory segments within the SE memory 116 where encrypted data is stored.

[0092] 6. Access Control: Message Verification

[0093] In some embodiments, access control is applied to messages to prevent unauthorized entities from triggering exchange operations and accessing LSE resources. Access control operations may use public keys or shared secrets stored in the LSE mapping table 206. In some embodiments, each LSE may be assigned a unique public key. In other embodiments, the public key may be shared by all LSEs or a subset of LSEs.

[0094] In some embodiments, the keys used for access control are different from the LSE keys used to protect memory and encrypt / decrypt SSE data for the LSE. For example, the LSE mapping table 206 may include different fields for different sets of keys. A first field may store or reference a set of one or more cryptographic keys used for encryption operations. The cryptographic keys may be unique to the LSE to enforce isolation and data integrity, as discussed previously. A second field may store or reference a public key or shared secret used for access control. The access control key may be unique to the LSE or shared by multiple LSEs.

[0095] Figure 6 An example set of operations for controlling access to an LSE is illustrated in accordance with some embodiments. Figure 6 One or more operations shown in may be modified, rearranged or omitted altogether. Accordingly, Figure 6 The specific order of operations shown in should not be construed as limiting the scope of one or more embodiments. As previously mentioned, access control operations can be performed during switching operations, such as in Figure 4 The access control operation is performed in operation 408 shown in FIG. Additionally or alternatively, the access control operation may be applied to other messages for the LSE.

[0096] In operation 602, the protocol handler firmware 112 intercepts a message intended for an LSE. The protocol handler firmware 112 may infer the target LSE based on the I / O interface through which the message is intercepted, information encoded in the message, and / or information from other protocol layers, as previously described.

[0097] In operation 604, the protocol handler firmware 112 determines whether access control is enabled for the LSE. In some embodiments, the protocol handler firmware 112 may parse the LSE entry in the mapping table 206 to determine whether there is an access control key (e.g., a public key or a shared secret) stored or referenced by a corresponding field. If no key is stored or referenced, then the protocol handler firmware 112 may infer that access control is not enabled for the target LSE.

[0098] In other embodiments, the access control keys of the LSE and / or references thereto may be stored in other areas of memory, such as in a segment dedicated to access control keys and / or policies. The protocol handler firmware 112 may scan or otherwise search for access control keys in the dedicated section of memory. If no keys or references are stored, then the protocol handler firmware 112 may infer that access control is not enabled for the target LSE.

[0099] In other embodiments, the protocol handler firmware 112 can check the access control policy to determine whether access control has been enabled for the LSE. The access control policy can enable or disable access control on a global basis for all LSEs running on a single level of the LSE, a group of LSEs, or a SE hardware platform. With respect to a group of LSEs, the access control policy can be based on a set of attributes common to LSEs, such as enabling access control for all LSEs from the same SSP or all LSEs of a particular type (e.g., all virtual SIM cards). As another example, the access control policy can be applied based on the I / O interface through which the message is received. For example, access control verification can be applied to all messages received from the NFC controller 134, but if received from the host processor 140, the access control verification is skipped.

[0100] Additionally or alternatively, a group of LSEs may be mapped to the same access control key. For example, all LSEs from the same SSP or the same type may reference the same public key field by referencing the address of an LSE entry or memory area storing the public key. In other embodiments, all LSEs running on a SE hardware platform may reference the same public key. In such a scenario, the access control module 114 may act as the owner of the key.

[0101] If access control is enabled, then in operation 606, the access control module 114 verifies the signature associated with the intercepted message. For example, the signature of the message may include a digital certificate issued by a third-party certificate authority, which is encrypted using a private key, where the private key is owned by an authorized entity and paired with a public key mapped to the target LSE. The access control module 114 can decrypt the signature using the public key.

[0102] If the access control module 114 is able to successfully decrypt the certificate, and the certificate verifies the identity of the private key owner, then the access control module 114 determines that the signature has been successfully verified in operation 608. The verification process also fails if the decryption is unsuccessful or the message contains an invalid certificate.

[0103] In other embodiments, the access control module 114 may verify the signature using other access verification protocols. For example, the access control module 114 may verify whether the signature was generated using a shared secret, such as a pre-shared key (PSK). If the access control module 114 cannot decrypt the signature using the PSK, the verification may fail.

[0104] As another example, the public key field in the LSE mapping table entry can be a certificate, used to verify the certificate chain, and in addition to the message signature, it is also checked against the sub-certificate authority. To verify the chain, the access control module 114 can start from the anchor point in the chain and verify the signature of the next certificate using the public key associated with the current certificate, continuing down the chain and verifying each link until the end is reached. If the chain is verified, then the verification can succeed, otherwise the verification fails.

[0105] In yet another example, the public key field in the mapping table entry of the LSE may store or reference a digest of the public key and / or certificate. For example, the digest may be generated by applying a secure hash algorithm (e.g., SHA-256) to the public key and certificate. The digest may reduce the storage overhead of the access control key.

[0106] If the verification is successful or access control is not enabled, then operations for the LSE are performed in operation 610. For example, the protocol handler firmware 112 may perform operations 410 and 412, such as Figure 4 In other embodiments, if the LSE is currently activated, the protocol handler firmware 112 may forward the message to the SESS code 202 without performing a switch.

[0107] If the verification is unsuccessful, then in operation 612, the protocol handler firmware 112 prevents operations directed to the LSE. For example, the protocol handler firmware 112 may prevent the switch operation from occurring by preventing the global address of the LSE from being reassigned within the switch memory area 204. Thus, the target LSE is not activated. Additionally or alternatively, the protocol handler firmware 112 may delete the message without forwarding it to the SESS code 202. In the event that the target LSE is already active, discarding the message may prevent the message from triggering other operations that access SESS data bound to the LSE.

[0108] 7. Access Control: Usage-Based Restrictions

[0109] In some embodiments, access control policies can define resource and other usage-based restrictions to control access to LSEs. Usage-based restrictions can prevent LSEs from monopolizing or overburdening the SE's shared hardware resources. Usage-based restrictions can also prioritize access rights when multiple LSEs run applications on a shared SE hardware platform.

[0110] In some embodiments, the access policy may be disclosed to and configured by an end user, for example, via a graphical user interface (GUI) on the mobile device 100. The user may select configuration options via the GUI, such as priorities associated with different LSEs, resource limits, and / or other parameters for controlling access, as discussed further herein.

[0111] In some embodiments, the access policy may define time-based restrictions on one or more LSEs. For example, the access policy may specify a maximum threshold time that an LSE may be active within a moving time window. If the LSE remains active for longer than the maximum threshold time within the moving window, the access control module 114 may temporarily restrict access to the SE hardware for a period of time.

[0112] In some embodiments, the access policy may define a switching frequency limit for one or more LSEs. For example, the access policy may specify a maximum number of times that an LSE may be activated by a switching operation within a moving time window. If the number of times an LSE is activated within the time window exceeds a threshold, the access control module 114 may temporarily restrict access to the SE hardware for a period of time.

[0113] In some embodiments, the access policy may define resource consumption thresholds for one or more LSEs. For example, the access policy may specify a maximum processor or memory utilization to limit the LSE's consumption of SE hardware resources. If the resource utilization exceeds the threshold, the access control module 114 may temporarily restrict access to the SE hardware for a period of time. As another example, the access policy may specify a maximum threshold utilization of a peripheral device within the host device. If an operation exceeds the maximum threshold utilization of the peripheral device, the access control module 114 may block, delay, or stop the operation.

[0114] In some embodiments, the access policy may require additional user authentication (such as a user's code or biometric authentication) to perform the operation. For example, if the user cannot successfully authenticate, the access control module 114 can block the payment operation.

[0115] In some embodiments, the access policy may define a minimum usage threshold to prioritize access to the LSE. For example, the access policy may specify a minimum threshold duration before a switching operation deactivates the LSE. The access control module 114 may block or delay the switching operation until the minimum threshold is met. Additionally or alternatively, determining whether to perform the switch may be based on the priorities associated with the currently activated LSE and the target LSE to be activated. If the target LSE has a higher priority, the protocol handler firmware 112 may perform the switch. Otherwise, the protocol handler firmware 112 may block or delay the switch until the currently active LSE completes message processing.

[0116] Access policies can be defined and applied based on a single LSE, a group of LSEs, or all LSEs. When applied to a single LSE, policies and thresholds may vary from LSE to LSE. For example, the threshold duration for one LSE may be longer than for another LSE. Similarly, policies and thresholds may differ between different LSE groups. LSEs can be grouped based on common attributes as described above. For example, access control policies can be applied based on LSE type, such as defining an access control policy that applies to virtual SIM cards, another that applies to payment services, another that applies to identity services, etc. Users can define grouping criteria or create custom groups through the GUI interface.

[0117] Figure 7 An example set of operations for applying an access control policy to a LSE is illustrated in accordance with some embodiments. Figure 7 One or more operations shown in may be modified, rearranged or omitted altogether. Accordingly, Figure 7 The particular order of operations shown in the drawings should not be construed as limiting the scope of one or more embodiments.

[0118] In operation 702, the protocol handler firmware 112 intercepts a message intended for an LSE. The protocol handler firmware 112 may infer the intended LSE based on the I / O interface through which the message is intercepted, information encoded in the message, and / or information from other protocol layers, as previously described.

[0119] In operation 704, the protocol handler firmware 112 determines whether the access policy has defined access control for the LSE. In some embodiments, the protocol handler firmware 112 may parse the LSE entry in the mapping table 206 or search a dedicated interval in memory to determine whether there is an access control policy stored or referenced by a corresponding access control field. If no policy is stored or referenced, then the protocol handler firmware 112 may infer that access control is not enabled for the target LSE. In other cases, the access control policy may explicitly indicate that access control is not defined for the LSE.

[0120] If access control has been defined, then the access control module 114 compares one or more access constraint thresholds defined in the access control policy to one or more usage metrics associated with the LSE in operation 706. For example, the access control module may track and compare activity time, number of switches, memory utilization, and / or other metrics to corresponding thresholds.

[0121] In operation 708, the access control module 114 determines whether one or more of the constraint thresholds are violated. For example, the access control module may determine whether the total activity time, switching frequency, or resource utilization exceeds a constraint threshold.

[0122] If the constraint threshold(s) are not exceeded or the access control is not applicable, then operations for the LSE are performed in operation 710. For example, the protocol handler firmware 112 may perform operations 410 and 412, such as Figure 4 In other embodiments, if the LSE is currently activated, the protocol handler firmware 112 may forward the message to the SESS code 202 without performing a switch.

[0123] If one or more of the constraint threshold(s) have been exceeded or otherwise violated, then in operation 712, the protocol handler firmware 112 blocks or delays operations with respect to the LSE. For example, the protocol handler firmware 112 may block or delay the occurrence of the switch operation by blocking the reassignment of the global address of the LSE within the switch memory region 204 or delaying the reassignment for a threshold time or until the operation of the currently active LSE is completed. Additionally or alternatively, the protocol handler firmware 112 may delete the message without forwarding the message to the SESS code 202 or delay passing the message to the SESS code 202.

[0124] 8. Computer Networks and Cloud Networks

[0125] In some embodiments, a computer network provides connections between a collection of nodes. The nodes can be local and / or remote from each other. The nodes are connected by a collection of links. Examples of links include coaxial cables, unshielded twisted cables, copper cables, optical fibers, and virtual links.

[0126] A subset of nodes implements a computer network. Examples of such nodes include switches, routers, firewalls, and network address translators (NATs). Another subset of nodes uses a computer network. Such nodes (also referred to as "hosts") can execute client processes and / or server processes. A client process makes a request for a computing service (such as the execution of a particular application and / or the storage of a particular amount of data). The server process responds by performing the requested service and / or returning corresponding data.

[0127] A computer network may be a physical network, comprising physical nodes connected by physical links. A physical node is any digital device. A physical node may be a function-specific hardware device, such as a hardware switch, a hardware router, a hardware firewall, and a hardware NAT. Additionally or alternatively, a physical node may be a general-purpose machine configured to execute various virtual machines and / or applications that execute corresponding functions. A physical link is a physical medium that connects two or more physical nodes. Examples of links include coaxial cables, unshielded twisted cables, copper cables, and optical fibers.

[0128] A computer network may be an overlay network. An overlay network is a logical network implemented on top of another network (such as a physical network). Each node in the overlay network corresponds to a corresponding node in the underlying network. Therefore, each node in the overlay network is associated with both an overlay address (addressed to the overlay node) and an underlying address (addressed to the underlying node that implements the overlay node). An overlay node may be a digital device and / or a software process (such as a virtual machine, an application instance, or a thread). The link connecting the overlay nodes is implemented as a tunnel through the underlying network. The overlay nodes at either end of the tunnel treat the underlying multi-hop path between them as a single logical link. Tunneling is performed by encapsulation and decapsulation.

[0129] In some embodiments, the client can be located locally and / or remote from the computer network. The client can access the computer network through other computer networks, such as a private network or the Internet. The client can transmit the request to the computer network using a communication protocol, such as the Hypertext Transfer Protocol (HTTP). The request is transmitted through an interface such as a client interface, such as a web browser, a program interface, or an application programming interface (API).

[0130] In some embodiments, a computer network provides a connection between a client and network resources. Network resources include hardware and / or software configured to execute a server process. Examples of network resources include processors, data storage devices, virtual machines, containers, and / or software applications. Network resources are shared between multiple clients. Clients request computing services from a computer network independently of each other. Network resources are dynamically allocated to requests and / or clients on demand. The network resources allocated to each request and / or client can be expanded or reduced based on, for example, (a) computing services requested by a specific client, (b) aggregate computing services requested by a specific tenant, and / or (c) the requested aggregate computing services of the computer network. Such a computer network may be referred to as a "cloud network."

[0131] In some embodiments, a service provider provides a cloud network to one or more end users. A cloud network can implement various service models, including but not limited to software as a service (SaaS), platform as a service (PaaS), and infrastructure as a service (IaaS). In SaaS, a service provider provides end users with the ability to use the service provider's applications that are being executed on network resources. In PaaS, a service provider provides end users with the ability to deploy customized applications on network resources. Customized applications can be created using programming languages, libraries, services, and tools supported by the service provider. In IaaS, a service provider provides end users with the ability to supply processing, storage, network, and other basic computing resources provided by network resources. Any arbitrary application, including an operating system, can be deployed on network resources.

[0132] In some embodiments, the computer network can implement various deployment models, including but not limited to private cloud, public cloud and hybrid cloud. In a private cloud, network resources are supplied to a specific group of one or more entities for exclusive use (the term "entity" as used herein refers to an enterprise, organization, individual or other entity). Network resources can be local to and / or away from the premises of a specific entity group. In a public cloud, cloud resources are supplied to multiple entities (also referred to as "tenants" or "customers") that are independent of each other. A computer network and its network resources are accessed by clients corresponding to different tenants. Such a computer network may be referred to as a "multi-tenant computer network". Several tenants may use the same specific network resources at different times and / or at the same time. Network resources may be local to and / or away from the premises of a tenant. In a hybrid cloud, a computer network includes a private cloud and a public cloud. The interface between a private cloud and a public cloud allows portability of data and applications. Data stored at a private cloud and data stored at a public cloud can be exchanged through an interface. Applications implemented at a private cloud and applications implemented at a public cloud may have dependencies on each other. Calls from an application at the private cloud to an application at the public cloud (and vice versa) may be performed through the interface.

[0133] In some embodiments, the tenants of a multi-tenant computer network are independent of each other. For example, the business or operation of one tenant can be separated from the business or operation of another tenant. Different tenants may have different network requirements for the computer network. Examples of network requirements include processing speed, data storage capacity, security requirements, performance requirements, throughput requirements, latency requirements, elasticity requirements, quality of service (QoS) requirements, tenant isolation and / or consistency. The same computer network may need to implement different network requirements required by different tenants.

[0134] In some embodiments, in a multi-tenant computer network, tenant isolation is implemented to ensure that applications and / or data of different tenants are not shared with each other. Various tenant isolation methods can be used.

[0135] In some embodiments, each tenant is associated with a tenant ID. Each network resource of the multi-tenant computer network is marked with a tenant ID. Only when the tenant and the specific network resource are associated with the same tenant ID, the tenant is allowed to access the specific network resource.

[0136] In some embodiments, each tenant is associated with a tenant ID. Each application implemented by the computer network is tagged with the tenant ID. Additionally or alternatively, each data structure and / or data set stored by the computer network is tagged with the tenant ID. Only when the tenant and the specific application, data structure and / or data set are associated with the same tenant ID, the tenant is allowed to access the specific application, data structure and / or data set.

[0137] As an example, each database implemented by a multi-tenant computer network can be marked with a tenant ID. Only the tenant associated with the corresponding tenant ID can access the data of a particular database. As another example, each entry in a database implemented by a multi-tenant computer network can be marked with a tenant ID. Only the tenant associated with the corresponding tenant ID can access the data of the particular entry. However, a database can be shared by multiple tenants.

[0138] In some embodiments, the subscription list indicates which tenants have access to which applications. For each application, a list of tenant IDs of tenants authorized to access the application is stored. Only when the tenant ID of a tenant is included in the subscription list corresponding to a specific application, the tenant is allowed to access the specific application.

[0139] In some embodiments, network resources corresponding to different tenants (such as digital devices, virtual machines, application instances, and threads) are isolated to tenant-specific overlay networks maintained by a multi-tenant computer network. As an example, a data packet from any source device in a tenant overlay network can be sent only to other devices within the same tenant overlay network. Encapsulation tunnels are used to prohibit any transmission from a source device on a tenant overlay network to devices in other tenant overlay networks. Specifically, a data packet received from a source device is encapsulated in an outer data packet. The outer data packet is sent from a first encapsulation tunnel endpoint (communicating with a source device in a tenant overlay network) to a second encapsulation tunnel endpoint (communicating with a destination device in the tenant overlay network). The second encapsulation tunnel endpoint decapsulates the outer data packet to obtain the original data packet sent by the source device. The original data packet is sent from the second encapsulation tunnel endpoint to a destination device in the same specific overlay network.

[0140] 9. Hardware Overview

[0141] According to one embodiment, the technology described herein is implemented by one or more special-purpose computing devices. The special-purpose computing device can be hard-wired to perform the present technology, or can include a digital electronic device that is permanently programmed to perform the present technology, such as one or more application-specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or network processing units (NPUs), or can include one or more general-purpose hardware processors that are programmed to perform the present technology according to program instructions in firmware, memory, other storage devices, or combinations. Such special-purpose computing devices can also combine customized hard-wired logic, ASICs, FPGAs, or NPUs with customized programming to implement the present technology. The special-purpose computing device can be a desktop computer system, a portable computer system, a handheld device, a networking device, or any other device that combines hard-wiring and / or program logic to implement the technology.

[0142] For example, Figure 8 800 is a block diagram illustrating a computer system 800 on which some embodiments of the present invention may be implemented. The computer system 800 includes a bus 802 and / or one or more other communication mechanisms for transmitting data between system components. The computer system 800 also includes a hardware processor 804 coupled to the bus 802 for processing information. The hardware processor 804 may be, for example, a general-purpose microprocessor.

[0143] The computer system 800 also includes a main memory 806, such as a random access memory (RAM) and / or other dynamic storage device, coupled to the bus 802 for storing information and instructions to be executed by the processor 804. The main memory 806 may also be used to store temporary variables or other intermediate information during execution of instructions to be executed by the processor 804. When such instructions are stored in a non-transitory storage medium accessible to the processor 804, such instructions cause the computer system 800 to become a special-purpose machine customized to perform the operations specified in the instructions.

[0144] Computer system 800 also includes a read only memory (ROM) 808 and / or other static storage device coupled to bus 802 for storing static information and instructions for processor 804. A storage device 810, such as a magnetic or optical disk, is provided and coupled to bus 802 for storing information and instructions.

[0145] The computer system 800 may be coupled via the bus 802 to a display 812, such as a cathode ray tube (CRT) or light emitting diode (LED) screen, for displaying information to a computer user. An input device 814, including alphanumeric and other keys, is coupled to the bus 802 for communicating information and command selections to the processor 804. Another type of user input device is a cursor control 816, such as a touch screen, a mouse, a trackball, or cursor direction keys, for communicating direction information and command selections to the processor 804 and for controlling cursor movement on the display 812. Such an input device may have two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), to allow the device to specify a position in a plane.

[0146] The computer system 800 may implement the techniques described herein using custom hardwired logic, one or more ASICs or FPGAs, firmware, and / or program logic that, in combination with the computer system, makes the computer system 800 a special purpose machine or programs the computer system 800 to be a special purpose machine. According to one embodiment, the techniques herein are performed by the computer system 800 in response to the processor 804 executing one or more sequences of one or more instructions contained in the main memory 806. These instructions may be read into the main memory 806 from another storage medium, such as the storage device 810. Execution of the sequences of instructions contained in the main memory 806 causes the processor 804 to perform the process steps described herein. In alternative embodiments, hardwired circuitry may be used in place of or in combination with software instructions.

[0147] The term "storage medium" as used herein refers to any non-transitory medium that stores data and / or instructions that cause a machine to operate in a particular manner. Such storage media may include non-volatile media and / or volatile media. Non-volatile media include, for example, optical or magnetic disks, such as storage device 810. Volatile media include dynamic memory, such as main memory 806. Common forms of storage media include, for example, floppy disks, flexible disks, hard disks, solid-state drives, tapes or any other magnetic data storage media, CD-ROMs, any other optical data storage media, any physical media with hole patterns, RAM, PROM and EPROM, FLASH-EPROM, NVRAM, any other memory chip or cassette, content addressable memory (CAM) and ternary content addressable memory (TCAM).

[0148] Storage media are distinct from but may be used in conjunction with transmission media. Transmission media participate in the transfer of information between storage media. For example, transmission media include coaxial cables, copper wire, and optical fiber, including the wires that comprise bus 802. Transmission media may also take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications.

[0149] Various forms of media may be involved in carrying one or more sequences of one or more instructions to processor 804 for execution. For example, the instructions may initially be carried on a disk or solid-state drive of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to computer system 800 can receive the data on the telephone line and use an infrared transmitter to convert the data to an infrared signal. An infrared detector can receive the data carried in the infrared signal and appropriate circuitry can place the data on bus 802. Bus 802 carries the data to main memory 806, from which processor 804 retrieves and executes the instructions. The instructions received by main memory 806 may optionally be stored on storage device 810 before or after execution by processor 804.

[0150] Computer system 800 also includes a communication interface 818 coupled to bus 802. Communication interface 818 provides a two-way data communication coupled to a network link 820, wherein network link 820 is connected to a local network 822. For example, communication interface 818 can be an integrated services digital network (ISDN) card, a cable modem, a satellite modem, or a modem that provides a data communication connection to a telephone line of a corresponding type. As another example, communication interface 818 can be a LAN card that provides a data communication connection to a compatible local area network (LAN). Wireless links can also be implemented. In any such implementation, communication interface 818 sends and receives electrical signals, electromagnetic signals, or optical signals that carry digital data streams representing various types of information.

[0151] The network link 820 typically provides data communication to other data devices through one or more networks. For example, the network link 820 can provide a connection to a host computer 824 or to data equipment operated by an Internet Service Provider (ISP) 826 through a local network 822. The ISP 826, in turn, provides data communication services through the global packet data communication network now commonly referred to as the "Internet" 828. Both the local network 822 and the Internet 828 use electrical, electromagnetic, or optical signals that carry digital data streams. The signals through the various networks and the signals on the network link 820 and through the communication interface 818 are example forms of transmission media that carry the digital data to or from the computer system 800.

[0152] Computer system 800 can send messages and receive data, including program code, through the network(s), network link 820, and communication interface 818. In the Internet example, server 830 can transmit the requested code for an application program through Internet 828, ISP 826, local network 822, and communication interface 818.

[0153] The received code may be executed by processor 804 as it is received, and / or stored in storage device 810 or other non-volatile storage for later execution.

[0154] 10. Other Matters; Extension

[0155] Embodiments are directed to a system having one or more devices including a hardware processor and configured to perform any of the operations described herein and / or in any of the following claims.

[0156] In an embodiment, a non-transitory computer-readable storage medium comprises instructions that, when executed by one or more hardware processors, cause performance of any of the operations described herein and / or any of the claims.

[0157] According to one or more embodiments, any combination of the features and functions described herein may be used. In the foregoing description, embodiments have been described with reference to many specific details that vary depending on the implementation. Accordingly, the description and drawings should be considered illustrative rather than restrictive. The sole and exclusive indicator of the scope of the present invention and what the applicants intend as the scope of the present invention is the literal and equivalent range of the set of claims issued from this application, in the specific form in which such claims issue, including any subsequent corrections.

Claims

1. One or more non-transitory machine-readable media storing instructions that, when executed by one or more processors, cause operations to be performed, the operations comprising: receiving a message for a specific logical security element among a plurality of logical security elements hosted by a secure element hardware platform, wherein when the message is received, the specific logical security element is not a currently activated logical security element on the secure element hardware platform; In response to receiving the message, updating a reference to a currently activated logical security element in a memory of the secure element hardware platform to reference a set of one or more resources bound to the particular logical security element; as well as At least one resource from the set of one or more resources bound to the particular logical security element is accessed based on the updated reference to the currently activated logical security element.

2. One or more non-transitory machine-readable media as described in claim 1, wherein the set of one or more resources includes a set of one or more cryptographic keys bound to the specific logical security element; wherein each corresponding logical security element in the multiple logical security elements is bound to a different set of cryptographic keys that is unique to each logical security element.

3. The one or more non-transitory machine-readable media of claim 1, wherein the set of one or more resources comprises a data registry that identifies a set of memory segments mapped to the particular logical security element.

4. One or more non-transitory machine-readable media as described in claim 3, wherein accessing the at least one resource includes encrypting or decrypting data stored in at least one memory segment in the set of memory segments mapped to the specific logical security element using at least one cryptographic key bound to the specific logical security element.

5. One or more non-transitory machine-readable media as described in claim 1, wherein updating a reference to a currently activated logical security element comprises writing an address of a mapping table entry associated with the particular logical security element, wherein the mapping table entry identifies which resources within the security element hardware platform are bound to the particular logical security element.

6. The one or more non-transitory machine-readable media of claim 5, wherein the memory protection unit is configured to monitor write transactions to a specific memory region storing the reference, and trigger a fault exception when the write transaction to the specific memory region does not originate from an authorized entity.

7. One or more non-transitory machine-readable media as described in claim 5, wherein the address is written to a specific memory in which write access is restricted by enforcing a cryptographic signature, and writing the address of the mapping table entry associated with the specific logical security element is performed in response to verifying the cryptographic signature.

8. The one or more non-transitory machine-readable media of claim 1, wherein the operations further comprise: forwarding the message to a secure element software stack; The secure element software stack executes code that is common to the plurality of logical secure elements.

9. One or more non-transitory computer-readable media as described in claim 8, wherein the code of the security element software stack is configured based at least in part on software data unique to the particular logical security element; wherein the software data is identified based at least in part on an updated reference.

10. The one or more non-transitory computer-readable media of claim 1, wherein the plurality of logical security elements comprises a first virtual smart card from a first security service provider and a second virtual smart card from a second security service provider.

11. A method comprising the operations as claimed in any one of claims 1 to 10.

12. A system comprising at least one device including a hardware processor, the system being configured to perform the operations of any one of claims 1-10.

13. A system comprising means for performing the operations of any one of claims 1-10.

Images