A trusted application lifecycle security management method and system

Abstract

This invention belongs to the field of data security protection technology and discloses a trusted application lifecycle security management method and system. This method is applicable to various heterogeneous trusted execution environments (TEEs), including three entities: the TEE, the user end, and the security management service. A key exchange protocol is used to establish a secure channel between these three entities. Verifiable proofs are generated within the security management service, and each operation at each stage of the trusted application's lifecycle is recorded and signed, generating a non-repudiation track. These verifiable proofs include initialization proofs, operation proofs, freeze proofs, and deletion proofs. This invention provides a universal proof generation and verification mechanism applicable to heterogeneous TEE technology systems, ensuring non-repudiation of each lifecycle process and enabling secure management of the trusted application lifecycle. Furthermore, based on enclave state awareness and an enclave self-destruction instruction set extension, this method enables self-lifecycle management by the trusted application itself.

Description

Technical Field

[0001] The present invention relates to the field of data security protection technology, and in particular to a trusted application lifecycle security management method and system. Background Art

[0002] The statements in this section merely provide background information related to the present invention and do not necessarily constitute prior art.

[0003] A Trusted Execution Environment (TEE) is a secure computing environment that provides an isolated execution space to protect sensitive data and operations from external attacks or unauthorized access. TEEs are based on various technology systems, including those based on different hardware instruction architectures such as CISC (Complex Instruction Set Computer) and RISC (Reduced Instruction Set Computer).

[0004] Trusted applications are specialized software that run in an isolated environment called a TEE, ensuring the integrity and confidentiality of code and data. These applications are designed to process sensitive information and provide services to the real-world operating system (such as Linux / Android), allowing this sensitive information to be used without being compromised. Trusted applications only have direct access to their own data assets, such as keys, to ensure security. These applications are typically protected by digitally signed trusted credentials provided by entities trusted by the user, ensuring the application's trustworthiness. The TEE provides a security layer, preventing the code and data running on the TEE from being accessed or tampered with by the real-world operating system. Trusted applications can be viewed as execution entities within the TEE environment, leveraging the isolation and security features provided by the TEE to perform tasks requiring high security. Trusted applications are used in a variety of scenarios, including smart contracts, key management, outsourced computing, and asset management.

[0005] The lifecycle of a trusted application refers to the full management of its code and data within a trusted execution environment (TEE), including development, initialization, execution, freezing, and deletion. During the development phase, trusted applications must adhere to security best practices, including code review, test management, and source code control. This helps identify and fix security vulnerabilities during development. Initialization may also involve the generation and distribution of keys and the setting of access control policies. The execution phase is when the trusted application actively runs within the TEE. During this phase, the application processes sensitive data, performs cryptographic calculations, and maintains isolation from the external environment. The deletion phase involves the permanent removal of the trusted application's code and data from the TEE. This ensures that all sensitive information is completely erased, leaving no trace, to prevent data leakage.

[0006] However, during the trusted application lifecycle, operations can be subject to repudiation. Possible scenarios during each trusted application lifecycle are as follows. First, during the trusted application initialization phase, the enclave operator may fail to properly perform code and data integrity checks, or intentionally introduce tampering, rendering the code and data in the enclave unreliable. The operator may deny its responsibility for these checks, claiming that the integrity issues were caused by errors during development or other unknown factors, thereby denying responsibility. Alternatively, the enclave operator may attempt to obtain the trusted application's code and data by simulating its behavior, failing to initialize the enclave, and then denying its failure to initialize the enclave. Second, during the trusted application's runtime phase, the trusted application's trusted execution environment provides secure data processing services to clients, ensuring data confidentiality and integrity. The enclave operator is responsible for processing sensitive data within the enclave and returning the processing results to the client. If the data processing results are erroneous due to operator error or malicious behavior, and the client questions the accuracy of the results, the enclave operator may deny the results, claiming that the results were caused by client data errors or external factors, not the operator's responsibility. Furthermore, if a transaction involving a trusted application encounters a problem, the trusted application operator can deny the trusted application's operation by claiming that the trusted application was not executed. Thirdly, during the trusted freeze phase, the enclave operator may not execute the freeze request and replay previous user transactions to destroy or attempt to obtain the trusted application's data. Fourthly, during the trusted application deletion phase, the trusted application's data is not actually completely destroyed, but rather illegally retained or leaked. If this data is used for improper purposes, the party responsible for data destruction may deny responsibility for incomplete destruction, claiming that the data destruction was carried out in accordance with the prescribed procedures, thus resulting in repudiation.

[0007] To address these issues, trusted applications can utilize cryptography and other methods throughout their lifecycles to prevent repudiation by enclave operators. However, different TEE technologies have different technical requirements. When using trusted applications based on multiple TEE technologies, each application requires developing a cryptographic module tailored to that specific TEE technology. This means developers must write specific code for each technology to fully utilize its features. Developers also need to consider the programming language support of different TEE technologies, which may require using a specific language or converting code to a supported language. Summary of the Invention

[0008] To address the above issues, the present invention proposes a trusted application lifecycle security management method and system. This method provides a universal proof generation and verification mechanism applicable to heterogeneous trusted execution environment technology systems, making each process in the lifecycle non-repudiable and enabling secure management of the trusted application lifecycle. Furthermore, based on enclave state awareness and enclave self-destruction instruction set extensions, self-lifecycle management by the trusted application itself is enabled.

[0009] In order to achieve the above object, the present invention adopts the following technical solutions:

[0010] In a first aspect, the present invention provides a method for securely managing a trusted application lifecycle, comprising the following steps:

