A trusted application running system compatible with GPTEE standard under a macro kernel

Abstract

The application relates to a trusted application running system compatible with a GPTEE standard under a macro kernel, and belongs to the field of information security, comprising a normal execution environment and a safe execution environment which realize hardware-level isolation through a Hypervisor; the normal execution environment deploys a CA and a trusted application client library which provides a GP TEE Client API standard interface; the safe execution environment deploys a trusted application virtual socket server, a TEE runtime environment and a TA which runs in the form of a standard user state process. The application establishes a cross-VM encrypted communication channel through a VSOCK virtual socket, and realizes safe session management between the CA and the TA, TA loading verification and command calling. The application guarantees safe isolation through a virtualization technology, realizes complete compatibility with the GP TEE standard, enables the TA to run in a functional complete macro kernel environment, and is compatible with the standard and rich in ecology.

Description

Technical Field

[0001] This application relates to the field of information security, and in particular to a trusted application running method compatible with the GPTEE standard under a monolithic kernel. Background Technology

[0002] Trusted Execution Environment (TEE) is a hardware-isolated security technology designed to provide a secure environment isolated from the general-purpose operating system (REE) for the processing of sensitive data and the execution of critical security operations. The core concept of TEE technology is to create a "Secure World" through hardware mechanisms, which runs in parallel with the "Normal World" running the general-purpose operating system, thereby protecting sensitive applications and data from malware attacks.

[0003] Currently, the mainstream TEE technology solutions in the industry mainly fall into the following categories:

[0004] Option 1: Microkernel TEE solution based on ARM TrustZone (such as OP-TEE).

[0005] ARM TrustZone technology is used to divide the processor into two independent execution environments: Secure World and Normal World. A lightweight microkernel TEE OS runs in Secure World, with Task TA running as an independent task on top of the TEE OS. Task CA runs on the Android / Linux system in Normal World, entering a secure monitoring mode via the SMC (Secure Monitor Call) instruction to achieve cross-world communication. OP-TEE fully implements the GlobalPlatform TEE standard specification.

[0006] Technical features: Fully supports the GP TEE standard and has high security, but TEE OS adopts a microkernel architecture, which limits its functionality and lacks complete ecosystem support.

[0007] Option 2: A virtualization-based REE-type Linux isolation solution (such as Trusty on Android).

[0008] Use a hypervisor to create a separate, secure virtual machine, within which a Linux-like TEE OS (such as TrustyOS) runs, with the TA (Trusty OS) running as a user-space process. Trusty OS is based on a streamlined Linux-like kernel, providing rich system calls and library support, and is isolated from the virtual machine where the Android system resides through the hypervisor.

[0009] Technical Features: Trusty OS provides a more complete Linux-like environment than traditional microkernel TEE OSes. TAs can use standard POSIX interfaces, C libraries, etc., resulting in higher development efficiency. However, Trusty OS does not fully implement the GlobalPlatformTEE standard, only providing some proprietary APIs. This means that TAs developed based on the GP standard cannot be directly ported and run, resulting in poor cross-platform compatibility.

[0010] Option 3: Enclave solution based on Intel SGX.

[0011] A secure enclave is created using the SGX instruction set provided by the CPU, loading sensitive code and data into a protected memory region. The enclave runs on the same OS as regular applications and communicates with them through a special ECALL / OCALL mechanism.

[0012] Technical features: No independent TEE OS required, but it is limited to Intel platforms and has limited memory capacity. It also does not support the GPTEE standard.

[0013] Therefore, the existing technology has the following technical problems.

[0014] Question 1: It is impossible to have both full TEE standard support and a rich ecosystem.

[0015] Existing TEE solutions face a dilemma:

[0016] Choosing a microkernel solution such as OP-TEE offers full GP TEE standard support and excellent cross-platform compatibility. However, the microkernel architecture results in extremely simplified system functionality, lacking rich driver support, system libraries, and development tools. Developers cannot use mature components in the ecosystem (such as complete file systems, network protocol stacks, and hardware drivers) and must redevelop basic functions in a constrained environment, leading to low development efficiency.

[0017] Choosing a Linux-like solution such as Trusty provides a relatively complete runtime environment. TA development can utilize standard POSIX interfaces and C libraries, resulting in high development efficiency. However, because it does not implement the GP TEE standard specification, TA can only use vendor-specific APIs, hindering cross-platform portability and creating a closed ecosystem. TAs developed based on the GP standard cannot run in a Trusty environment, and vice versa.

[0018] Question 2: The contradiction between standard compatibility and ecosystem richness

[0019] The GlobalPlatform TEE standard aims to provide a unified TEE programming interface to achieve cross-platform compatibility for technical interfaces (TAs). However, in existing solutions:

[0020] Solutions that implement the GP standard (such as OP-TEE) suffer from a severely limited ecosystem due to microkernel limitations.

[0021] Solutions that offer a rich ecosystem (such as Trusty) do not support the GP standard, thus creating an ecological island.

[0022] Developers face a difficult choice: either prioritize standards compatibility over development efficiency, or prioritize development efficiency over standards compatibility. This dilemma severely restricts the widespread adoption of TEE technology and the development efficiency of TA (Technical Application).

[0023] Question 3: Application migration costs are high.

[0024] When migrating from a regular Linux environment to a microkernel environment such as OP-TEE, a large amount of code refactoring is required due to the significant differences in system interfaces.

[0025] When migrating to proprietary solutions such as Trusty, although the interfaces are similar, they do not conform to the GP standard, and subsequent platform migrations will still face repeated adaptation work. Summary of the Invention

