Virtual secure element application system and method based on trusted execution environment

Abstract

A virtual secure element application system and method based on a trusted execution environment are disclosed. The system comprises: a virtual secure element interface component deployed in a rich execution environment and at least one application; a virtual secure element trusted application deployed in a trusted execution environment, the virtual secure element trusted application being configured to create and run a virtual card operating system and at least one virtual applet running on the virtual card operating system; wherein the virtual secure element interface component provides a standard access interface consistent with a physical secure element, receives instructions from the application, and forwards the instructions to the virtual secure element trusted application; the virtual card operating system in the virtual secure element trusted application interprets and executes the instructions, calls a corresponding virtual applet in the at least one virtual applet for processing, and returns the processing result to the application via the virtual secure element interface component. The system can combine the respective functions of the secure element and the trusted execution environment.

Description

Technical Field

[0001] This invention relates to the field of terminal device security technology, specifically to a virtual security element application system and method based on a trusted execution environment. Background Technology

[0002] With the widespread application of technologies such as mobile payment, digital identity authentication, and the Internet of Things, data security and transaction security of terminal devices have become crucial. Currently, mainstream hardware security solutions for terminal devices are developing along two main technological paths: one is the Trusted Execution Environment (TEE), and the other is the Secure Element (SE), which includes embedded secure elements (eSE) and integrated secure elements (inSE).

[0003] On the one hand, TEEs provide secure storage and processing capabilities for sensitive data by building a secure area within the terminal's main processor that is isolated from the Rich Execution Environment (REE, i.e., the ordinary operating system environment). Their advantage lies in their ability to directly access the terminal's powerful computing resources, supporting complex security applications and rich user interactions. However, TEE technology suffers from severe fragmentation. Implementations vary significantly across different chip manufacturers and device models, leading to high costs for the development, testing, and distribution of Trusted Applications (TAs), and hindering the formation of a unified application ecosystem.

[0004] On the other hand, the SE (Secure Component) is a dedicated security element independent of the main processor, designed to simulate a smart card environment and provide a highly secure, physically resistant isolated environment. The SE typically runs a Card Operation System (COS), which can install and run applets compliant with global standards such as Java Card. Its advantage lies in its ability to remotely and uniformly distribute and manage secure applications through a mature Trusted Service Manager (TSM) platform, resulting in a relatively mature ecosystem. However, as a separate coprocessor, the SE's computing power, storage capacity, and bandwidth for interaction with the main system are usually far lower than the main processor, making it difficult to support complex security applications requiring high computing power or large data volumes.

[0005] In existing endpoint security architectures, TEE and SE are typically two independent, parallel solutions. TEE focuses on providing high-performance security services for applications on the REE side, while SE focuses on supporting card applications in fields such as finance and transportation. Although they can communicate through secure channels, their application ecosystems and development models are vastly different. TEE applications need to be developed for specific platforms, while SE applications follow globally unified smart card specifications. This fragmented approach means that developers who want to leverage the powerful computing capabilities of TEE must face complex development and deployment challenges; while those who want to utilize the mature application ecosystem and distribution system of SE are limited by its inherent performance bottlenecks. Summary of the Invention

[0006] To address the shortcomings of existing technologies, this invention proposes a novel security architecture that inherits the advantages of the standardized application ecosystem and unified distribution management of the Security Element (SE) while fully utilizing the powerful computing capabilities, abundant hardware resources, and interactive capabilities of the Trusted Execution Environment (TEE).

[0007] In a first aspect, embodiments of the present invention provide a virtual secure element application system based on a trusted execution environment (TEA). The virtual secure element application system is deployed on a terminal device including a rich execution environment (REA) and the TEA. The virtual smart card system includes:

[0008] A virtual secure element interface component deployed in a rich execution environment and at least one application;

[0009] A trusted application of a virtual secure element deployed in the trusted execution environment, the trusted application of the virtual secure element being used to create and run a virtual card operating system and at least one virtual application applet running on the virtual card operating system;

[0010] The virtual security element interface component provides a standard access interface that is completely consistent with the physical security element, and receives instructions from the application, and forwards the instructions to the trusted application of the virtual security element;

[0011] The virtual card operating system in the trusted application of the virtual secure element interprets and executes the instructions, calls the corresponding virtual application applet in the at least one virtual application applet for processing, and returns the processing result to the application via the virtual secure element interface component.

[0012] Optionally, the terminal device is further provided with a near-field communication module. The near-field communication module communicates with the trusted application of the virtual security element through a hardware bus, and uses the trusted application of the virtual security element to transmit external card reader instructions to the corresponding virtual application applet of the at least one virtual application applet, so that the virtual application applet can process the external card reader instructions.