[0011] Applied to various heterogeneous trusted execution environments, including the trusted execution environment, the user end, and the security management service, it uses a key exchange protocol to establish a secure channel between the trusted execution environment, the user end, and the security management service. It generates verifiable proofs in the independent trusted execution environment-based security management service, records and signs every operation at each stage of the trusted application's lifecycle, and generates an irrefutable trace.

[0012] The verifiable proof includes initialization proof, operation proof, freeze proof and deletion proof.

[0013] As an optional implementation, the initialization proof includes the following steps:

[0014] The user terminal constructs and sends an initialization request for the trusted application to the trusted execution environment, and the user terminal signs the initialization request using a private key;

[0015] The trusted execution environment receives the initialization request and parses it;

[0016] The Trusted Execution Environment initializes the enclave based on the initialization request information and determines the initialization result. If the initialization is successful, it proceeds to the next step. If the initialization fails, it returns the corresponding error message.

[0017] The trusted application calls the enclave status awareness extension command to obtain the status of the enclave and determine whether the enclave is initialized successfully. If the initialization is successful, it proceeds to the next step. If the initialization fails, it returns the corresponding error information;

[0018] The security management service generates a signature based on the perceived information using the private key of the trusted execution environment, and generates an initialization certificate based on this signature and returns it to the user end;

[0019] The user end uses the initialization proof to perform subsequent proof verification.

[0020] As an optional implementation, the operation proof includes the following steps:

[0021] The user terminal constructs and sends a trusted application execution request to the trusted execution environment, and the user terminal signs the execution request using a private key;

[0022] The trusted execution environment receives the execution request and parses it;

[0023] The trusted execution environment starts the enclave and executes the trusted application based on the run request information, obtaining the execution result. If the execution is successful, it proceeds to the next step. If the execution fails, it returns the corresponding error information;

[0024] The trusted execution environment sends the execution results of the trusted application and related information of the execution request to the security management service;

[0025] The security management service generates a signature based on the relevant information using the private key of the trusted execution environment, and generates a running certificate based on this signature and returns it to the user end;

[0026] The user end uses the operation certificate to perform subsequent certificate verification work.

[0027] As an optional implementation, the freezing certificate includes the following steps:

[0028] The user terminal constructs and sends a freeze request of the trusted application to the trusted execution environment, and the user terminal signs the freeze request using a private key;

[0029] The trusted execution environment receives the freeze request and parses it;

[0030] The trusted execution environment starts the enclave and executes the trusted application based on the freeze request information to obtain the execution result. If the execution is successful, the next step is carried out. If the execution fails, the corresponding error information is returned.

[0031] The trusted execution environment sends information related to the freeze request to the security management service;

[0032] The security management service generates a signature based on the relevant information using the private key of the trusted execution environment, and generates a freezing certificate based on this signature and returns it to the user end;

[0033] The user end uses the freezing certificate for subsequent proof verification.

[0034] As an optional implementation, the deletion certificate includes the following steps:

[0035] The user terminal constructs and sends a deletion request of the trusted application to the trusted execution environment, and the user terminal signs the deletion request using a private key;

[0036] The trusted execution environment receives the deletion request and parses it;

[0037] The trusted execution environment starts the enclave and executes the trusted application based on the deletion request information, obtaining the execution result. If the execution is successful, the next step is carried out; if the execution fails, the corresponding error information is returned;

[0038] The trusted execution environment sends the relevant information of the deletion request to the security management service;

[0039] The security management service generates a signature based on the relevant information of the deletion request using the private key of the trusted execution environment, and generates a deletion certificate based on this signature and returns it to the user end;

[0040] The user end uses the deletion certificate for subsequent certificate verification.

[0041] As an optional implementation, it also includes using the remote authentication function in the trusted execution environment technology system to implement the certification process of the initialization stage and the deletion stage in the life cycle of the trusted application.

[0042] In a second aspect, the present invention provides a trusted application lifecycle security management system, which is based on the trusted application lifecycle security management method described in the first aspect and is applied to multiple heterogeneous trusted execution environments.

[0043] In a third aspect, the present invention provides an electronic device comprising a memory and a processor, and computer instructions stored in the memory and executed on the processor, wherein the computer instructions, when executed by the processor, perform the method described in the first aspect.

[0044] In a fourth aspect, the present invention provides a computer-readable storage medium for storing computer instructions, wherein when the computer instructions are executed by a processor, the method described in the first aspect is performed.

[0045] In a fifth aspect, the present invention provides a computer program product, comprising a computer program, which implements the method described in the first aspect when executed by a processor.

[0046] Compared with the prior art, the present invention has the following beneficial effects:

[0047] The present disclosure proposes a method and system for secure management of the lifecycle of trusted applications, and constructs a universal proof generation and verification mechanism, which can be provided to trusted applications based on different heterogeneous trusted execution environments. Using cryptography and other methods, verifiable proofs are generated in an independent security management service based on a trusted execution environment, so that each process of the lifecycle is non-repudiable, thereby realizing secure management of the lifecycle of trusted applications. During the initialization, execution, freezing and deletion stages of trusted applications, each operation can be recorded and signed to generate an irrefutable trace. For example, when data is modified or deleted, the relevant operations can be confirmed by digital signatures to ensure that the operator cannot deny his or her behavior. At the same time, based on its own trusted execution environment, the security management service can provide lifecycle security management services for trusted applications based on heterogeneous trusted execution environment technology systems.

[0048] Advantages of additional aspects of the present invention will be given in part in the following description and in part will be obvious from the following description, or will be learned through practice of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] The accompanying drawings, which constitute a part of the present invention, are used to provide a further understanding of the present invention. The exemplary embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute improper limitations on the present invention.

[0050] Figure 1 A trusted application lifecycle diagram provided in Example 1 of the present invention;