[0026] To address the problems existing in the prior art, this application provides a trusted application runtime system that is compatible with the GPTEE standard under a monolithic kernel. It ensures security isolation through virtualization technology while achieving full compatibility with the GPTEE standard, enabling TA to run in a fully functional monolithic kernel environment, thus achieving both standard compatibility and ecosystem richness.

[0027] This application provides a trusted application runtime system compatible with the GPTEE standard under a monolithic kernel. The system includes a normal execution environment and a secure execution environment, which are hardware-level isolated through a hypervisor.

[0028] The typical execution environment includes the Client Application for information connection and the Trusted Application Client Library. The Trusted Application Client Library provides the GlobalPlatform TEE Client API standard interface for the Client Application to call, and also implements session management, data serialization, and VSOCK communication encapsulation encryption protocol processing functions when the Client Application calls the ordinary application.

[0029] The secure execution environment (SEA) deploys a Trusted Application Virtual Socket (TIPS) server, a TEE runtime environment, and a Trusted Application process, which are connected sequentially. The TIPS server listens for VSOCK connection requests from the normal execution environment, establishes VSOCK connections with the normal execution environment, and responds to other requests from the normal execution environment. The TEE runtime environment assists in loading and setting up TAs and invoking CA-TA commands through information exchange with the TIPS server and the Trusted Application process. The Trusted Application process is the actual running trusted application, existing as a standard user process, used to execute command responses from the Client Application.

[0030] Optionally, the trusted application client library includes: a GP Clinent API interface implementation module, a first encryption protocol processing module for mutual information connection, a session management module, and a VSOCK client communication module, wherein,

[0031] The GP Clinent API implementation module provides a standard interface encapsulation for Client Applications to call;

[0032] The Session management module is responsible for maintaining the session state between the Client Application and the TA in the secure execution environment, and implementing session routing;

[0033] The VSOCK client communication module is responsible for establishing an encrypted communication channel with the secure execution environment and enabling information exchange with the secure execution environment.

[0034] The first encryption protocol processing module is used to execute the encryption handshake protocol with the secure execution environment, maintain the encryption communication channel, and realize request encryption and response decryption.

[0035] Optionally, the trusted application virtual socket server includes a VSOCK server communication module with mutual information connection, a second encryption protocol processing module, and a Session routing module, wherein,

[0036] The Session routing module is used by the Session management module to maintain the session state between the Client Application and the TA, and to implement session routing.

[0037] The VSOCK server communication module is used to establish an encrypted communication channel with the VSOCK client communication module to realize information exchange with the VSOCK client communication module.

[0038] The second encryption protocol processing module is used to execute the encryption handshake protocol with the normal execution environment, maintain the encryption communication channel, and realize request decryption and response encryption.

[0039] Optionally, the normal execution environment runs a standard Host OS operating system, while the secure execution environment runs an independent monolithic kernel operating system.

[0040] Optionally, the Hypervisor is responsible for isolating and mediating communication between the normal execution environment and the secure execution environment, and its functions include:

[0041] Configure Stage-2 page tables to achieve memory isolation;

[0042] VSOCK virtual devices enable cross-VM communication;

[0043] Manage the scheduling and context switching of virtual CPUs.

[0044] Optionally, the system architecture can be built through the system initialization process. After the architecture is built, the TA loading and session establishment process, as well as the CA-TA command invocation process, can be implemented based on the built system architecture.

[0045] Optionally, the system initialization process includes;

[0046] The hypervisor creates a protected VM and configures Stage-2 page tables to achieve memory isolation.

[0047] Deploy the VSOCK virtual appliance to establish a cross-VM communication channel;

[0048] Start the monolithic kernel operating system in the Protected VM and load the TEE components in the TEE runtime environment;

[0049] The Host OS establishes an encrypted communication channel with the Protected VM through an encrypted handshake protocol.

[0050] Optionally, the TA loading and session establishment process includes;

[0051] The Client Application initiates a session establishment request, and the Trusted Application Client Library encrypts the session establishment request and sends it to the Trusted Application Virtual Socket Server through an encrypted communication channel.

[0052] The Trusted Application Virtual Sockets server decrypts the encrypted session establishment request and determines the TA, which is then routed to the TEE runtime environment.

[0053] The TEE runtime environment verifies the integrity of the TA image and creates the TA process after the integrity verification is successful.

[0054] The TEE runtime environment generates a Session ID and establishes a session mapping relationship between the Session ID and the TA process;

[0055] The TA performs initialization and seals the initialization result and Session ID to generate a Session response message. The Session response message is encrypted by the Trusted Application Virtual Socket server and returned to the Trusted Application Client Library. The Trusted Application Client Library decrypts the encrypted Session response message and returns the Client Application value.

[0056] Optionally, the CA-TA command invocation process includes;

[0057] The Client Application initiates a command call request through the Session ID. The Trusted Application Client Library encrypts the command call request and sends it to the Trusted Application Virtual Socket Server through an encrypted communication channel.

[0058] The Trusted Application Virtual Socket server decrypts the encrypted command call request and routes it to the TA through the TEE runtime environment;

[0059] The Trusted Application Virtual Socket (TA) performs a secure operation and generates an execution result. The Trusted Application Virtual Socket (TAVPS) server encrypts the execution result and returns it to the Trusted Application Client Library via an encrypted communication channel. The Trusted Application Client Library decrypts the encrypted execution result and returns the Client Application value.

[0060] Optionally, the TEE runtime environment includes a trusted application loading service, a session manager, a key management service, and a trusted application internal core library that are interconnected.