[0013] Optionally, the trusted application of the virtual security element also provides the virtual application applet with an interface to call the native security services of the trusted execution environment, so that the virtual application applet can use the interface to obtain the security services provided by the trusted execution environment.

[0014] Optionally, the virtual application applet renders a hardware-protected, secure confirmation interface on the physical display screen by calling the trusted user interface service of the trusted execution environment, which cannot be tampered with by applications in the rich execution environment, and supports password keyboard input.

[0015] Optionally, it also includes a trusted service management agent service running in the rich execution environment, the trusted service management agent service being used for:

[0016] The system receives instruction packets from the trusted service management system. These instruction packets are sent to the trusted application of the virtual security element via the virtual security element interface component. The trusted application of the virtual security element uses the instruction packets to download, install, update, or delete the virtual application applet.

[0017] Optionally, the trusted application of the virtual security element encapsulates the native security services provided by the trusted execution environment through a TEE adaptation layer, and provides encapsulated function calls to the virtual card operating system and the virtual application applet through a unified interface.

[0018] Optionally, the instructions from the application are instructions that conform to the smart card standard, and the virtual application applet is a piece of application bytecode that conforms to the smart card standard and carries specific business security logic.

[0019] Optionally, the instructions from the application include an application identifier that indicates a corresponding virtual application mini-program in the at least one virtual application mini-program.

[0020] Optionally, the virtual security element is applied to key management, electronic certificates, and privacy protection.

[0021] Secondly, embodiments of the present invention provide a method for applying a virtual secure element based on a trusted execution environment, including:

[0022] The virtual secure element interface component running in the rich execution environment of the terminal device receives instruction requests from upper-layer applications through a standard access interface that is completely consistent with the physical secure element, and forwards the instruction requests to the trusted application of the virtual secure element running in the trusted execution environment.

[0023] The virtual card operating system in the trusted application of the virtual security element parses the instruction request and calls the corresponding virtual application applet to execute it;

[0024] The execution result of the virtual application applet is returned to the upper-layer application through the virtual security element interface component.

[0025] Optionally, it also includes remote security management steps for virtual application applets:

[0026] By running the Trusted Service Management Agent service in the rich execution environment, instructions are received from the external Trusted Service Management System;

[0027] The instructions are securely transmitted to the trusted application of the virtual security unit in the trusted execution environment through the virtual security element interface component; after security verification, the trusted application of the virtual security element performs the installation, update or deletion operation of the virtual application applet in the virtual card operating system according to the instructions.

[0028] Optionally, a card simulation step is also included:

[0029] The terminal device receives instructions sent by an external reader / writer via its near-field communication module. These instructions are then sent directly to the trusted application of the virtual security unit within the trusted execution environment via a hardware bus. The trusted application of the virtual security unit then distributes these instructions to the corresponding virtual application applets for processing.

[0030] The response command obtained by the virtual application applet is sent to the near-field communication module through the hardware bus, and the near-field communication module returns it to the external reader / writer.

[0031] Thirdly, embodiments of the present invention provide a computer-readable medium storing computer instructions executable by a smart terminal, wherein when the computer instructions are executed, the virtual security element application method described above is implemented.

[0032] The beneficial effect of this invention is that by creatively constructing a virtual security element trusted application within a trusted execution environment, the virtual security element trusted application achieves the same functions and hardware / software interfaces as the physical security element, and by utilizing the virtual card operating system embedded in the virtual security element trusted application, existing security application applets can be directly migrated and run in this virtual environment with little or no modification, thereby effectively bridging the ecological and capability gap between security elements and trusted execution environments in the prior art.

[0033] Because virtual application mini-programs can invoke the native security services of the Trusted Execution Environment (TEE) through the unified interface provided by the Trusted Application of the Virtual Secure Element (REE), applications running on the REE side can obtain the security protection capabilities of the TEE and the Secure Element. This enables security services requiring high-performance computing or rich interactions in scenarios such as mobile payment, digital identity, and the Internet of Things (IoT). Furthermore, the mature trusted service management system within the existing Secure Element ecosystem can be reused, enabling remote security lifecycle management of virtual application mini-programs. Attached Figure Description

[0034] Figure 1 This diagram illustrates the overall architecture of a smart card application system based on a trusted execution environment according to an embodiment of the present invention.

[0035] Figure 2 This diagram illustrates the internal structure of a trusted application of a virtual security element according to an embodiment of the present invention.

[0036] Figure 3 The diagram illustrates the interaction flow of the Trusted Service Management (TSM) service according to an embodiment of the present invention.

[0037] Figure 4 This diagram illustrates the interactive flowchart of an application calling a virtual application applet according to an embodiment of the present invention;

[0038] Figure 5 The diagram illustrates the interactive flowchart of a virtual smart card system for implementing card emulation functionality according to an embodiment of the present invention. Detailed Implementation