[0051] Figure 2 A participant diagram of the trusted application lifecycle security management method provided in Example 1 of the present invention;

[0052] Figure 3 This is an architectural diagram of the trusted application lifecycle security management method provided in Example 1 of the present invention;

[0053] Figure 4 This is a flowchart of the initialization certification of the trusted application lifecycle security management method provided in Example 1 of the present invention;

[0054] Figure 5 This is a flowchart of the operation certification of the trusted application lifecycle security management method provided in Example 1 of the present invention;

[0055] Figure 6 A flowchart of the freezing certification process of the trusted application lifecycle security management method provided in Example 1 of the present invention;

[0056] Figure 7 A flowchart of the deletion proof of the trusted application lifecycle security management method provided in Example 1 of the present invention;

[0057] Figure 8 This is an architectural diagram of a trusted application lifecycle security management method provided in Example 2 of the present invention;

[0058] Figure 9 This is a flowchart of the initialization certification of the trusted application lifecycle security management method provided in Example 2 of the present invention. DETAILED DESCRIPTION

[0059] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0060] It should be noted that the following detailed descriptions are exemplary and intended to provide further explanation of the present invention. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art to which the present invention belongs.

[0061] It should be noted that the terms used herein are only for describing specific embodiments and are not intended to limit exemplary embodiments according to the present invention. As used herein, unless the context clearly indicates otherwise, the singular form is also intended to include the plural form. In addition, it should be understood that the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0062] In the absence of conflict, the embodiments of the present invention and the features thereof may be combined with each other.

[0063] First, let’s explain the terms used in this application:

[0064] Trusted Execution Environment: We use TEE to represent this. A trusted execution environment is a secure computing environment that provides an isolated execution space to protect sensitive data and operations from external attacks or unauthorized access.

[0065] Enclave: We use E to represent it. A secure, isolated environment created by the CPU within the Trusted Execution Environment (TEE). The TEE ensures that the code and data within this enclave are protected from interference or tampering by the host operating system or other software. It enforces strict access controls and encryption to maintain the integrity and confidentiality of the enclave's contents.

[0066] Trusted Application: We use TA to represent an application in a trusted execution environment. A trusted application is a specialized software that runs in an isolated environment called a TEE to ensure the integrity and confidentiality of code and data. Trusted applications can be considered the execution entities within the TEE environment, leveraging the isolation and security features provided by the TEE to perform tasks requiring high security.

[0067] Instruction Set Architecture (ISA): This is the programming-related portion of computer architecture, encompassing basic data types, the instruction set, registers, addressing modes, the memory hierarchy, interrupts, exception handling, and external I / O. The ISA defines the interface between CPU hardware and software, specifying fundamental specifications such as the instructions, registers, and memory addressing modes supported by the processor. The ISA provides the foundation for hardware isolation and secure operation within a Trusted Execution Environment (TEE).

[0068] Security Management Service: We use SMS to represent it. It is an independent service based on the Trusted Execution Environment (TEE). It can be applied to trusted applications deployed in heterogeneous TEE technology systems, providing verifiable security management of their lifecycle.

[0069] Remote Attestation: We use RA to represent this. It is the process of verifying that a remote enclave is trustworthy. It allows a service provider to remotely verify the identity and integrity of an enclave connecting to its service.

[0070] Example 1

[0071] like Figure 3 As shown, this embodiment provides a trusted application lifecycle security management method, including the following steps:

[0072] Applied to various heterogeneous trusted execution environments, including the trusted execution environment, the user end, and the security management service, it uses a key exchange protocol to establish a secure channel between the trusted execution environment, the user end, and the security management service. It generates verifiable proofs in the independent trusted execution environment-based security management service, records and signs every operation at each stage of the trusted application's lifecycle, and generates an irrefutable trace.

[0073] Verifiable proofs include proof of initialization, proof of operation, proof of freeze, and proof of deletion.

[0074] The life cycle of a trusted application is as follows: Figure 1As shown in Figure 1, trusted applications are deployed in a variety of heterogeneous trusted execution environments and are suitable for a variety of application scenarios, including smart contracts, outsourced computing, key management, and asset management. The trusted application lifecycle includes development, initialization, execution, freezing, and deletion.

[0075] Development: The development of trusted applications includes two modules: the untrusted part and the trusted application.

[0076] a) Untrusted part: mainly consists of code running outside the trusted execution environment, including communication management with other external services, and management of the trusted execution environment running trusted applications, including initialization, start, stop and deletion operations.

[0077] b) Trusted Applications: These primarily consist of code running in a trusted execution environment, including data management and interface implementation. Data management primarily involves organizing, adding, deleting, modifying, and deleting data. Interface implementations primarily include calculation interfaces, freezing interfaces, and destruction interfaces.

[0078] Initialization: Initialization of trusted applications includes two modules: secure communication and trusted applications.

[0079] a) Secure communication: includes functions for secure communication with the user end and the security management service, specifically key exchange and secure communication after encryption using the key.

[0080] b) Trusted Application: During the initialization phase, trusted applications mainly include data initialization and code loading. The code and trusted application code are included in the data initialization. Data initialization includes data that may need to be loaded during initialization, such as keys and other information.

[0081] Execution: For the execution of trusted applications, it includes two modules: secure communication and trusted application.

[0082] a) Secure communication: includes functions for secure communication with the user end and security management services, and secure communication encrypted using keys.

[0083] b) Trusted Applications: During the execution phase, trusted applications primarily include execution parameters and data updates. Execution parameters refer to the request information, including execution parameters, that a user carries with them when initiating a call request to a trusted application. These execution parameters serve as input for the trusted application. Data updates occur after the trusted application executes the requested logic based on the execution parameters.