[0061] In summary, this application includes at least one of the following beneficial technical effects:

[0062] 1. Standard compatibility: Fully implements the GP TEE standard, TA can be ported across platforms, and is compatible with standard solutions such as OP-TEE;

[0063] 2. Rich ecosystem: TA runs in a complete monolithic kernel environment and can directly use all the resources (drivers, libraries, tools) in the ecosystem, with development efficiency equivalent to ordinary application development;

[0064] 3. Security Isolation: Strong isolation between Protected VM and Normal World is achieved through Hypervisor hardware virtualization, with a security level equivalent to the traditional TrustZone solution;

[0065] 4. Ease of migration: Ordinary applications can be quickly adapted to TA, only needing to call the GP standard API to handle security logic, without the need to refactor the system interface layer code. Attached Figure Description

[0066] Figure 1This is an architecture diagram of a trusted application runtime system compatible with the GPTEE standard under a monolithic kernel, according to an embodiment of this application.

[0067] Figure 2 This is a flowchart of a trusted application runtime system compatible with the GPTEE standard under a monolithic kernel, according to an embodiment of this application.

[0068] Figure 3 This is a flowchart of a second embodiment of a trusted application runtime system compatible with the GPTEE standard under a monolithic kernel, according to an embodiment of this application.

[0069] Figure 4 This is a flowchart of the third embodiment of the trusted application runtime system compatible with the GPTEE standard under a monolithic kernel according to this application. Detailed Implementation

[0070] The present application will be further described in detail below with reference to the accompanying drawings.

[0071] This specific embodiment is merely an explanation of this application and is not intended to limit it. After reading this specification, those skilled in the art can make modifications to this embodiment without contributing any inventive step, but such modifications are protected by patent law as long as they fall within the scope of the claims of this application.

[0072] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0073] In existing Trusted Execution Environment (TEE) technology implementations, Trust Applications (TAs) typically run on a specially designed microkernel architecture TEE OS (such as OP-TEE, Trusty, etc.). This traditional architecture has the following problems:

[0074] (1) Limited development ecosystem: The simplified functions of TEE OS and the lack of rich driver support, system libraries and development tools make TA development and debugging difficult and development efficiency low. Developers need to perform customized development for specific TEE OS and cannot reuse mature ecosystem resources.

[0075] (2) Poor functional scalability: When the TA needs to access complex hardware devices or use advanced system functions, the TEE OS often requires a lot of custom development work, and some functions may not be implemented.

[0076] (3) Complicated standard compatibility implementation: Although GlobalPlatform has formulated the TEE standard specification, implementing the complete GP TEE standard interface under the microkernel architecture requires rebuilding the entire runtime environment, which involves a large amount of engineering work and is prone to compatibility issues.

[0077] (4) High migration cost: When existing TA applications are migrated from the TEE environment to the REE environment, a lot of code refactoring and adaptation work is required, resulting in a long migration cycle and high risk.

[0078] To address the aforementioned issues, this invention proposes a trusted application runtime system (TA) compatible with the GlobalPlatform TEE standard within a monolithic kernel. By utilizing pKVM virtualization technology to run the monolithic kernel as a protected VM, combined with the VSOCK communication mechanism and a custom encryption protocol, TA can run in a fully functional monolithic kernel environment while maintaining secure isolation and full compatibility with the GP TEE standard interface. This invention leverages the advantages of a mature monolithic kernel ecosystem (rich drivers, libraries, and tools) while ensuring security through hardware-level virtualization isolation, significantly reducing the development difficulty and migration costs of TA.

[0079] The following is an explanation of the technical terms used in this invention:

[0080] TEE OS: Generally refers to an operating system that runs in a Trusted Execution Environment (TEE), typically a microkernel or lightweight kernel architecture.

[0081] Trust Application (TA): A trusted application running on top of the TEE OS, used for handling sensitive data and security operations.

[0082] Monolithic kernel: An operating system kernel architecture characterized by the fact that the entire kernel program is a single binary executable file, containing all kernel services (such as device drivers, file systems, network protocol stacks, etc.).

[0083] GlobalPlatform TEE Standard (GP TEE Standard): An international standard specification for Trusted Execution Environments developed by the GlobalPlatform organization, defining the architecture, API interfaces, and security requirements of TEEs.

[0084] pKVM (protected KVM): A protected kernel-based virtual machine technology introduced by Android that provides hardware-level virtual machine isolation and memory protection.

[0085] Protected VM: A virtual machine protected by pKVM, which is strongly isolated from the host machine and other virtual machines, ensuring the confidentiality and integrity of data within the virtual machine.

[0086] VSOCK (Virtual Socket): A socket interface for communication between virtual machines and the host machine or between virtual machines, providing efficient cross-VM communication capabilities.

[0087] Client Application (CA): A client application running in a normal execution environment (REE) that calls security services provided by the TA through the TEE Client API.

[0088] TEE Client API: A client API interface defined by GlobalPlatform, used to establish sessions and communicate between CAs and TAs.

[0089] TEE Internal API: An internal API interface defined by GlobalPlatform, which is called by TA to access security services provided by TEE (such as encryption, key management, etc.).

[0090] Session: A communication connection established between CA and TA for transmitting commands and data, with independent lifecycle management.

[0091] REE (Rich Execution Environment): A rich execution environment refers to a general execution environment that runs a common operating system (such as Android or Linux), as opposed to TEE.

[0092] Exception level (EL) is essentially the processor's execution privilege level. The higher the level number, the higher the privilege (EL3 > EL2 > EL1 > EL0).