[0039] The invention will now be described in more detail with reference to the accompanying drawings. In the various drawings, the same elements are indicated by similar reference numerals. For clarity, the various parts in the drawings are not drawn to scale. Furthermore, some well-known parts may not be shown.

[0040] In this paper, the term "APDU instruction" refers to the Application Protocol Data Unit instruction conforming to smart card standards such as ISO / IEC 7816, which is the basic data packet for interaction between the application and the security element. The term "edge correspondence" means that the edge of a pulse signal or gate signal is approximately aligned with the edge of another signal, allowing for a fixed phase deviation between the two signal edges. For example, due to factors such as device delay or line delay, the two signals can still be considered "edge-corresponding".

[0041] Many specific details of the invention, such as the system architecture, module functions, interaction processes, and techniques, are described below to provide a clearer understanding of the invention. However, as those skilled in the art will understand, the invention may be implemented without adhering to these specific details.

[0042] This invention can be presented in various forms, and some of its embodiments will be described below.

[0043] Figure 1 A schematic diagram of the overall architecture of a smart card application system based on a trusted execution environment according to an embodiment of the present invention is shown.

[0044] refer to Figure 1 As shown, the system is deployed in terminal device 1000. Terminal device 1000 contains a main processor and, based on hardware security extension technologies (such as ARM TrustZone), divides two mutually isolated execution environments at the hardware level: Rich Execution Environment (REE) 1100 and Trusted Execution Environment (TEE) 1200. REE 1100 is the main operating system environment (such as Linux or Android) running on device 1000, and is generally considered untrusted or with low security. TEE 1200 is a secure CPU area co-constructed by hardware (such as ARM TrustZone, Intel SGX / TXX, AMD SEV-SNP) and software, used to protect the confidentiality and integrity of sensitive code and data. Trusted applications are trusted applications running in TEE 1200, responsible for performing security-sensitive operations, and working with client applications (CAs) in REE 1100 to complete security-sensitive business processing. The client application in REE 1100 is responsible for presenting the interface to the user, receiving requests, and calling trusted applications in TEE 1200 through the TEE Client API provided by TEE OS. The TEE Client API ensures communication security by providing a combination of encryption algorithms and authentication, which can be accomplished using the hardware encryption engine built into TEE 1200.

[0045] In the Rich Execution Environment 1100, a Virtual Secure Element Interface Component 1110 is deployed. In the Trusted Execution Environment (1200), a trusted application, the Virtual Secure Element Trusted Application 1210, is deployed. The Virtual Secure Element Interface Component 1110 is a core middleware or system service in the REE, and its main function is to implement the access interface of the Physical Secure Element (SE) (e.g., the SE API defined by GlobalPlatform). The Virtual Secure Element Interface Component 1110 acts as a communication bridge and protocol converter between the application 1120 in the Rich Execution Environment 1100 and the Virtual Secure Element Trusted Application 1210 in the Trusted Execution Environment 1200. The application 1120 forwards smart card standard-compliant access commands to the Virtual Secure Element Trusted Application 1210 within the TEE through the access interface provided by the Virtual Secure Element Interface Component 1110. The Virtual Secure Element Trusted Application 1210 has a built-in Virtual Card Operating System (vCOS) that implements the complete hardware behavior and software interface of the Physical Secure Element (SE). At least one Virtual Application Applet 1211 runs on top of this operating system, and the Virtual Application Applet 1211 actually executes specific business security logic.

[0046] Application 1120 is the ultimate caller of the security service. It obtains the security capabilities of the TEE through the standard access interface (such as sending APDU commands) provided by the Virtual Security Element Interface Component 110, which is exactly the same as the physical security element. The TSM (Trusted Service Manager) proxy service 1130 is a local proxy service running in the background. It is responsible for interacting with the Remote Trusted Service Management (TSM) system 2000 located on the network side to cooperate in completing the remote lifecycle management of virtual application applets 1211 in a large number of terminal devices.

[0047] The system also includes a Near Field Communication (NFC) module 1300 integrated into the terminal device 1000. The NFC module 1300 includes components such as an NFC controller and a radio frequency antenna, and is responsible for handling the transmission and reception of NFC protocols and radio frequency signals. The Virtual Secure Element Trusted Application 1210 can communicate directly or indirectly with the NFC module 1300 via a secure hardware bus (such as an SPI bus or an SWP bus).