[0084] Freeze: Freezing of trusted applications includes two modules: secure communication and trusted applications.

[0085] a) Secure communication: includes functions for secure communication with the user end, specifically secure communication after encryption using a key.

[0086] b) Trusted Applications: Trusted applications in the freeze phase primarily include freeze flags and interface modifications. A freeze request is triggered by the user of the trusted application, which updates the freeze flag. Interface modification is performed before each interface executes its logic. It primarily checks the freeze flag. If the freeze flag is true, the interface terminates immediately, skipping the execution of the interface logic and resulting in the interface being frozen. Freezing is a pre-emptive action for subsequent deletion.

[0087] Deletion: Deletion of trusted applications includes two modules: secure communication and trusted applications.

[0088] a) Secure communication: includes functions for secure communication with the user end, specifically secure communication after encryption using a key.

[0089] b) Trusted Applications: Trusted applications during the deletion phase primarily involve data and code deletion. Data deletion can be performed using the corresponding interfaces, including clearing stored data at the code level and invoking self-destruct instructions supported by the Trusted Execution Environment (TEE). Code deletion can be performed using the corresponding interfaces, invoking self-destruct instructions supported by the TEE to destroy the entire TEE.

[0090] The main participants of the trusted application lifecycle security management method disclosed in this disclosure include the trusted execution environment owner, the trusted application owner and the security management service owner. Figure 2 As shown. Among them:

[0091] Trusted application owners: Execute trusted applications using a trusted execution environment (TEE) to ensure the privacy and security of trusted application data. They also establish secure communication with the TEE service and send management requests for the trusted application lifecycle.

[0092] Trusted Execution Environment Owner: This owner controls the server where the Trusted Execution Environment resides. This server executes trusted applications while maintaining secure communication with the user end and the security management service.

[0093] Security management service owner: It uses its own trusted execution environment to provide security management methods such as proof generation.

[0094] The overall architecture of this disclosure includes three main parts: trusted execution environment, user terminal and security management service. Figure 3 As shown. Among them:

[0095] User side: We use U to represent it. The user side is controlled by the trusted application owner and mainly includes the management of the trusted application lifecycle and the communication management, key exchange and encrypted communication required to establish a secure channel.

[0096] a) The lifecycle mainly includes the control of the lifecycle of trusted applications, the construction of related requests, and the verification of corresponding proofs.

[0097] Development: For trusted application development, support interfaces related to the entire trusted application lifecycle. Initialization and run requests are the basic interfaces for trusted applications. In addition, freeze and delete interfaces need to be developed to support the freeze and delete processes throughout the lifecycle. Optionally, reference the unified interface specifications provided by the security management service.

[0098] Initialization Request: Constructs an initialization request for a trusted application in a trusted execution environment, including the trusted application's code and initial data. This request is executed by the trusted execution environment service and initialized in the enclave.

[0099] Run Request: Constructs a run request for a trusted application. This request includes the call to the trusted application's related interfaces and parameters. The Trusted Execution Management Service's enclave completes the computation task.

[0100] Freeze Request: Constructs a freeze request for a trusted application, which freezes all interfaces of the trusted application. Optionally, a corresponding thawing interface can be provided.

[0101] Deletion request: Constructs a deletion request for a trusted application. The request is the corresponding interface of the trusted application, which performs the deletion operation of the trusted application code and data.

[0102] Proof Verification: For the lifecycle process from initialization to deletion, the security management service can generate a verifiable proof for each process. Users can verify the proof, thus completing the security management of the trusted application lifecycle.

[0103] b) Communication management mainly includes functions related to communication with trusted execution environment services.

[0104] c) Key exchange mainly includes key exchange with the enclave in the trusted execution environment service to construct a secure channel.

[0105] d) Encrypted communication: After the secure channel is established, encrypted communication is performed between the user end and the trusted execution environment service.

[0106] Trusted Execution Environment Services: We use T to represent this. Trusted Execution Environment Services are controlled by the Trusted Execution Environment owner and mainly include trusted hardware, instruction set architecture, and untrusted parts.

[0107] a) Trusted hardware: It provides an enclave environment to store the private data and code data of trusted applications. Code data includes calculation interfaces, freezing interfaces, and deletion interfaces.

[0108] b) Instruction Set Architecture: In addition to supporting the Trusted Execution Environment (TEE) instruction layer, it also provides two functions: enclave state awareness and enclave self-destruction support. Enclave state awareness enables trusted applications to obtain the status of related enclaves, while enclave self-destruction enables trusted applications to self-destruct code and data.

[0109] c) Untrusted part: mainly includes request processing, enclave management, and communication management related to secure channels, key exchange and encrypted communication.

[0110] Request processing is the process of receiving and processing relevant requests from the user. Requests mainly include initialization requests, run requests, freeze requests, and delete requests.

[0111] Enclave management includes the management of enclave initialization, startup, shutdown, and destruction.

[0112] Communication management mainly includes functions related to communication with the user end and security management services.

[0113] Key exchange mainly includes key exchange with the enclave in the security management service and the user end to construct a secure channel.

[0114] Encrypted communication: After the secure channel is established, encrypted communication is performed between the trusted execution environment service, the user end, and the security management service.

[0115] Security Management Service: We use S to represent it. The security management service is controlled by the security management service owner and mainly includes trusted hardware and untrusted parts.

[0116] a) Trusted hardware mainly includes the enclave environment, where the attestation generation operation and related cryptographic libraries are performed.

[0117] b) The non-trusted part mainly includes the security management of the trusted application life cycle, the unified interface specification provided to user development, enclave management, and communication management related to secure channels, key exchange, and encrypted communication.