[0093] EL0: User application execution;

[0094] EL1: Operating system kernel execution;

[0095] EL2: Virtualization Management;

[0096] EL3: Safety state switching and startup.

[0097] like Figure 1As shown, the system architecture of this embodiment of the invention is divided into two main execution environments: Normal World (REE) and Secure World (Protected VM). The two are isolated at the hardware level through Hypervisor.

[0098] Normal World runs a standard Host OS (Android or Linux) and deploys a Client Application (CA) and a TEE Client Library (Trusted Application Client Library) for information connectivity.

[0099] Client Application (CA) refers to a regular application that needs to call security services, such as payment applications, digital wallets, DRM clients, etc.

[0100] The TEE Client Library provides the GlobalPlatform TEE Client API standard interface to the Client Application (CA) for it to call. At the same time, it implements session management, data serialization, VSOCK communication encapsulation and encryption protocol processing functions when the Client Application (CA) calls ordinary applications.

[0101] The CA interacts with the TEE Client Library through standard GP TEE Client API interfaces (such as TEEC_InitializeContext, TEEC_OpenSession, TEEC_InvokeCommand, etc.). The TEE Client Library contains four core modules: the GP Client API interface implementation module, the first encryption protocol processing module for mutual information connection, the Session management module, and the VSOCK client communication module. Specifically, the GP Client API interface implementation module provides standard interface encapsulation for the CA to call; the Session management module is responsible for maintaining the session state between the CA and the Secure World's TA, implementing session routing; the VSOCK client communication module is responsible for establishing an encrypted communication channel with the Secure World, enabling information exchange; and the first encryption protocol processing module is used to execute the encrypted handshake protocol with the Secure World, maintain the encrypted communication channel, and implement request encryption and response decryption.

[0102] Secure World runs a standalone monolithic kernel operating system (such as Linux) and deploys a TEEVSOCK Server (TEE VSCOK Server; Trusted Application Virtual Socket Server), a TEE RuntimeEnvironment, and a TA Process (Trusted Application Process) with sequential information connections.

[0103] TEE VSOCK Server (tee-vsock-server; Trusted Application Virtual Socket Server): Used to listen for connection requests from the Normal World, establish VSOCK connections with the Normal World, and respond to other requests from the Normal World. TEE VSOCK Server includes a VSOCK server communication module for mutual information connection, a second encryption protocol processing module, and a Session routing module.

[0104] The Session routing module also connects to the Normal World's Session management module through the Hypervisor, and works with the Session management module to maintain the session state between CA and TA to achieve session routing.

[0105] The VSOCK server communication module connects with the VSCOK client communication module via the Hypervisor to establish an encrypted communication channel and enable information exchange. The second encryption protocol processing module executes the encrypted handshake protocol with Normal World, maintains the encrypted communication channel, and enables request decryption and response encryption.

[0106] The TEE Runtime Environment is used for information exchange with the TEE VSOCK Server and TAProcess to assist in TA loading and session setup, as well as CA-TA command invocation. The TEE Runtime Environment includes TA Loader Service (taloader; Trusted Application Loading Service), Session Manager, Key Management Service (keymaster; Key Management Service), and TEE InternalCore Library (libteec-internal.so; Trusted Application Internal Core Library).

[0107] Among them, the TA Process (Trusted Application Process) is the actual running trusted application, which exists in the form of a standard user-mode process and is used to execute CA command responses.

[0108] Hypervisors (such as pKVM) are responsible for isolating and mediating communication between the two worlds, and their functions include:

[0109] Configure Stage-2 page tables to achieve memory isolation;

[0110] VSOCK virtual devices enable cross-VM communication;

[0111] Manage the scheduling and context switching of virtual CPUs (vCPUs).

[0112] In this invention, Figure 1 The system architecture shown is constructed through the system initialization process. After construction, the TA loading and session establishment process, as well as the CA-TA command invocation process, can be implemented based on the complete system architecture. The following is a detailed description of the three processes.

[0113] Process 1: System Initialization Process.

[0114] The system initialization process includes three stages: Hypervisor environment preparation, Protected VM startup and loading of TEE components, and Normal World initialization. (The following section combines...) Figure 2 The execution process at each stage is described in detail.

[0115] Phase 1: Hypervisor Environment Preparation

[0116] Specifically, it includes the following steps S11 to S13.

[0117] Step S11: When the bootloader hands over control to the host OS, the hypervisor initializes, including:

[0118] Boot the Hypervisor with EL2 privilege level and detach the Hypervisor from the vmlinux image;

[0119] Create a Stage-2 page table for the Host OS in the Hypervisor for translating virtual machine physical addresses to host physical addresses;

[0120] The hypervisor divides the system's physical memory into a Host region and a Protected region. The Host region is used by the Normal World, and the Protected region is used by the Protected VMs in the Secure World.

[0121] Initialize the System Memory Isolation Unit (SMMU) and configure the Memory Access (DMA) isolation policy to ensure that DMA devices cannot access the memory of the Protected VM. It is important to know that the SMMU provides address translation and permission checks for I / O devices.

[0122] This step corresponds to Figure 2 The middle section includes "PKVM initialization" and "isolated memory page table".

[0123] Step S12: Start the Host OS and create the Protected VM.

[0124] The host OS initiates a Protected VM creation request by calling the KVM interface via ioctl;

[0125] The hypervisor allocates independent physical memory from the protected region to the protected VM;