[0048] In this architecture, the components work collaboratively through specific connections and interactions. Application 1120 calls the Virtual Secure Element Interface Component 1110 via a standard interface (such as OMAPI). The Virtual Secure Element Interface Component 1110 then conducts secure cross-environment communication with the Virtual Secure Element Trusted Application 1210 within the Trusted Execution Environment 1200 via the Trusted Execution Environment Client API (TEE Client API). The Trusted Service Management Agent Service 1130 communicates with the remote Trusted Service Management System 2000 via network, and also transmits management commands from the remote Trusted Service Management System 2000 to the Virtual Secure Element Trusted Application 1210 via the Virtual Secure Element Interface Component 1110. In card emulation scenarios, the external card reader interacts with the Near Field Communication Module 1300 via an RF field. The Near Field Communication Module 1300 then transmits the received commands directly to the Virtual Secure Element Trusted Application 1210 for processing via a secure hardware bus, thus forming a closed-loop communication path within the secure world that does not pass through the Rich Execution Environment 1100.

[0049] The system operates as follows: When application 1120 needs to invoke a security service, it sends an APDU instruction conforming to the smart card standard to the Virtual Secure Element Interface Component 1110. The Virtual Secure Element Interface Component 1110 receives the instruction, encapsulates it into parameters for a Trusted Execution Environment (TUI) client API call, and forwards it to the Virtual Secure Element Trusted Application 1210 via a secure channel. Upon receiving the instruction, the virtual card operating system within the Virtual Secure Element Trusted Application 1210 parses it and selects one of at least one virtual application applet 1211 to execute the corresponding business security logic. During execution, the virtual application applet 1211 can not only process standard smart card instructions but also invoke native security services of the Trusted Execution Environment 1200 through the extended interfaces provided by the Virtual Secure Element Trusted Application 1210, such as invoking the Trusted User Interface (TUI) for tamper-proof user confirmation. After processing, the result returns along the original path and is ultimately delivered to application 1120 via the Virtual Secure Element Interface Component 1110. For remote application management, the Trusted Service Management Agent 1130 obtains management instruction packages from the remote Trusted Service Management System 2000 and securely transmits them to the Trusted Application 1210 of the Virtual Security Element via the Virtual Security Element Interface Component 1110. The virtual card operating system then performs download, installation, or update operations on the virtual application applet 1211, thereby reusing the mature SE application distribution and management ecosystem. In card emulation mode, the instructions received by the Near Field Communication Module 1300 from the external card reader are directly sent to the Trusted Application 1210 of the Virtual Security Element via the hardware bus. The corresponding virtual application applet 1211 processes and generates a response, which is then returned directly to the Near Field Communication Module 1300 and the external card reader via the same path, realizing card functionality without the need for a physical security element.

[0050] Figure 2 A schematic diagram of the internal structure of a trusted application of a virtual security element according to an embodiment of the present invention is shown.

[0051] refer to Figure 2 As shown in the figure, this embodiment of the invention illustrates the internal structure of the Virtual Security Element Trusted Application 1210 and its interaction with the external environment. The Virtual Security Element Trusted Application 1210 adopts a layered architecture design, mainly including a TEE adaptation layer 1212 and a runtime layer 1213 from bottom to top, and at least one virtual application applet 1211 is carried on top of the runtime layer 1213.

[0052] The TEE adapter layer 1212 is located at the bottom layer of the Virtual Secure Element Trusted Application 1210, and its function is to act as an abstraction layer for interfacing with the underlying Trusted Execution Environment 1200. This TEE adapter layer 1212 is responsible for encapsulating and uniformly calling various low-level security functions and enhancement services provided by the Trusted Execution Environment 1200 kernel or trusted operating system. The TEE adapter layer 1212 provides these encapsulated function calls to the upper-layer runtime layer 1213 through a unified interface, thereby shielding the differences in the specific implementations of Trusted Execution Environments 1200 from different vendors and models, and providing a stable and consistent foundation for accessing low-level services to the upper layers.

[0053] The runtime layer 1213, built upon the TEE adaptation layer 1212, is the core logic engine of the trusted application 1210 within the virtual secure element. At its core is a virtual card operating system (vCOS), which can be a security-hardened and feature-extended Java Card Virtual Machine (JCVM) implementation. This vCOS provides a runtime environment for virtual application applets 1211 running on it that is highly compatible with and functionally equivalent to the physical secure element (SE) chip in terms of instruction set, memory model, and security mechanisms. The vCOS integrates core components such as an instruction interpreter, memory manager, security domain and application manager, application firewall, and application programming interfaces (APIs) conforming to smart card standards such as the Global Platform (GP). Furthermore, the vCOS integrates other enhanced services and functions available in the trusted execution environment 1200. Thus, the runtime layer 1213 can provide two sets of application programming interfaces to the developers of the virtual application applet 1211 through its virtual card operating system: one is a standard smart card API that is completely consistent with the development of physical security elements; the other is a unified extended API for calling various TEEs (such as TUI, mass secure storage) encapsulated by the aforementioned TEE adaptation layer 1212.