[0118] Security Management: We use P to represent this. Security Management includes initialization proof, running proof, freezing proof, and deletion proof. These proofs are generated by enclaves in trusted hardware.

[0119] The unified interface specification primarily includes abstract interface definitions for each stage of the trusted application lifecycle. It specifies interface declarations, including input parameter types and return value types. Users can refer to the unified interface specification when developing trusted applications.

[0120] Enclave management includes the management of enclave initialization, startup, shutdown, and destruction.

[0121] Communication management mainly includes functions related to communication with trusted execution environment services.

[0122] Key exchange mainly includes key exchange with the enclave in the trusted execution environment service to construct a secure channel.

[0123] Encrypted communication: After the secure channel is established, encrypted communication is performed between the security management service, the user end, and the trusted execution environment service.

[0124] The method disclosed in the present invention includes initialization proof, operation proof, freezing proof and deletion proof for the security management of the trusted application life cycle. The establishment of a secure channel between the trusted execution environment and the user and the security management service uses a conventional key exchange protocol. The key exchange stage as the basis is not described in detail in the subsequent process. The unified interface specification that users refer to when developing trusted applications can be obtained from the security management service through a normal Internet channel. After a secure channel is established between the trusted execution environment and the user terminal and the security management service, the relevant communication information is encrypted by default. The encryption and decryption processes are not described in detail in the subsequent process.

[0125] Initialization proof process is as follows Figure 4 The specific process is as follows:

[0126] 1) User U first constructs a trusted application initialization request, described as Q1 = {Request_id, T_ip, Code, Parameters}. U signs the request using its private key (we assume the execution environment service T knows the corresponding public key). This signing process is described as Sig_u1 = signature(Private_U, Q1). The signature verifies U's identity, and T uses the signature to determine whether it has permission to initialize the trusted application. U sends {Q1, Sig_u1} to the trusted execution environment service T. Some attributes are described below:

[0127] a) Request_id: This request number serves as the unique identifier of the request.

[0128] b) T_ip: the network address of the trusted execution environment service T.

[0129] c) Code: The code of the trusted application TA to be initialized.

[0130] d) Parameters: Parameter data of the trusted application TA to be initialized.

[0131] e) Sig_u1: User signature for this request.

[0132] 2) The Trusted Execution Environment service T processes the received message and parses the initialization request {Q1, Sig_u1}. It first performs basic checks such as formatting. If the checks pass, it proceeds to step 3). If the checks fail, it returns the corresponding error message. Specific check items are as follows:

[0133] a) Check whether the Sig_u1 signature is correct and whether the user has the permission to initialize.

[0134] 3) The Trusted Execution Environment service T initializes the enclave based on the Code and Parameters information in Q1 and evaluates the initialization result. We describe the return result as R1 = {Enclave_id, Success, Error_msg}. If successful, proceed to step 4); if unsuccessful, the corresponding error message is returned. Some attributes are described below:

[0135] a) Enclave_id: Unique ID of the successfully initialized enclave.

[0136] b) Success: Boolean type, true indicates that the enclave initialization succeeded, false indicates that the enclave initialization failed.

[0137] c) Error_msg: When initialization fails, the error message of the failure is recorded.

[0138] 4) The trusted application (TA) calls the enclave state awareness extension command to obtain the state of the enclave and determine whether initialization was successful. We describe the enclave state as State = {Null, Init, Start, Stop, Destroy}. If successful, proceed to step 5). If not, the corresponding error message is returned. The state description is as follows:

[0139] a) Null: Indicates that the enclave does not exist.

[0140] b) Init: Indicates that the enclave has been initialized.

[0141] c) Start: Indicates that the enclave has been started.

[0142] d) Stop: Indicates that the enclave has stopped.

[0143] e)Destroy: Indicates that the enclave has been destroyed.

[0144] 5) The security management service S generates a signature based on the perceived information State using the private key of the trusted execution environment T. We describe the signature as Sig_init = signature(Private_T, Enclave_id, State). S generates an initialization proof based on this signature and returns it to the user end U. We describe the initialization proof as Proof_init = {Enclave_id, State, Sig_init}. Some attributes are described as follows:

[0145] a) Private_T: The private key of the trusted execution environment T, stored in the security management service S.

[0146] b) Enclave_id: Unique ID of the successfully initialized enclave.

[0147] c)State: Initialize the state of the enclave.

[0148] The user terminal U uses the initialization proof Proof_init to perform subsequent proof verification work.

[0149] Run the proof process as Figure 5 The specific process is as follows:

[0150] 1) User U first constructs a request to run a trusted application, described as Q2 = {Request_id, T_ip, Enclave_id, Interface_exec, Parameters}. U signs the request using its private key, describing the signing process as Sig_u2 = signature(Private_U, Q2). The signature verifies U's identity, and T determines whether it has permission to call the trusted application (or the trusted application TA determines this). U sends {Q2, Sig_u2} to the trusted execution environment service T. Some attributes are described below:

[0151] a) Request_id: This request number serves as the unique identifier of the request.

[0152] b) T_ip: the network address of the trusted execution environment service T.

[0153] c) Enclave_id: unique ID of the enclave to be run.

[0154] d) Interface_exec: the interface of the trusted application TA to be executed.

[0155] e) Parameters: interface parameter data of the trusted application TA to be run.

[0156] f) Sig_u2: User signature for this request

[0157] 2) The Trusted Execution Environment service T processes the received message and parses the initialization request {Q2, Sig_u2}. It first performs basic checks such as formatting. If the checks pass, it proceeds to step 3. If the checks fail, it returns the corresponding error message. Specific check items are as follows:

[0158] a) Check whether the Sig_u2 signature is correct and whether the user has permission to run trusted applications.

[0159] 3) The trusted execution environment service T starts the enclave Enclave_id and executes the trusted application TA based on the Interface_exec and Parameters information in Q2, obtaining the execution result. If the execution is successful and the result is returned, step 4) is performed. If the execution fails due to an exception, the corresponding error message is returned. We describe this execution result as R2 = {Enclave_id, Success, Error_msg, Result}. If successful, step 4) is performed. If failed, the corresponding error message is returned. Some attributes are described below:

[0160] a) Enclave_id: unique enclave ID.

[0161] b) Success: Boolean type, true indicates successful operation, false indicates failure.

[0162] c) Error_msg: When initialization fails, the error message of the failure is recorded.

[0163] d)Result: The result returned after successful execution.

[0164] 4) The trusted execution environment service T sends information related to R2 and Q2 to the security management service. We describe this information as Exec_msg = {Enclave_id, Result, Request_id}.

[0165] 5) The security management service S generates a signature based on Exec_msg using the private key of the trusted execution environment T. We describe this signature as Sig_exec = signature(Private_T, Exec_msg). S generates an execution proof based on this signature and returns it to the user U. We describe this execution proof as Proof_exec = {Enclave_id, Exec_msg, Sig_exec}.

[0166] The user terminal U uses the execution proof Proof_exec to perform subsequent proof verification work.

[0167] Freeze certification process Figure 6 The specific process is as follows:

[0168] 1) User U first constructs a freeze request for the trusted application, described as Q3 = {Request_id, T_ip, Enclave_id, Interface_freeze, Parameters}. U signs the request using its private key, described as Sig_u3 = signature(Private_U, Q3). The signature verifies U's identity, and T determines whether it has permission to call the trusted application (or the trusted application TA determines this). U sends {Q3, Sig_u3} to the trusted execution environment service T. Some attributes are described below:

[0169] a) Request_id: This request number serves as the unique identifier of the request.

[0170] b) T_ip: the network address of the trusted execution environment service T.

[0171] c) Enclave_id: The enclave ID of the trusted application to be frozen.

[0172] d) Interface_freeze: The interface of the trusted application TA to be frozen.

[0173] e) Parameters: Interface parameter data of the trusted application TA to be frozen. Boolean type, true indicates freezing, and false indicates unfreezing.

[0174] f) Sig_u3: User signature for this request.

[0175] 2) The Trusted Execution Environment service T processes the received message and parses the initialization request {Q3, Sig_u3}. It first performs basic checks such as formatting. If the checks pass, it proceeds to step 3. If the checks fail, it returns the corresponding error message. Specific check items are as follows:

[0176] a) Check whether the Sig_u3 signature is correct and whether the user has permission to run trusted applications.

[0177] 3) The trusted execution environment service T starts the enclave Enclave_id and executes the trusted application TA based on the Interface_freeze and Parameters information in Q3, obtaining the execution result. If the execution is successful and the result is returned, step 4 is performed. If the execution fails due to an exception, the corresponding error message is returned. We describe this execution result as R3 = {Enclave_id, Success, Error_msg}. After successful execution, the trusted application's computing-related runtime interfaces cannot be called. Deleting the process interface has no impact; optionally, the unfrozen interface is retained. Some attributes are described below:

[0178] a) Enclave_id: unique enclave ID.

[0179] b) Success: Boolean type, true indicates successful operation, false indicates failure.

[0180] c) Error_msg: When initialization fails, the error message of the failure is recorded.

[0181] 4) The trusted execution environment service T sends freeze-related information to the security management service S. We describe this information as Freeze_msg = {Enclave_id, Success, Request_id}.

[0182] 5) Security management service S generates a signature based on Freeze_msg using the private key of trusted execution environment T. We describe this signature as Sig_freeze = signature(Private_T, Freeze_msg). S generates a freeze proof based on this signature and returns it to user U. We describe the freeze proof as Proof_freeze = {Enclave_id, Freeze_msg, Sig_freeze}.

[0183] The user terminal U uses the freezing proof Proof_freeze to perform subsequent proof verification.

[0184] Deletion certification process Figure 7 The specific process is as follows:

[0185] 1) User U first constructs a trusted application deletion request, described as Q4 = {Request_id, T_ip, Enclave_id, Interface_delete}. U signs the request using its private key, described as Sig_u4 = signature(Private_U, Q4). The signature verifies U's identity, and T determines whether it has permission to call the trusted application (or the trusted application TA determines this). U sends {Q4, Sig_u4} to the trusted execution environment service T. Some attributes are described below:

[0186] a) Request_id: This request number serves as the unique identifier of the request.

[0187] b) T_ip: the network address of the trusted execution environment service T.

[0188] c) Enclave_id: The enclave ID of the trusted application to be deleted.

[0189] d)Interface_delete: The interface of the trusted application TA to be deleted.

[0190] 2) The Trusted Execution Environment service T processes the received message and parses the initialization request {Q4, Sig_u4}. It first performs basic checks such as formatting. If the checks pass, it proceeds to step 3. If the checks fail, it returns the corresponding error message. Specific check items are as follows:

[0191] a) Check whether the Sig_u4 signature is correct and whether the user has permission to run trusted applications.

[0192] 3) The trusted execution environment service T starts the enclave Enclave_id and executes the trusted application TA based on the Interface_delete information in Q4, obtaining the execution result. If the execution is successful and the result is returned, the process proceeds to step 4). If the execution fails due to an exception, the corresponding error message is returned. We describe this execution result as R4 = {Enclave_id, Success, Error_msg}.