[0126] Configure memory access permissions for the Stage-2 page table of the Protected VM, so that the Protected VM can access the Protected region, but the Host OS cannot access the Protected region.

[0127] The hypervisor allocates virtual CPUs (vCPUs) to the protected VMs and configures the register states of the virtual CPUs.

[0128] This step corresponds to Figure 2 In the "Create Protected VM" section.

[0129] Step S13: After the Protected VM is configured, configure the VSOCK virtual device.

[0130] The hypervisor creates a VSOCK virtual device for the protected VM and assigns a unique CID (e.g., CID=3) to the protected VM. It also configures the virtqueue shared memory queue as a cross-VM data transfer channel. The virtqueue is a circular buffer located in a shared memory area between the host and guest (which is strictly managed by the hypervisor) for data flow.

[0131] This step corresponds to Figure 2 The middle part is "allocating hardware devices such as CID".

[0132] After Phase 1 is completed, a basic Protected VM isolation environment is established, but the communication channel is not yet activated.

[0133] Phase 2: Protected VM starts up and loads TEE components.

[0134] Specifically, it includes the following steps S21 to S23.

[0135] Step S21: After the Protected VM is configured with the VSOCK virtual device, the Host OS loads the monolithic kernel image and starts the Protected VM.

[0136] The host OS loads the monolithic kernel image and fs into the memory space of the protected VM;

[0137] The startup parameters for the virtual CPU are set through the KVM interface. The startup parameters are the PC (Program Counter) pointer pointing to the monolithic kernel entry and the device tree description of the hardware configuration. Then the Hypervisor starts the virtual CPU and makes the monolithic kernel start in the Protected VM with EL1 privilege level.

[0138] This step corresponds to Figure 2 Start the Protected VM.

[0139] Step S22: After the monolithic kernel starts, initialize the monolithic kernel.

[0140] The monolithic kernel parses the device tree, discovers and initializes the registered VSOCK virtual device (virtio_vsock.ko); simultaneously, it starts the first init process. This step corresponds to... Figure 2 "Protected VM initialization" in the middle.

[0141] Step S23: After the init process executes the startup script, it loads the TEE component.

[0142] Start the Key Management Service (keymaster), TA Loader Service (taloader), Session Manager, and TEE VSOCK Server in sequence.

[0143] The keymaster reads the Root Key from the TrustZone secure storage area (which is generated by hardware RNG when the system first boots). If the Root Key does not exist, it generates a new one and persists it to the encrypted partition. Then it listens for IPC (such as Unix Domain Socket).

[0144] The taloader loads and parses the TA registry, constructing a mapping index relationship (HashMap) between UUIDs and TAs.<UUID, TAInfo> Then listen for IPC.

[0145] The Session Manager initializes the session management table (an in-memory HashMap structure) and connects to the keymaster, then obtains the Session ID to generate the necessary key materials.

[0146] The TEE VSOCK Server creates a VSOCK server socket, obtains the pre-configured root key required for communication encryption from the keymaster, loads the TEE certificate chain and private key, and then enters the event loop to wait for connections.

[0147] This step corresponds to Figure 2 The options are "Load TEE RUNTIME" and "Start Session Manager".

[0148] Once Phase Two is complete, the Protected VM and TEE components are ready and awaiting connection requests from the Normal World.

[0149] Phase 3: Normal World initialization.

[0150] Specifically, it includes the following steps S31 to S33.

[0151] Step S31: When the Host OS starts up (before the Zygote process starts or when TEE is used for the first time), the Host OS loads the TEE Client Library.

[0152] The TEE Client Library executes its constructor, obtains the CID and service port of the Protected VM, and initializes internal data structures such as the connection pool and session cache.

[0153] This step corresponds to Figure 2 The terms "Normal World" and "CA Client" are used in this context.

[0154] Step S32: When the first CA calls TEEC_InitializeContext(), an encrypted communication channel is established. The encrypted communication channel is used to enable information exchange between the Normal World's TEE Client Library and the Protected VM's TEE VSCOKServer.

[0155] Step S321: VSOCK connection established.

[0156] A VSOCK client socket is created using the VSOCK client communication module in the TEE Client Library. The connection parameter `sockaddr_vm` is constructed, setting the target CID to the CID of the Protected VM and the target port to `TEE_SERVICE_PORT`. The `connect()` function is called to initiate a connection request. The connection request is forwarded to the Protected VM via the Hypervisor's VSOCK routing mechanism.

[0157] Connection requests are received through the VSOCK server communication module in the TEE VSCOK Server, and the TEE VSCOKServer's accept() function returns the VSOCK client socket.

[0158] Step S322: Encrypted handshake protocol.

[0159] Step S3221: Protocol version negotiation.

[0160] The VSOCK client communication module in the TEE Client Library sends a plaintext handshake message containing a list of supported protocol versions and encryption algorithms. Upon receiving the plaintext handshake message, the second encryption protocol processing module of the TEE VSCOK Server verifies protocol version compatibility, selects the strongest encryption algorithm supported by both parties (preferably AES-256-GCM), and returns a handshake confirmation message.

[0161] Step S3222: Key exchange.

[0162] TEE Client Libraryo uses the NIST P-256 curve to generate an asymmetric key pair (ECC) and sends the public key PubKey_CA;

[0163] The TEE VSCOK Server uses the NIST P-256 curve to generate a temporary key pair and sends the public key PubKey_TEE.

[0164] The first encryption protocol processing module of the TEE Client Library and the second encryption protocol processing module of the TEE VSCOK Server exchange public keys, namely the public key PubKey_CA and the public key PubKey_TEE. Based on the preset root key and the exchanged public key, they use the ECDH algorithm to calculate the shared key, and then derive the session key through HKDF.