[0054] Virtual application applet 1211 runs within the virtualization environment provided by runtime layer 1213. Each virtual application applet 1211 is essentially a piece of application bytecode conforming to global smart card standards such as Java Card, carrying specific business security logic, such as payment transaction algorithms, access control authentication keys, or electronic certificate data. Thanks to the standard-compatible environment provided by runtime layer 1213, existing applet applications developed for physical security components can be directly migrated to this virtual environment and run as virtual application applet 1211 with little or no modification.

[0055] Figure 3 The diagram illustrates the interactive flowchart for invoking the TSM service according to an embodiment of the present invention.

[0056] refer to Figure 3 As shown, the process begins with application 1120 running in the Rich Execution Environment (REE) 1100. When application 1120 needs to obtain or manage specific security services for its users (such as downloading a payment app or an electronic access control virtual app), it first initiates a request by calling the Trusted Service Management (TSM) proxy service 1130, which also runs in the Rich Execution Environment 1100, through step S1. This request indicates the service type (e.g., application download) and other necessary parameters.

[0057] After receiving the request, the Trusted Service Management Agent Service 1130 forwards the request to the Remote Trusted Service Management (TSM) System 2000 located on the network side via the network connection through step S2.

[0058] After receiving a request, the Remote Trusted Service Management System 2000 verifies the identity and permissions of the requesting application 1120 in step S3 to ensure it is qualified to request the service and also verifies the legality of the requested business logic. In step S4, it performs corresponding business processing based on the requested service type. For example, for an application download request, the Remote Trusted Service Management System 2000 prepares the corresponding virtual application applet installation package and related management data. In step S5, it assembles one or more Application Protocol Data Unit (APDU) instruction sequences according to standard protocols such as the Smart Card Global Platform (GP). This APDU instruction sequence contains all the necessary operation commands. The Remote Trusted Service Management System 2000 returns this APDU instruction sequence as a response to the TSM agent service 1130 via the network.

[0059] After receiving an APDU instruction response from the Remote Trusted Service Management System 2000, the TSM agent service 1130 sends the received APDU instruction to the Virtual Secure Element Interface Component 1110 via the standard Open Mobile API (OMAPI) interface. The Virtual Secure Element Interface Component 1110, acting as a protocol converter between the Rich Execution Environment 1100 and the Trusted Execution Environment 1200, has one of its core functions being handling this type of cross-environment communication. Upon receiving the APDU instruction, the Virtual Secure Element Interface Component 1110 does not directly interpret its content but instead encapsulates and formats it, converting it into parameter data conforming to the Trusted Execution Environment Client API (TEE Client API) call specification. After encapsulation, the Virtual Secure Element Interface Component 1110 initiates a call to the Trusted Execution Environment 1200 via step S7, sending the encapsulated data to the Virtual Secure Element Trusted Application 1210.

[0060] After receiving a call request from the Virtual Secure Element Interface Component 1110, the Virtual Secure Element Trusted Application 1210 parses the incoming encapsulated data in step S9, extracts the APDU instructions, and then uses the virtual card operating system to parse the APDU instructions, identify their instruction type and target, and accordingly executes a specific virtual application applet 1211 according to the APDU instructions in steps S10 to S11, and receives the APDU response. The virtual application applet 1211 executes the APDU instructions in the secure runtime environment provided by the virtual card operating system, completes the corresponding operation, and generates an APDU response.

[0061] The Virtual Security Element Trusted Application 1210 then returns this APDU response to the Trusted Service Management Agent Service 1130 via steps S12 to S13. Upon receiving the APDU response from the Virtual Security Element Trusted Application 1210, the Trusted Service Management Agent Service 1130 needs to report the response to the Remote Trusted Service Management System 2000 to inform it of the command execution result. Therefore, the Trusted Service Management Agent Service 1130 reports this APDU response to the Trusted Service Management System 2000 via the network via step S14.

[0062] The Remote Trusted Service Management System 2000 parses the received APDU response in step S15 and determines whether the current management process has been completed based on its content. If the process is not yet complete (for example, the installation of an application may require multiple APDU command interactions to complete), it generates the APDU commands required for the next step in step S16 and returns them to the Trusted Service Management Agent Service 1130 in step S17, thus forming a new round of command-response interaction. If the process is complete, a final completion status result is generated and returned to the TSM agent service 1130. Finally, the TSM agent service 1130 returns this final result to the application 1120 that initially initiated the request, thereby completing the entire remote management process.

[0063] Through the above multiple rounds of interaction, a virtual application applet can be securely downloaded, installed, and configured into the terminal's virtual security element, after which it can be called by application 1120 through a standard interface.

[0064] Figure 4 This diagram illustrates the interactive flowchart of an application calling a virtual application applet according to an embodiment of the present invention.