[0193] 4) The trusted execution environment service T sends deletion related information to the security management service S. We describe this information as Delete_msg={Enclave_id, Success, Request_id}.

[0194] 5) The security management service S generates a signature based on Delete_msg using the private key of the trusted execution environment T. We describe this signature as Sig_delete = signature(Private_T, Delete_msg). S generates a deletion proof based on this signature and returns it to the user U. We describe this deletion proof as Proof_delete = {Enclave_id, Delete_msg, Sig_delete}.

[0195] The user terminal U uses the deletion proof Proof_delete to perform subsequent proof verification work.

[0196] The Trusted Execution Environment service T and the Security Management service S can optionally retain relevant attestation data, allowing the user end U to selectively verify attestations at various points in the trusted application lifecycle. The core verification logic verifies the validity of the enclave signature in the attestation. Alternatively, users can leverage the remote authentication capabilities of the enclave's technology architecture to verify the authenticity of the enclave. Users can also configure the attestation generation process to include a random nonce to prevent replay attacks.

[0197] The following describes the instruction set ISA extensions: the enclave state awareness instruction set extension, which records enclave initialization, startup, shutdown, and destruction status information at the hardware level; and the enclave self-destruction instruction set extension, which supports enclave self-destruction initiated by trusted applications at the hardware level.

[0198] Example 2

[0199] It also includes using the remote authentication function in the trusted execution environment technology system to implement the certification process of the initialization stage and deletion stage in the trusted application life cycle. The security management of the development, operation and freezing stages in the trusted application life cycle is the same as that in Example 1.

[0200] During the initialization phase of the lifecycle, the security management service S remotely authenticates the enclave within the trusted execution environment service T. The deletion phase is triggered by the user and involves the destruction of the enclave within the untrusted portion of the trusted execution service. This is supported by proof of destruction (i.e., signing the destruction result) within the instruction set architecture, and verified using the remote attestation component of the trusted execution environment technology architecture.

[0201] The architecture of this embodiment is as follows Figure 8 The main changes are as follows:

[0202] 1) The instruction set architecture part of the trusted execution environment service T includes support for enclave destruction proof.

[0203] 2) The security management part of the security management service S removes the deletion certificate part.

[0204] 3) Added remote verification services, including authentication verification and deletion proof verification. Authentication verification is the remote authentication function in the original Trusted Execution Environment technology system, supplemented by the deletion proof verification function.

[0205] The initialization proof process of this embodiment is as follows Figure 9 The specific process is as follows:

[0206] 1) User U first constructs a trusted application initialization request, described as Q1 = {Request_id, T_ip, Code, Parameters}. U signs the request using its private key (we assume the execution environment service T knows the corresponding public key). This signing process is described as Sig_u1 = signature(Private_U, Q1). The signature verifies U's identity, and T uses the signature to determine whether it has permission to initialize the trusted application. U sends {Q1, Sig_u1} to the trusted execution environment service T. Some attributes are described below:

[0207] a) Request_id: This request number serves as the unique identifier of the request.

[0208] b) T_ip: the network address of the trusted execution environment service T.

[0209] c) Code: The code of the trusted application TA to be initialized.

[0210] d) Parameters: Parameter data of the trusted application TA to be initialized.

[0211] e) Sig_u1: User signature for this request.

[0212] 2) The Trusted Execution Environment service T processes the received message and parses the initialization request {Q1, Sig_u1}. It first performs basic checks such as formatting. If the checks pass, it proceeds to step 3). If the checks fail, it returns the corresponding error message. Specific check items are as follows:

[0213] a) Check whether the Sig_u1 signature is correct and whether the user has the permission to initialize.

[0214] 3) The Trusted Execution Environment service T initializes the enclave based on the Code and Parameters information in Q1 and evaluates the initialization result. We describe the return result as R1 = {Enclave_id, Success, Error_msg}. If successful, proceed to step 4); if unsuccessful, the corresponding error message is returned. Some attributes are described below:

[0215] a) Enclave_id: Unique ID of the successfully initialized enclave.

[0216] b) Success: Boolean type, true indicates that the enclave initialization succeeded, false indicates that the enclave initialization failed.

[0217] c) Error_msg: When initialization fails, the error message of the failure is recorded.

[0218] 4) Security Management Service S remotely authenticates the enclave and evaluates the authentication result. If successful, it proceeds to step 5). If unsuccessful, it returns the corresponding error message. We describe the authentication result as R_attestation = {Enclave_id, Success, Error_msg}. If successful, it proceeds to step 5). If unsuccessful, it returns the corresponding error message. Some attributes are described below:

[0219] a) Enclave_id: Unique ID of the successfully initialized enclave.

[0220] b) Success: Boolean type, true indicates successful authentication, false indicates failed authentication.

[0221] c) Error_msg: When initialization fails, the error message of the failure is recorded.

[0222] 5) The security management service generates a signature based on the attestation result R_attestation using the private key of the trusted execution environment T. We describe the signature as Sig_init = signature(Private_T, Enclave_id, Success). S generates an initialization proof based on this signature and returns it to the user end U. We describe the initialization proof as Proof_init = {Enclave_id, State, Sig_init}. Some attributes are described as follows:

[0223] a) Private_T: The private key of the trusted execution environment T, stored in the security management service S.

[0224] b) Enclave_id: Unique ID of the successfully initialized enclave.

[0225] c) Success: The authentication result is true.

[0226] The user terminal U uses the initialization proof Proof_init to perform subsequent proof verification work.

[0227] Example 3

[0228] This embodiment provides a trusted application lifecycle security management system, which is based on the trusted application lifecycle security management method described in Example 1 and is applied to multiple heterogeneous trusted execution environments.