[0165] Step S3223: Authentication.

[0166] The second encryption protocol processing module of the TEE VSCOK Server generates a random challenge number, signs the random challenge number using its private key, and sends the signature and certificate chain. The TEE Client Library verifies the certificate chain (the root certificate of the certificate chain is preset at system startup) and the signature to confirm the true identity of the Protected VM and prevent man-in-the-middle attacks. If verification fails, the TEE Client Library closes the connection and returns an error to the CA.

[0167] Step S3224: Activate the encrypted communication channel.

[0168] The TEE Client Library and TEE VSCOK Server initialize the AES-256-GCM encryption context using a derived Session Key, and all subsequent VSCOK messages are encrypted using AES-256-GCM. After the TEE Client Library and TEE VSCOK Server exchange encryption test messages to confirm that the channel is working properly, the handshake is complete.

[0169] This step corresponds to Figure 2 The text mentions "CA libtee SDK" and "request handshake".

[0170] Step S33: Save the connection context.

[0171] The TEE Client Library stores connection information (socket descriptor, session key, connection ID, etc.) in the TEEC_Context structure and returns TEEC_SUCCESS to the CA.

[0172] Phase 3 completed the establishment of encrypted communication channels between the Normal World and the Protected VM.

[0173] Process 2: TA loading and session establishment process.

[0174] The TA loading and session establishment process includes five stages: Normal World request encapsulation and sending, Protected VM request processing and routing, TA image verification and decryption, TA process creation and initialization, Session establishment and ID return. The following is a combination of... Figure 3 The execution process at each stage is described in detail.

[0175] Phase 1: Encapsulation and sending of Normal World requests.

[0176] Specifically, it includes the following steps S41 to S42.

[0177] Step S41: The CA calls the TEEC_OpenSession() function and specifies the UUID of the target TA. Then, it encapsulates the Session establishment request through the TEEClient Library, including:

[0178] The Session management module in the TEE Client Library receives calls;

[0179] Construct an OpenSession request message structure, which includes message type, target TA UUID, initial operation parameters, etc., and serialize the OpenSession request message structure into a byte stream.

[0180] Then, the first encryption protocol processing module is called to encrypt the OpenSession request message structure of the byte stream, that is, to use AES-256-GCM encryption to obtain ciphertext, calculate HMAC-SHA256 integrity signature, and finally assemble to obtain the Session establishment request. The format of the Session establishment request is {ciphertext, HMAC, IV, timestamp}.

[0181] This step corresponds to Figure 3 The rightmost column is logic.

[0182] Step S42: Send a Session establishment request via the VSOCK virtual device.

[0183] The VSOCK client communication module in the TEE Client Library adds a message header (including the message length) before the Session establishment request and sends it.

[0184] Phase Two: Protected VM Request Processing and Routing.

[0185] Specifically, this includes the following steps S51 to S52.

[0186] Step S51: TEE VSCOK Server receives and decrypts.

[0187] After receiving a Session establishment request with added message headers, the VSOCK server communication module in TEE VSCOK Server passes it to the second encryption protocol processing module.

[0188] Subsequently, the second encryption protocol processing module in the TEE VSCOK Server performs decryption verification, including:

[0189] Verify the timestamp, that is, check whether it is within a reasonable time window, to prevent replay attacks;

[0190] Verify the integrity of HMAC. If HMAC verification fails, reject the request and return an error. If HMAC verification passes, use AES-256-GCM to decrypt the plaintext and deserialize it to obtain the OpenSessionRequest structure.

[0191] Step S52: Session routing processing.

[0192] The Session routing module in the TEE VSCOK Server parses the message type of the Session establishment request, extracts the UUID of the target TA, and queries the TA registry to see if the corresponding target TA has been registered. If the target TA has not been registered, an error is returned; if the target TA has been registered, the executable file path of the target TA is obtained, a target TA loading request is constructed, and the target TA loading request is sent to the taloader in the TEE Runtime Environment via IPC.

[0193] Phase 3: TA Image Verification and Decryption.

[0194] Specifically, it includes the following steps S61 to S63.

[0195] Step S61: Taloader receives the TA loading request.

[0196] Step S62: Verify the integrity of the TA image, including;

[0197] Read the TA image file. The TA image format is {encrypted binary data, signature, certificate}.

[0198] Verify the certificate chain by using the pre-configured root certificate to verify the integrity and validity of the TA's certificate chain;

[0199] Signature Verification: Verify the correctness of the digital signature using the public key in the certificate chain to ensure that the encrypted binary data of the target TA has not been tampered with.

[0200] Step S63: Decrypt the TA image.

[0201] The taloader requests the decryption key for the TA from the keymaster via IPC, and uses the decryption key to decrypt the binary data of the TA using the AES decryption algorithm.

[0202] If any verification step in steps S62 and S63 fails, an error is returned.

[0203] This step corresponds to Figure 3 The middle column of logic.

[0204] Phase 4: TA process creation and initialization.

[0205] Specifically, it includes the following steps S71 to S72.

[0206] Step S71: After the TA image is verified, taloader creates the TA process.

[0207] The `fork()` function is called to create a child process, and security attributes are set within the child process. These security attributes include configuring the SELinux context to a restricted TEE domain, setting a dedicated UID / GID, and configuring process capabilities (retaining only necessary permissions). Subsequently, the decrypted binary data of the TA is written to a memory file descriptor to avoid leaving plaintext in the file system. Finally, `fexecve()` is called to execute the TA entry function, completing the creation of the subsequent TA process.