[0065] refer to Figure 4 As shown, this process begins with the pre-processing step (step S1) of application 1120 executing its own business logic. After completing the pre-processing, application 1120 needs to establish a connection with a specific virtual application applet 1211 to perform core security operations. To this end, application 1120 calls the access interface of virtual security element interface component 1110 to establish a secure channel for communication between virtual security element interface component 1110 and the target virtual application applet 1211, and requests a connection by providing the application identifier (AID) of the virtual application applet 1211 (step S2).

[0066] The Virtual Secure Element Interface Component 1110 receives this connection request and, based on the received parameters, generates an APDU instruction conforming to the smart card standard for selecting a specified AID (step S3). After generating the instruction, the Virtual Secure Element Interface Component 1110 encapsulates and formats it as necessary, converting it into parameter data conforming to the Trusted Execution Environment Client API (TEEClient API) call specification. After encapsulation, the Virtual Secure Element Interface Component 1110 sends the encapsulated data to the Virtual Secure Element Trusted Application 1210 by initiating a call to the Trusted Execution Environment 1200 (step S4).

[0067] After receiving a call request from the Virtual Secure Element Interface Component 1110, the Virtual Secure Element Trusted Application 1210 parses the incoming encapsulated data and extracts the original SELECT APDU instruction. Subsequently, the virtual card operating system inside the Virtual Secure Element Trusted Application 1210 logically creates or activates a secure channel corresponding to the application 1120 that initiated the request, according to the instruction requirements (step S5).

[0068] Next, the virtual card operating system distributes the parsed SELECT APDU instruction to the virtual application applet 1211 within it that matches the specified AID (step S6). The virtual application applet 1211 is activated in the secure runtime environment provided by the virtual card operating system, executes its selection processing logic, generates an APDU response indicating successful selection, and returns the response to the trusted application 1210 of the virtual secure element (step S7). The trusted application 1210 then returns this response to the virtual secure element interface component 1110, which parses and converts it before returning a connection success response to the application 1120 (steps S8 and S9). At this point, the secure channel and logical connection between the application 1120 and the target virtual application applet 1211 have been successfully established.

[0069] After successfully connecting to the virtual application applet 1211, application 1120 converts the business data that needs to be processed by the virtual application applet 1211 into one or more APDU instructions (step S10). Then, application 1120 sends this business APDU instruction to the virtual secure element interface component 1110 (step S11). The virtual secure element interface component 1110 encapsulates the business APDU instruction into TEE Client API call parameters and forwards it to the virtual secure element trusted application 1210 through a secure channel (step S12). After receiving this business instruction, the virtual card operating system 1210 parses it and identifies that the instruction should be sent to the previously established virtual application applet 1211, and then forwards the APDU instruction to the corresponding virtual application applet 1211 (step S13). The virtual application applet 1211 begins to execute the business instruction (step S14). During this execution process, the virtual application applet 1211 can not only process standard smart card instruction logic, but also initiate calls to the native security services of the Trusted Execution Environment 1200 through the unified extended application programming interface (API) provided by the runtime layer of the Trusted Application 1210 of the virtual secure element. For example, the virtual application applet 1211 calls the Trusted User Interface (TUI) service to request the rendering of a hardware-protected, secure confirmation interface on the physical display screen that cannot be tampered with by applications on the Trusted Execution Environment 1100 side. The user can view and confirm the transaction details on the TUI interface, and may also need to enter a personal identification code (PIN). After the user completes the confirmation and authentication, the virtual application applet 1211 uses the key stored securely inside to perform a signature operation on the input transaction data.

[0070] After the business processing is completed, the virtual application applet 1211 assembles the result into an APDU response and returns it to the virtual secure element trusted application 1210 (step S15). The virtual secure element trusted application 1210 then returns the final business response APDU to the application 1120 via the virtual secure element interface component 1110 (steps S16 to S17). After receiving the business response APDU from the virtual application applet 1211, the application 1120 parses it, extracts the processing result, and performs subsequent business processing (step S18).

[0071] After all business interactions are completed, application 1120 will finally call virtual secure element interface component 1110 to send a command to close the secure channel, thereby ending the current session with virtual application applet 1211 and releasing related resources (steps S19 to S24).

[0072] Through the complete interaction process described above, ordinary applications running in the rich execution environment 1100 can transparently utilize virtual security applications running in the trusted execution environment 1200 to complete high-security business processing, achieving a significant improvement in security capabilities and user experience.

[0073] Figure 5 The diagram illustrates the interactive flowchart of a virtual smart card system for implementing card emulation functionality according to an embodiment of the present invention.

[0074] refer to Figure 5 As shown, this embodiment of the invention demonstrates how a terminal device can interact with an external card reader via its internally integrated Near Field Communication (NFC) module 1300 without the need for a Physical Security Element (SE) chip, and how a virtual application applet 1211 running within a Trusted Execution Environment (TEE) 1200 completes security processing, thereby achieving a complete contactless smart card emulation function.