[0229] In further embodiments, there is also provided:

[0230] An electronic device includes a memory and a processor, and computer instructions stored in the memory and executed by the processor, wherein when the computer instructions are executed by the processor, the method described in Example 1 is performed. For the sake of brevity, no further details are given here.

[0231] It should be understood that in this embodiment, the processor may be a central processing unit (CPU), or may be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), off-the-shelf field-programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor, etc.

[0232] The memory may include a read-only memory and a random access memory, and provides instructions and data to the processor. A portion of the memory may also include a non-volatile random access memory. For example, the memory may also store information about the device type.

[0233] A computer-readable storage medium is used to store computer instructions, and when the computer instructions are executed by a processor, the method described in Example 1 is performed.

[0234] The method in Example 1 can be directly implemented as a hardware processor, or can be implemented using a combination of hardware and software modules in the processor. The software module can be located in a storage medium mature in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, etc. The storage medium is located in the memory, and the processor reads the information in the memory and, in conjunction with its hardware, completes the steps of the above method. To avoid repetition, it will not be described in detail here.

[0235] A computer program product includes a computer program, which implements the method described in embodiment 1 when executed by a processor.

[0236] The present invention also provides at least one computer program product tangibly stored on a non-transitory computer-readable storage medium. The computer program product includes computer-executable instructions, such as instructions contained in program modules, which are executed in a device on a real or virtual processor of a target to perform the process / method described above. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, etc. that perform specific tasks or implement specific abstract data types. In various embodiments, the functionality of program modules can be combined or divided between program modules as needed. The machine-executable instructions for the program modules can be executed in local or distributed devices. In distributed devices, program modules can be located in local and remote storage media.

[0237] The computer program code for implementing the method of the present invention can be written in one or more programming languages. These computer program codes can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device so that when the program code is executed by the computer or other programmable data processing device, the functions / operations specified in the flow chart and / or block diagram are implemented. The program code can be executed entirely on a computer, partially on a computer, as an independent software package, partially on a computer and partially on a remote computer, or entirely on a remote computer or server.

[0238] In the context of the present invention, computer program code or related data can be carried by any appropriate carrier to enable a device, apparatus, or processor to perform the various processes and operations described above. Examples of carriers include signals, computer-readable media, and the like. Examples of signals include electrical, optical, radio, acoustic, or other forms of propagated signals, such as carrier waves, infrared signals, and the like.

[0239] Those skilled in the art will appreciate that the units and algorithm steps of the various examples described in conjunction with this embodiment can be implemented in electronic hardware or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0240] Although the above describes the specific embodiments of the present invention in conjunction with the accompanying drawings, it is not intended to limit the scope of protection of the present invention. Those skilled in the art should understand that various modifications or variations that can be made by those skilled in the art on the basis of the technical solution of the present invention without any creative work are still within the scope of protection of the present invention.

Claims

1. A trusted application lifecycle security management method, characterized in that: Applied to various heterogeneous trusted execution environments, including the trusted execution environment, the user end, and the security management service, it uses a key exchange protocol to establish a secure channel between the trusted execution environment, the user end, and the security management service. It generates verifiable proofs in the independent trusted execution environment-based security management service, records and signs every operation at each stage of the trusted application's lifecycle, and generates an irrefutable trace. The verifiable proof includes the following steps: The user terminal constructs and sends a verifiable attestation request of the trusted application to the trusted execution environment, and the user terminal signs the verifiable attestation request using a private key; The trusted execution environment receives and parses the verifiable attestation request; The trusted execution environment starts the enclave and executes the trusted application based on the verifiable proof request information, obtaining the execution result. If the execution is successful, the next step is carried out. If the execution fails, the corresponding error information is returned. The trusted execution environment sends the trusted application execution results and relevant information of the verifiable attestation request to the security management service; The security management service generates a signature based on the relevant information using the private key of the trusted execution environment, and generates a verifiable proof based on this signature and returns it to the user end; The user uses the verifiable proof to perform subsequent proof verification work; The verifiable proof includes initialization proof, operation proof, freeze proof and deletion proof.

2. A trusted application lifecycle security management method according to claim 1, characterized in that: The deletion certificate The following steps are involved: The user terminal constructs and sends a deletion request of the trusted application to the trusted execution environment, and the user terminal signs the deletion request using a private key; The trusted execution environment receives the deletion request and parses it; The trusted execution environment starts the enclave and executes the trusted application based on the deletion request information, obtaining the execution result. If the execution is successful, the next step is carried out; if the execution fails, the corresponding error information is returned; The trusted execution environment sends the relevant information of the deletion request to the security management service; The security management service generates a signature based on the relevant information of the deletion request using the private key of the trusted execution environment, and generates a deletion certificate based on this signature and returns it to the user end; The user end uses the deletion certificate for subsequent certificate verification.

3. A trusted application lifecycle security management method according to claim 1, characterized in that: It also includes using the remote authentication function in the trusted execution environment technology system to implement the certification process of the initialization stage and deletion stage in the trusted application life cycle.

4. A trusted application lifecycle security management system, characterized in that: A trusted application lifecycle security management method according to claim 1 is applied to a variety of heterogeneous trusted execution environments.

5. An electronic device, characterized in that: The method comprises a memory and a processor, and computer instructions stored in the memory and executed on the processor, wherein when the computer instructions are executed by the processor, the method according to any one of claims 1 to 3 is completed.

6. A computer-readable storage medium, characterized in that Used to store computer instructions, which, when executed by a processor, complete the method according to any one of claims 1 to 3.

7. A computer program product, characterized in that The invention comprises a computer program, which is used to implement the method according to any one of claims 1 to 3 when executed by a processor.

Images