[0208] Step S72: The TA process performs initialization.

[0209] After the TA process starts, it automatically loads the libteec-internal.so library and calls TA_CreateEntryPoint() in the libteec-internal.so library to perform initialization. Then, it registers the TA process PID with the Session Manager via IPC.

[0210] This step corresponds to Figure 3 The leftmost column of logic.

[0211] Phase 5: Session establishment and ID return.

[0212] Specifically, this includes the following steps S81 to S85.

[0213] Step S81: After receiving the TA process registration, the Session Manager generates a unique Session ID using a hash algorithm.

[0214] Step S82: Create a mapping relationship between Session ID and TA process PID in the session management table.

[0215] Step S83: Send the initialization parameters to TA. TA calls the TA_OpenSessionEntryPoint() callback function to perform global initialization. The initialization result is either success or error.

[0216] Step S84: Return the TA initialization result to the Session Manager.

[0217] Step S85: The Session Manager encapsulates the initialization result and Session ID into a Session response message, which is returned to the TEE VSCOK Server via IPC. The second encryption protocol processing module of the TEE VSCOK Server encrypts the Session response message to obtain an encrypted Session response message, which is then sent back to the Normal World through the VSOCK server communication module.

[0218] The VSOCK client communication module of the TEE Client Library receives encrypted Session response messages, processes them through the first encryption protocol to decrypt and verify them, and after decryption and verification, deserializes them to obtain OpenSessionResponse. If successful, it saves the Session response information to the TEEC_Session structure and returns it to the CA. The CA then uses the corresponding Session ID in the TEEC_Session structure to call the TA service.

[0219] Process 3: TA-CA command invocation process.

[0220] The TA-CA command invocation process includes four stages: CA initiates the command, Protected VM receives the message and session, TA processes the service, and the result is returned. (The following is a summary of the process.) Figure 4 The execution process at each stage is described in detail.

[0221] Phase 1: CA initiates commands.

[0222] Specifically, this includes the following steps S91 to S95.

[0223] Step S91: The CA, carrying the Session response information obtained from step two, calls the TEE Client Library to initiate a command call request.

[0224] Step S92: The Session management module in the TEE Client Library verifies the integrity and timeliness of the Session response messages. This step corresponds to... Figure 4 "CA call command" in Chinese.

[0225] Step S93: After the Session response message is verified, the TEE Client Library constructs an InvokeCommand request message. The InvokeCommand request message includes the message type (MSG_INVOKE_COMMAND), Session ID, Command ID, and initial operation parameters. This step corresponds to... Figure 4The commands are "TEE_InvokeCommand" and "session send command".

[0226] Step S94: The first encryption protocol processing module of the TEE Client Library serializes and encrypts the InvokeCommand request message body. This step corresponds to... Figure 4 The terms "data encryption signature" and "transmission protocol encapsulation" are used.

[0227] Step S95: Send a serialized and encrypted InvokeCommand request message body through the VSOCK client communication module.

[0228] Phase Two: Message reception and Session routing on the Protected VM side.

[0229] Specifically, it includes the following steps S101 to S103.

[0230] Step S101: The VSOCK server communication module and the second encryption protocol processing module of the TEE VSCOK Server respectively receive and decrypt the serialized and encrypted InvokeCommand request message body, and forward the decrypted InvokeCommand request message body to the Session routing module.

[0231] Step S102: The Session routing module queries the Session Manager's session management table based on the Session response message in the InvokeCommand request message body to obtain the PID and communication socket of the target TA process, and then forwards the command call request to the Session Manager via IPC.

[0232] Step S109: The Session Manager forwards the command invocation request to the target TA process.

[0233] Phase 3: TA business processing.

[0234] The target TA process receives a command invocation request, calls the TA_InvokeCommandEntryPoint() callback function implemented by the TA, executes the command invocation request, and generates the execution result.

[0235] Phase 4: Results Return.

[0236] Specifically, this includes the following steps S201 to S203.

[0237] Step S121: The target TA will call the libteec-internal.so interface to return the execution results (success status, return result) to the Session Manager and TEE VSCOK Server layer by layer.

[0238] Step S122: The second encryption protocol processing module of the TEE VSCOK Server encrypts the execution result and sends it back to the VSOCK client communication module of the TEE Client Library through the VSOCK server communication module.

[0239] Step S123: The first encryption protocol processing module of the TEE Client Library decrypts and verifies the execution result, then fills it into the returnOrigin and operation structures provided by CA to complete the call.

[0240] Phases two, three, and four correspond to Figure 4 The rightmost column is logic.

[0241] The present invention has the following advantages:

[0242] 1. Utilize pKVM to run the complete monolithic kernel as a Protected VM, achieving hardware-level security isolation (equivalent to the isolation strength of a traditional Secure World).

[0243] 2. Implement the GP TEE runtime in the monolithic kernel environment of the Protected VM, and fully implement the GlobalPlatform TEE Internal API and Client API standards;

[0244] 3. TA runs as a standard user-space process and can directly use the complete Linux system calls, library functions, drivers and other ecosystem resources;

[0245] 4. Implement cross-VM communication between CA (Normal World) and TA (Protected VM) through VSOCK virtual sockets;

[0246] 5. A custom encryption protocol is used to ensure the confidentiality and integrity of cross-VM communication;

[0247] 6. Encryption during compilation using TA image ensures code integrity.

[0248] The above description is merely a preferred embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of disclosure in this application is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the foregoing disclosed concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this application.