[0075] The card emulation process begins with the physical proximity of the external card reader and the terminal device 1000. When the user brings the terminal device 1000 close to the external card reader (e.g., a hotel room door card reader or a public transportation gate), the two establish a radio frequency connection via near field communication technology (step S1).

[0076] Subsequently, the external card reader sends a SELECT command to the near-field communication module 1300 on the terminal device 1000 via a radio frequency signal emitted by its antenna. This command aims to select and activate a specific card application within the terminal, whose application identifier (AID) points to the installed virtual application applet 1211 (step S2). After receiving the radio frequency signal, the radio frequency antenna of the near-field communication module 1300 demodulates and parses the protocol using its internal NFC controller to obtain the original Application Protocol Data Unit (APDU) command, which is then transmitted via a secure hardware bus (e.g., SPI bus or SWP bus) (step S3). One end of this hardware bus is connected to the controller interface of the near-field communication module 1300, while the other end is configured, through the system hardware architecture, to be directly accessible by software within the trusted execution environment 1200. The Virtual Secure Element Trusted Application 1210 actively reads or passively receives data from the hardware bus by calling the underlying driver application programming interface (API) provided by the Trusted Execution Environment 1200 operating system, calls its internal protocol stack to interpret the transmission protocol, strips off the transmission layer encapsulation, and thus restores the original SELECT APDU instruction initially sent by the external card reader (steps S4 and S5).

[0077] After successfully parsing the APDU instruction, the virtual card operating system inside the Virtual Secure Element Trusted Application 1210 logically establishes a secure channel for the session with the external card reader (step S6). Next, the virtual card operating system distributes the parsed SELECT APDU instruction to its internal virtual application applet 1211, which matches the AID in the instruction (S7). This virtual application applet 1211 is activated in the secure runtime environment provided by the virtual card operating system, executes its initialization logic when selected, and generates an APDU response indicating successful selection. The virtual application applet 1211 returns this response to the Virtual Secure Element Trusted Application 1210. After receiving the response, the virtual secure element trusted application 1210 encapsulates the APDU response according to the same transmission protocol (such as SWP or SPI protocol) as when it was received. Then, it writes the encapsulated data to the hardware bus connected to the near field communication module 1300 by calling the driver API of the trusted execution environment 1200 again. The near field communication module 1300 reads the encapsulated data from its bus interface, and the NFC controller performs protocol parsing to obtain the APDU response. Finally, the response data is modulated into a radio frequency signal through the radio frequency antenna and sent to the external card reader. After receiving this response, the external card reader parses and processes it to confirm that the card application selection is successful and prepares for subsequent business interaction (steps S8 to S11).

[0078] After successfully selecting the virtual application applet 1211, the external card reader immediately sends the service APDU instruction to the near-field communication module 1300 via radio frequency signal. The near-field communication module 1300 also sends the instruction to the virtual secure element trusted application 1210 after protocol encapsulation and bus transmission. After the virtual secure element trusted application 1210 parses the service APDU instruction, the virtual card operating system forwards it to the previously selected virtual application applet 1211. Under the scheduling of the virtual card operating system, the virtual application applet 1211 begins to execute the service instruction. After processing, the virtual application applet 1211 generates a service APDU response and returns it to the virtual secure element trusted application 1210. The virtual secure element trusted application 1210 then repeats the response sending process to return the response to the external card reader (steps S12 to S20).

[0079] Once all necessary business interactions are completed, the external card reader needs to terminate the session. To do this, the external card reader sends an APDU command to close the secure channel. The transmission path of this command is exactly the same as the aforementioned command, finally securingly and completely ending the card simulation transaction (steps S21 to S27).

[0080] Through the above process, the present invention enables the instruction and response data flow between the external card reader and the virtual application applet 1211 to be processed in a closed loop within the trusted execution environment 1200 or through a hardware path directly controlled by it, without going through the rich execution environment 1100. This ensures high security of the communication process and high performance of the processing process while providing the same functional interface and user experience as traditional physical security elements.

[0081] The above solution can be used to address needs such as key management, electronic certificates, and privacy protection. For example, a bank downloads and installs a payment mini-program into a trusted application within a virtual secure element, creates a transaction confirmation key, and when the application initiates a transaction, it sends business data to this payment mini-program via APDU instructions. The payment mini-program can first display the transaction content on its interface for user confirmation, then use the transaction confirmation key to sign the transaction message and return the result. The bank application then uploads the signature result to the bank's backend for signature verification.