Claims

1. A trusted application runtime system compatible with the GPTEE standard under a monolithic kernel, characterized in that: It includes a normal execution environment and a secure execution environment, which are hardware-level isolated through a hypervisor. The normal execution environment runs a standard Host OS, while the secure execution environment runs an independent monolithic kernel operating system. The hypervisor is responsible for the isolation and communication between the normal and secure execution environments, and its functions include: configuring Stage-2 page tables to achieve memory isolation; providing the VSOCK virtual device to achieve cross-VM communication; and managing the scheduling and context switching of virtual CPUs. The typical execution environment includes the Client Application for information connection and the Trusted Application Client Library. The Trusted Application Client Library provides the GlobalPlatform TEE Client API standard interface for the Client Application to call, and also implements session management, data serialization, and VSOCK communication encapsulation encryption protocol processing functions when the Client Application calls the ordinary application. The Trusted Application Client Library includes: a GP Clinent API interface implementation module, a first encryption protocol processing module for mutual information connection, a Session management module, and a VSOCK client communication module; The secure execution environment (SEA) deploys a trusted application virtual socket server, a TEE runtime environment, and trusted application processes, which are sequentially connected. The trusted application virtual socket server listens for VSOCK connection requests from the normal execution environment, establishes VSOCK connections with the normal execution environment, and responds to other requests from the normal execution environment. The TEE runtime environment assists in loading and setting up TAs and invoking CA-TA commands through information exchange with the trusted application virtual socket server and trusted application processes. The trusted application process is the actual running trusted application, existing as a standard user-mode process, used to execute command responses from the Client Application. The trusted application virtual socket server includes a VSOCK server communication module with mutual information connection, a second encryption protocol processing module, and a Session routing module.

2. A trusted application runtime system compatible with the GPTEE standard under a monolithic kernel as described in claim 1, characterized in that: The GP Clinent API implementation module provides a standard interface encapsulation for Client Applications to call; The Session management module is responsible for maintaining the session state between the Client Application and the TA in the secure execution environment, and implementing session routing; The VSOCK client communication module is responsible for establishing an encrypted communication channel with the secure execution environment and enabling information exchange with the secure execution environment. The first encryption protocol processing module is used to execute the encryption handshake protocol with the secure execution environment, maintain the encryption communication channel, and realize request encryption and response decryption.

3. A trusted application runtime system compatible with the GPTEE standard under a monolithic kernel as described in claim 2, characterized in that: The Session routing module is used by the Session management module to maintain the session state between the Client Application and the TA, and to implement session routing. The VSOCK server communication module is used to establish an encrypted communication channel with the VSOCK client communication module to realize information exchange with the VSOCK client communication module. The second encryption protocol processing module is used to execute the encryption handshake protocol with the normal execution environment, maintain the encryption communication channel, and realize request decryption and response encryption.

4. A trusted application runtime system compatible with the GPTEE standard under a monolithic kernel as described in claim 1, characterized in that: The system architecture is built through the system initialization process. After the architecture is built, the TA loading and session establishment process, as well as the CA-TA command invocation process, are implemented based on the built system architecture.

5. A trusted application runtime system compatible with the GPTEE standard under a monolithic kernel as described in claim 4, characterized in that: The system initialization process includes: The hypervisor creates a protected VM and configures Stage-2 page tables to achieve memory isolation. Deploy the VSOCK virtual appliance to establish a cross-VM communication channel; Start the monolithic kernel operating system in the Protected VM and load the TEE components in the TEE runtime environment; The Host OS establishes an encrypted communication channel with the Protected VM through an encrypted handshake protocol.

6. A trusted application runtime system compatible with the GPTEE standard under a monolithic kernel as described in claim 4, characterized in that: The TA loading and session establishment process includes: The Client Application initiates a session establishment request, and the Trusted Application Client Library encrypts the session establishment request and sends it to the Trusted Application Virtual Socket Server through an encrypted communication channel. The Trusted Application Virtual Sockets server decrypts the encrypted session establishment request and determines the TA, which is then routed to the TEE runtime environment. The TEE runtime environment verifies the integrity of the TA image and creates the TA process after the integrity verification is successful. The TEE runtime environment generates a Session ID and establishes a session mapping relationship between the Session ID and the TA process; The TA performs initialization and seals the initialization result and Session ID to generate a Session response message. The Session response message is encrypted by the Trusted Application Virtual Socket server and returned to the Trusted Application Client Library. The Trusted Application Client Library decrypts the encrypted Session response message and returns the Client Application value.

7. A trusted application runtime system compatible with the GPTEE standard under a monolithic kernel as described in claim 6, characterized in that: The CA-TA command invocation process includes: The Client Application initiates a command call request through the Session ID. The Trusted Application Client Library encrypts the command call request and sends it to the Trusted Application Virtual Socket Server through an encrypted communication channel. The Trusted Application Virtual Socket server decrypts the encrypted command call request and routes it to the TA through the TEE runtime environment; The Trusted Application Virtual Socket (TA) performs a secure operation and generates an execution result. The Trusted Application Virtual Socket (TAVPS) server encrypts the execution result and returns it to the Trusted Application Client Library via an encrypted communication channel. The Trusted Application Client Library decrypts the encrypted execution result and returns the Client Application value.

8. A trusted application runtime system compatible with the GPTEE standard under a monolithic kernel as described in claim 1, characterized in that: The TEE runtime environment includes a trusted application loading service, a session manager, a key management service, and a trusted application internal core library that are interconnected.

Images