[0082] In this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0083] As described above, these embodiments of the present invention do not exhaustively cover all details, nor do they limit the invention to the specific embodiments described. Clearly, many modifications and variations can be made based on the above description. This specification selects and specifically describes these embodiments to better explain the principles and practical applications of the invention, thereby enabling those skilled in the art to effectively utilize the invention and its modifications. The invention is limited only by the claims and their full scope and equivalents.

Claims

1. A virtual secure element application system based on a trusted execution environment, characterized in that, The virtual secure element application system is deployed on a terminal device that includes a rich execution environment and the trusted execution environment. The virtual smart card system includes: A virtual secure element interface component deployed in a rich execution environment and at least one application; A trusted application of a virtual secure element deployed in the trusted execution environment, the trusted application of the virtual secure element being used to create and run a virtual card operating system and at least one virtual application applet running on the virtual card operating system; The virtual security element interface component provides a standard access interface that is completely consistent with the physical security element, and receives instructions from the application, and forwards the instructions to the trusted application of the virtual security element; The virtual card operating system in the trusted application of the virtual secure element interprets and executes the instructions, calls the corresponding virtual application applet in the at least one virtual application applet for processing, and returns the processing result to the application via the virtual secure element interface component.

2. The virtual secure element application system according to claim 1, characterized in that, The terminal device is also equipped with a near-field communication module. The near-field communication module communicates with the trusted application of the virtual security element through a hardware bus, and uses the trusted application of the virtual security element to transmit external card reader instructions to the corresponding virtual application applet of the at least one virtual application applet, so that the virtual application applet can process the external card reader instructions.

3. The virtual secure element application system according to claim 1, characterized in that, The trusted application of the virtual security element also provides the virtual application applet with an interface to call the native security services of the trusted execution environment, so that the virtual application applet can use the interface to obtain the security services provided by the trusted execution environment.

4. The virtual secure element application system according to claim 3, characterized in that, The virtual application applet renders a secure confirmation interface on the physical display screen by calling the trusted user interface service of the trusted execution environment. This interface is hardware-protected and cannot be tampered with by applications in the rich execution environment, and it supports password keyboard input.

5. The virtual secure element application system according to claim 1, characterized in that, It also includes a trusted service management agent service running in the rich execution environment, the trusted service management agent service being used for: The system receives instruction packets from the trusted service management system. These instruction packets are sent to the trusted application of the virtual security element via the virtual security element interface component. The trusted application of the virtual security element uses the instruction packets to download, install, update, or delete the virtual application applet.

6. The virtual secure element application system according to claim 1, characterized in that, The virtual security element trusted application encapsulates the native security services provided by the trusted execution environment through the TEE adaptation layer, and provides encapsulated function calls to the virtual card operating system and the virtual application applet through a unified interface.

7. The virtual secure element application system according to claim 1, characterized in that, The instructions from the application are compliant with the smart card standard. The virtual application applet is a piece of application bytecode that conforms to the smart card standard and carries specific business security logic.

8. The virtual secure element application system according to claim 1, characterized in that, The instructions from the application include an application identifier that indicates a corresponding virtual application mini-program in the at least one virtual application mini-program.

9. The virtual secure element application system according to claim 1, characterized in that, The virtual security element is used for key management, electronic certificates, and privacy protection.

10. A method for applying a virtual secure element based on a trusted execution environment, characterized in that, include: The virtual secure element interface component running in the rich execution environment of the terminal device receives instruction requests from upper-layer applications through a standard access interface that is completely consistent with the physical secure element, and forwards the instruction requests to the trusted application of the virtual secure element running in the trusted execution environment. The virtual card operating system in the trusted application of the virtual security element parses the instruction request and calls the corresponding virtual application applet to execute it; The execution result of the virtual application applet is returned to the upper-layer application through the virtual security element interface component.

11. The method for applying a virtual secure element according to claim 10, characterized in that, It also includes remote security management steps for virtual application mini-programs: By running the Trusted Service Management Agent service in the rich execution environment, instructions are received from the external Trusted Service Management System; The instructions are securely transmitted to the trusted application of the virtual security unit in the trusted execution environment via the virtual security element interface component. After security verification, the virtual security element, through trusted application, performs installation, update, or deletion operations on the virtual application applet in the virtual card operating system according to the instructions.

12. The method for applying a virtual security element according to claim 10, characterized in that, It also includes the card emulation step: The terminal device receives instructions sent by an external reader / writer via its near-field communication module. These instructions are then sent directly to the trusted application of the virtual security unit within the trusted execution environment via a hardware bus. The trusted application of the virtual security unit then distributes these instructions to the corresponding virtual application applets for processing. The response command obtained by the virtual application applet is sent to the near-field communication module through the hardware bus, and the near-field communication module returns it to the external reader / writer.

13. A computer-readable medium storing computer instructions executable by a smart terminal, wherein when executed, the computer instructions implement the virtual secure element application method as described in any one of claims 10 to 12.

Images