Trusted application life cycle safety management method and system

Abstract

The invention belongs to the technical field of data security protection, and discloses a trusted application life cycle security management method and system, which is applied to various heterogeneous trusted execution environments, and comprises three main bodies, namely a trusted execution environment, a user side and a security management service, and a security channel is established among the three main bodies by using a key exchange protocol. Generating a verifiable proof in the security management service, recording and signing each operation of each stage of the life cycle of the trusted application, and generating a non-repudiation track; the verifiable certification comprises an initialization certification, an operation certification, a freezing certification and a deletion certification. The invention provides a universal proof generation and verification mechanism, which is suitable for a heterogeneous trusted execution environment technology system, so that each process of the life cycle is not repudiated, the safety management of the trusted application life cycle is realized, and in addition, based on enclave state perception and enclave self-destruction instruction set extension, the safety of the trusted application life cycle is improved. And the self life cycle management of the trusted application is realized.

Description

Technical Field

[0001] The present invention relates to the technical field of data security protection, 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] Trusted Execution Environment (TEE) is a secure computing environment. It provides an isolated execution space to protect sensitive data and operations from external attacks or unauthorized access. Trusted Execution Environment has multiple technical systems, including different hardware instruction architecture sets based on CISC (Complex Instruction Set Computer) and RISC (Reduced Instruction Set Computer).

[0004] Trusted applications are special software that runs in an isolated environment called TEE to ensure the integrity and confidentiality of code and data. These applications are designed to process sensitive information and provide services to the normal world operating system (such as Linux / Android) so that this sensitive information can be used without being leaked. Trusted applications can only directly access their own data assets, such as keys, to ensure security. They are usually protected by digitally signed trusted credentials, which are provided by entities trusted by the user, ensuring the trustworthiness of the application. TEE provides a security layer so that the code and data running on the TEE cannot be accessed or tampered with by the normal world operating system. Trusted applications can be regarded as execution entities in the TEE environment. They use the isolation and security features provided by TEE to perform tasks that require high security. Trusted applications have a variety of application scenarios including smart contracts, key management, outsourced computing, and asset management.

[0005] The lifecycle of a trusted application refers to the full-process management of its code and data in a trusted execution environment (TEE), including processes such as development, initialization, execution, freezing, and deletion. During the development phase, the development of trusted applications needs to follow security best practices, including code inspection, test management, and source code control. This helps to identify and fix security vulnerabilities during the development phase. Initialization may also involve the generation and distribution of keys, as well as setting access control policies. The execution phase is the period when the trusted application is actively running in the TEE. During this phase, the application processes sensitive data, performs cryptographic calculations, and remains isolated from the external environment. The deletion phase involves the code and data of the trusted application being permanently removed from the TEE. This requires ensuring that all sensitive information is completely cleared without leaving any traces to prevent data leakage.

[0006] However, during the life cycle of a trusted application, related operations may be denied. The following scenarios may exist in each life cycle of a trusted application. First, during the initialization phase of a trusted application, the enclave operator fails to correctly perform integrity checks on the code and data, or deliberately introduces tampering, resulting in unreliable code and data in the enclave. The operator may deny its responsibility for the check, claiming that the integrity issues of the code and data are caused by errors in the development process or other unknown factors, thereby denying its responsibility. In addition, the enclave operator may not successfully initialize the enclave, but simulate the behavior of the enclave to try to obtain the code and data of the trusted application, and deny its failure to successfully initialize the enclave. Second, during the operation phase of a trusted application, the trusted execution environment of the trusted application provides secure data processing services to customers to ensure the confidentiality and integrity of the data. The enclave operator is responsible for processing sensitive data in the enclave and returning the processing results to the customer. If the data processing results are incorrect due to the operator's mistakes or malicious behavior, when the customer questions the accuracy of the results, the enclave operator may deny it, claiming that the results are caused by the customer's data errors or external factors, not the operator's responsibility. In addition, when a transaction problem related to a trusted application occurs, the trusted application operator can generate a statement that the trusted application was not executed, denying the operation of the related trusted application. Third, during the trusted freezing phase, the enclave operator may not execute the freezing request, and replay the previous user's transaction to destroy or attempt to obtain the data of the trusted application. Fourth, during the deletion phase of the trusted application, the data of the trusted application is not actually completely destroyed, but illegally retained or leaked. When this data is used for improper purposes, the party responsible for data destruction may deny its responsibility for incomplete destruction, claiming that the data destruction has been carried out in accordance with the prescribed procedures, resulting in denial.

[0007] To address the above issues, trusted applications can choose to use cryptography and other methods to prevent enclave operators from denying their rights during the corresponding life cycle. However, different TEE technologies have different technical requirements. When there are trusted applications based on multiple TEE technologies at the same time, each application needs to develop a corresponding cryptographic module for a specific TEE technology. This means that developers need to write specific code for each technology to fully utilize these features. At the same time, developers also need to consider the support of different TEE technologies for programming languages, which means that developers may need to use specific languages ​​or convert the code to supported languages. Summary of the invention

[0008] In order to solve the above problems, the present invention proposes a trusted application lifecycle security management method and system, provides a universal proof generation and verification mechanism, and is applicable to a heterogeneous trusted execution environment technology system, so that each process of the lifecycle is non-repudiable, thereby realizing the secure management of the trusted application lifecycle. In addition, based on the enclave state perception and the enclave self-destruction instruction set extension, the trusted application itself realizes the lifecycle management.

[0009] In order to achieve the above object, the present invention adopts the following technical solution: In a first aspect, the present invention provides a trusted application lifecycle security management method, comprising the following steps: Applied to various heterogeneous trusted execution environments, including the trusted execution environment, the user end, and the security management service, the key exchange protocol is used to establish a secure channel between the trusted execution environment, the user end, and the security management service, and verifiable proofs are generated in the independent security management service based on the trusted execution environment. Each operation at each stage of the entire life cycle of the trusted application is recorded and signed to generate an irrefutable track. The verifiable proofs include initialization proof, operation proof, freezing proof and deletion proof.

[0010] As an optional implementation, the initialization proof includes the following steps: The user terminal constructs and sends an initialization request for a trusted application to the trusted execution environment, and the user terminal signs the initialization request using a private key; The trusted execution environment receives the initialization request and parses it; The trusted execution environment initializes the enclave based on the information of the initialization request 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 information. 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, the corresponding error message is returned; 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 the signature and returns it to the user end; The user end uses the initialization proof to perform subsequent proof verification work.

[0011] As an optional implementation, the operation proof includes the following steps: The user terminal constructs and sends a running request of the trusted application to the trusted execution environment, and the user terminal signs the running request using a private key; The trusted execution environment receives the execution request and parses it; The trusted execution environment starts the enclave and executes the trusted application based on the information of the run request to obtain the execution result. If the execution is successful, the next step is performed. If the execution fails, the corresponding error information is returned; The trusted execution environment sends the execution results of the trusted application and related information of the running 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 running certificate based on the signature and returns it to the user end; The user end uses the operation certificate to perform subsequent certificate verification work.

[0012] As an optional implementation, the freezing certificate includes the following steps: 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; The trusted execution environment receives the freeze request and parses it; 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 performed. If the execution fails, the corresponding error information is returned. The trusted execution environment sends the relevant information of the freeze 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 freezing certificate based on the signature and returns it to the user end; The user end uses the freezing certificate for subsequent certificate verification.

[0013] As an optional implementation, the deletion proof includes the following steps: 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 to obtain the execution result. If the execution is successful, the next step is performed. 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 the signature and returns it to the user end; The user end uses the deletion certificate to perform subsequent certificate verification work.

[0014] 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.

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

[0016] 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 when the computer instructions are executed by the processor, the method described in the first aspect is performed.

[0017] 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.

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

[0019] Compared with the prior art, the present invention has the following beneficial effects: The present disclosure proposes a trusted application lifecycle security management method and system, constructs a universal proof generation and verification mechanism, and 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 life cycle is non-repudiable, thereby achieving secure management of the trusted application lifecycle. During the initialization, execution, freezing, and deletion stages of the trusted application, each operation can be recorded and signed to generate an irrefutable track. For example, when data is modified or deleted, the relevant operations can be confirmed by a digital signature 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 a heterogeneous trusted execution environment technology system.

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

[0021] The accompanying drawings in the specification, 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.

[0022] Figure 1 A trusted application life cycle diagram provided in Example 1 of the present invention; Figure 2 A participant diagram of the trusted application lifecycle security management method provided in Example 1 of the present invention; Figure 3 An architectural diagram of a trusted application lifecycle security management method provided in Example 1 of the present invention; Figure 4 A flowchart of initialization certification of a trusted application lifecycle security management method provided in Example 1 of the present invention; Figure 5 A flowchart of the operation certification of the trusted application lifecycle security management method provided in Example 1 of the present invention; Figure 6 A freezing certification flow chart of the trusted application lifecycle security management method provided in Example 1 of the present invention; Figure 7 A deletion proof flow chart of the trusted application lifecycle security management method provided in Example 1 of the present invention; Figure 8 An architectural diagram of a trusted application lifecycle security management method provided in Example 2 of the present invention; Fig. 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

[0023] The present invention will be further described below in conjunction with the accompanying drawings and embodiments.

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

[0025] 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 "include" and "have" and any of their variations 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.

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

[0027] First, the nouns involved in this application are explained: Trusted Execution Environment: We use TEE to represent it. A trusted execution environment is a secure computing environment. It provides an isolated execution space to protect sensitive data and operations from external attacks or unauthorized access.

[0028] Enclave: We use E to represent it. A secure isolated environment created by the CPU in a trusted execution environment. The trusted execution environment ensures that the code and data within this enclave are protected from interference or tampering by the host operating system or other software. It implements strict access control and encryption measures to maintain the integrity and confidentiality of the enclave content.

[0029] Trusted Application: We use TA to represent an application in a trusted execution environment. A trusted application is a special software that runs in an isolated environment called TEE to ensure the integrity and confidentiality of code and data. Trusted applications can be regarded as the execution subject in the TEE environment. They use the isolation and security features provided by TEE to perform tasks that require high security.

[0030] Instruction Set Architecture: We use ISA to represent it. It is the part of computer architecture related to programming, which includes basic data types, instruction sets, registers, addressing modes, storage systems, interrupts, exception handling, and external I / O. ISA defines the interface between CPU hardware and software, and it specifies the basic specifications such as instructions, registers, and memory addressing modes supported by the processor. ISA provides the basis for hardware isolation and secure operation of the trusted execution environment.

[0031] Security Management Service: We use SMS to represent it. It is an independent service based on the trusted execution environment, which can be applied to trusted applications deployed in heterogeneous trusted execution environment technology systems to perform verifiable security management on their life cycle.

[0032] Remote Attestation: We use RA to represent it. It is the process of verifying whether a remote enclave is trustworthy. It allows service providers to remotely verify the identity and integrity of enclaves connected to their services.

[0033] Example 1 like Figure 3 As shown, this embodiment provides a trusted application lifecycle security management method, including the following steps: Applied to various heterogeneous trusted execution environments, including the trusted execution environment, the user end, and the security management service, the key exchange protocol is used to establish a secure channel between the trusted execution environment, the user end, and the security management service, and verifiable proofs are generated in the independent security management service based on the trusted execution environment. Each operation at each stage of the entire life cycle of the trusted application is recorded and signed to generate an irrefutable track. Verifiable proofs include initialization proof, operation proof, freeze proof, and deletion proof.

[0034] The life cycle of a trusted application is as follows: Figure 1 As 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 life cycle includes processes such as development, initialization, execution, freezing, and deletion.

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

[0036] a) Untrusted part: mainly the 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 delete operations.

[0037] b) Trusted Application: mainly refers to the code running in the trusted execution environment, including data management and interface implementation. Data management mainly involves the organization, addition, deletion, modification and deletion of data. Interface implementation mainly includes calculation interface, freezing interface and destruction interface.

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

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

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

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

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

[0043] b) Trusted Application: Trusted applications in the execution phase mainly include execution parameters and data updates. Execution parameters refer to the request information such as execution parameters carried when the user initiates a call request for a trusted application. The execution parameters are used as the execution input of the trusted application. Data updates refer to the data updates of the trusted application caused by the trusted application executing the logic of the corresponding request according to the execution parameters.

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

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

[0046] b) Trusted Application: Trusted applications in the freezing stage mainly include freeze marks and interface modifications. The freeze request is triggered by the user who owns the trusted application. After the request is triggered, the freeze mark is updated. Interface modification is the part executed by each interface before executing the interface logic, mainly for the judgment of the freeze mark. If the freeze mark is true, the interface ends directly, that is, the execution of the interface logic part is skipped, which is manifested as the effect of interface freezing. Freezing is a pre-action for subsequent deletion.

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

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

[0049] b) Trusted applications: Trusted applications in the deletion phase mainly include data deletion and code deletion. Data deletion can be operated by the corresponding interface, including cleaning up the stored data at the code level and calling the self-destruction instructions supported by the trusted execution environment level. Code deletion can be operated by the corresponding interface, calling the self-destruction instructions supported by the trusted execution environment level to destroy the entire trusted execution environment.

[0050] The main participants of the trusted application lifecycle security management method disclosed in the present invention include the trusted execution environment owner, the trusted application owner and the security management service owner. Figure 2 As shown. Among them: Trusted application owner: Use the trusted execution environment to execute trusted applications and ensure the privacy and security of trusted application data. At the same time, establish secure communication with the trusted execution environment service and send management requests for the trusted application life cycle.

[0051] Trusted Execution Environment Owner: This owner can control the server where the trusted execution environment is located. The server executes trusted applications while maintaining secure communication with the user end and the security management service.

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

[0053] The overall architecture of the present disclosure includes three main parts: trusted execution environment, user end, and security management service. Figure 3 As shown. Among them: 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 life cycle and the communication management, key exchange and encrypted communication required to establish a secure channel.

[0054] a) The life cycle mainly includes the control of the life cycle of the trusted application, the construction of related requests and the verification of the corresponding proofs.

[0055] Development: For the development of trusted applications, support interfaces related to the entire life cycle of trusted applications. Initialization request and run request are the basic interfaces of trusted applications. In addition, freeze and delete interfaces need to be developed to support the freeze and delete process in the life cycle. Optionally, refer to the unified interface specification provided by the security management service.

[0056] Initialization request: Constructs an initialization request for the trusted application in the trusted execution environment, including the trusted application code and initial data. The request is executed by the trusted execution environment service and initialized in the enclave.

[0057] Run request: Construct a run request for a trusted application, which contains the call and parameters of the trusted application related interface. The enclave of the trusted execution management service completes the computing task.

[0058] Freeze request: Construct a freeze request for a trusted application, which will freeze all interfaces of the trusted application. Optionally, a corresponding thawing interface can be provided.

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

[0060] Proof Verification: For the process from initialization to deletion of the life cycle, the security management service can generate a verifiable proof for each process. Users can verify the proof to complete the security management of the trusted application life cycle.

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

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

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

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

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

[0066] b) Instruction set architecture: In addition to supporting the trusted execution environment instruction level, it also provides two functions: enclave state awareness and enclave self-destruction support. Among them, enclave state awareness enables trusted applications to obtain the status of related enclaves, and enclave self-destruction enables trusted applications to self-destruct code and data.

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

[0068] Request processing is to receive relevant requests sent from the user end and process them accordingly. Requests mainly include initialization requests, run requests, freeze requests and delete requests.

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

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

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

[0072] Encrypted communication. After the secure channel is established, the trusted execution environment service conducts encrypted communication with the user end and the security management service.

[0073] 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.

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

[0075] 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.

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

[0077] The unified interface specification mainly includes abstract interface definitions for each stage of the trusted application life cycle, and specifies interface declarations, including input parameter types and return value types. Users can refer to the unified interface specification for implementation when developing trusted applications.

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

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

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

[0081] Encrypted communication. After the secure channel is established, the security management service conducts encrypted communication with the user end and the trusted execution environment service.

[0082] The method disclosed in the present invention includes initialization proof, operation proof, freezing proof and deletion proof for the security management of the life cycle of trusted applications. 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, and 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, and the encryption and decryption processes are not described in detail in the subsequent process.

[0083] The initialization proof process is as follows Figure 4 The specific process is as follows: 1) The user U first constructs an initialization request for the trusted application. We describe this request as Q1={Request_id, T_ip, Code, Parameters}. U signs the request using a private key (we assume that the executable environment service T knows the corresponding public key). We describe the signing process as Sig_u1=signature(Private_U,Q1). The signature is intended to prove U's identity, and T determines whether it has the authority to initialize the trusted application through the signature. U sends {Q1, Sig_u1} to the trusted execution environment service T. Some attributes are described as follows: a) Request_id: This is the request number, which is used as the unique identifier of this request.

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

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

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

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

[0088] 2) The trusted execution environment service T processes the received message and parses the initialization request {Q1, Sig_u1}, first performing basic checks such as format. If the check passes, proceed to step 3), otherwise the corresponding error message is returned. The specific check items are as follows: a) Check whether the Sig_u1 signature is correct and whether the user has the permission to initialize.

[0089] 3) The trusted execution environment service T initializes the enclave based on the Code and Parameters information in Q1, and judges the initialization result. We describe the return result as R1={Enclave_id, Success, Error_msg}. If successful, proceed to step 4, if failed, return the corresponding error information. Some attributes are described as follows: a) Enclave_id: Unique ID of the successfully initialized enclave.

[0090] b) Success: Boolean type, true indicates successful initialization of the enclave, false indicates failure to initialize the enclave.

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

[0092] 4) The trusted application TA calls the enclave state awareness extension command to obtain the state of the enclave and determine whether the initialization is successful. We describe the enclave state as State = {Null, Init, Start, Stop, Destroy}. If successful, proceed to step 5. If failed, return the corresponding error information. The state description is as follows: a) Null: Indicates that the enclave does not exist.

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

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

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

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

[0097] 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 the initialization proof to the user end U. We describe the initialization proof as Proof_init = {Enclave_id, State, Sig_init}, and some attributes are described as follows: a) Private_T: The private key of the trusted execution environment T, stored in the security management service S.

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

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

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

[0101] Run the proof process as Figure 5 The specific process is as follows: 1) The user U first constructs a running request for the trusted application. We describe this request as Q2={Request_id, T_ip, Enclave_id, Interface_exec, Parameters}. U signs the request with a private key. We describe this signing process as Sig_u2=signature(Private_U,Q2). The signature is intended to prove the identity of U. T determines whether it has the authority to call the trusted application through the signature (or the trusted application TA determines it). U sends {Q2, Sig_u2} to the trusted execution environment service T. Some attributes are described as follows: a) Request_id: This is the request number, which is used as the unique identifier of this request.

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

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

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

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

[0106] f) Sig_u2: User signature for this request 2) The trusted execution environment service T processes the received message and parses the initialization request {Q2, Sig_u2}, first performing basic checks such as format. If the check passes, proceed to step 3), otherwise the corresponding error message is returned. The specific check items are as follows: a) Whether the Sig_u2 signature is correct and whether the user has the permission to run trusted applications.

[0107] 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, and obtains the execution result. If the execution is successful and the result is returned, proceed to step 4). If an abnormal execution fails, the corresponding error information is returned. We describe the execution result as R2={Enclave_id, Success, Error_msg, Result}. If successful, proceed to step 4). If failed, the corresponding error information is returned. Some attributes are described as follows: a) Enclave_id: unique number of the enclave.

[0108] b) Success: Boolean type. True indicates successful operation, and false indicates failed operation.

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

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

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

[0112] 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 the signature as Sig_exec = signature (Private_T, Exec_msg). S generates an execution proof based on this signature and returns the execution proof to the user end U. We describe the execution proof as Proof_exec = {Enclave_id, Exec_msg, Sig_exec}.

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

[0114] Freeze certification process Figure 6 The specific process is as follows: 1) The user U first constructs a freeze request for the trusted application. We describe this request as Q3={Request_id, T_ip, Enclave_id, Interface_freeze, Parameters}. U signs the request with a private key. We describe this signing process as Sig_u3=signature(Private_U,Q3). The signature is intended to prove U's identity. T determines through the signature that it has the authority to call the trusted application (or the trusted application TA determines). U sends {Q3, Sig_u3} to the trusted execution environment service T. Some attributes are described as follows: a) Request_id: This is the request number, which is used as the unique identifier of this request.

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

[0116] c) Enclave_id: the enclave number where the trusted application TA to be frozen is located.

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

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

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

[0120] 2) The trusted execution environment service T processes the received message and parses the initialization request {Q3, Sig_u3}, first performing basic checks such as format. If the check passes, proceed to step 3, otherwise the corresponding error message is returned. The specific check items are as follows: a) Whether the Sig_u3 signature is correct and whether the user has permission to run trusted applications.

[0121] 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, and obtains the execution result. If the execution is successful and the return result is obtained, step 4) is performed. If an abnormal execution fails, the corresponding error information is returned. We describe the execution result as R3={Enclave_id, Success, Error_msg}. After the execution is successful, the running interface related to the trusted application calculation cannot be called. Deleting the interface of the process has no effect. Optionally, the unfreeze interface is retained. Some attributes are described as follows: a) Enclave_id: unique number of the enclave.

[0122] b) Success: Boolean type. True indicates successful operation, and false indicates failed operation.

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

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

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

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

[0127] Deletion certification process Figure 7 The specific process is as follows: 1) The user U first constructs a deletion request for the trusted application. We describe this request as Q4={Request_id, T_ip, Enclave_id, Interface_delete}. U signs the request with a private key. We describe this signing process as Sig_u4=signature(Private_U,Q4). The signature is intended to prove U's identity. T determines through the signature that it has the authority to call the trusted application (or the trusted application TA determines). U sends {Q4, Sig_u4} to the trusted execution environment service T. Some attributes are described as follows: a) Request_id: This is the request number, which is used as the unique identifier of this request.

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

[0129] c) Enclave_id: the enclave number where the trusted application TA to be deleted is located.

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

[0131] 2) The trusted execution environment service T processes the received message and parses the initialization request {Q4, Sig_u4}, first performing basic checks such as format. If the check passes, proceed to step 3, otherwise the corresponding error message is returned. The specific check items are as follows: a) Whether the Sig_u4 signature is correct and whether the user has permission to run trusted applications.

[0132] 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, and obtains the execution result. If the execution is successful and the result is returned, proceed to step 4). If an abnormal execution fails, the corresponding error information is returned. We describe the execution result as R4={Enclave_id, Success, Error_msg}.

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

[0134] 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 the signature as Sig_delete = signature (Private_T, Delete_msg). S generates a deletion proof based on this signature and returns the deletion proof to the user end U. We describe the deletion proof as Proof_delete = {Enclave_id, Delete_msg, Sig_delete}.

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

[0136] The trusted execution environment service T and the security management service S can choose to retain the relevant proof data, and the user end U can selectively verify the proof for each node in the trusted application life cycle. The core verification logic is to verify the validity of the enclave signature in the proof. Optionally, the user can use the remote authentication function in the technical system where the enclave is located to verify the authenticity of the enclave. Optionally, the user can set the random number nonce to be carried during the proof generation process to prevent replay attacks, etc.

[0137] The instruction set ISA extension is described as follows: Enclave state awareness instruction set extension, which records the initialization, start, stop and destruction status information of the enclave at the hardware level; Enclave self-destruction instruction set extension, which supports enclave self-destruction initiated by trusted applications at the hardware level.

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

[0139] In the initialization phase of the life cycle, the security management service S remotely authenticates the enclave in the trusted execution environment service T. The deletion phase is triggered by the user, and the enclave is destroyed in the untrusted part of the trusted execution service. At the same time, the destruction proof (i.e., signing the destruction result) is supported in the instruction set architecture part, and the proof is verified with the help of the remote authentication part of the trusted execution environment technology system.

[0140] The architecture of this embodiment is as follows Figure 8 The main changes are as follows: 1) The instruction set architecture part of the trusted execution environment service T includes support for enclave destruction proof.

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

[0142] 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, and the deletion proof verification function is added.

[0143] The initialization proof process of this embodiment is as follows Fig. 9 The specific process is as follows: 1) The user U first constructs an initialization request for the trusted application. We describe this request as Q1={Request_id, T_ip, Code, Parameters}. U signs the request using a private key (we assume that the executable environment service T knows the corresponding public key). We describe the signing process as Sig_u1=signature(Private_U,Q1). The signature is intended to prove the identity of U, and T determines whether it has the authority to initialize the trusted application through the signature. U sends {Q1, Sig_u1} to the trusted execution environment service T. Some attributes are described as follows: a) Request_id: This is the request number, which is used as the unique identifier of this request.

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

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

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

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

[0148] 2) The trusted execution environment service T processes the received message and parses the initialization request {Q1, Sig_u1}, first performing basic checks such as format. If the check passes, proceed to step 3), otherwise the corresponding error message is returned. The specific check items are as follows: a) Check whether the Sig_u1 signature is correct and whether the user has the permission to initialize.

[0149] 3) The trusted execution environment service T initializes the enclave based on the Code and Parameters information in Q1, and judges the initialization result. We describe the return result as R1={Enclave_id, Success, Error_msg}. If successful, proceed to step 4, if failed, return the corresponding error information. Some attributes are described as follows: a) Enclave_id: Unique ID of the successfully initialized enclave.

[0150] b) Success: Boolean type, true indicates successful initialization of the enclave, false indicates failure to initialize the enclave.

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

[0152] 4) The security management service S performs remote authentication on the enclave and judges the authentication result. If the authentication succeeds, it proceeds to step 5). If it fails, it returns the corresponding error message. We describe the authentication result as R_attestation={Enclave_id, Success, Error_msg}. If it succeeds, it proceeds to step 5). If it fails, it returns the corresponding error message. Some attributes are described as follows: a) Enclave_id: Unique ID of the successfully initialized enclave.

[0153] b) Success: Boolean type, true means the authentication is successful, false means the authentication failed.

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

[0155] 5) The security management service generates a signature based on the authentication 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 the initialization proof to the user end U. We describe the initialization proof as Proof_init={Enclave_id, State, Sig_init}, and some attributes are described as follows: a) Private_T: The private key of the trusted execution environment T, stored in the security management service S.

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

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

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

[0159] Example 3 This embodiment provides a trusted application lifecycle security management system, which is based on a trusted application lifecycle security management method described in Embodiment 1 and is applied to a variety of heterogeneous trusted execution environments.

[0160] In further embodiments, there is also provided: An electronic device includes 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 described in Embodiment 1 is performed. For the sake of brevity, it will not be described in detail here.

[0161] It should be understood that in this embodiment, the processor may be a central processing unit CPU, and the processor may also be other general-purpose processors, digital signal processors DSP, application-specific integrated circuits ASIC, off-the-shelf 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 the processor may also be any conventional processor, etc.

[0162] The memory may include a read-only memory and a random access memory, and provide 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.

[0163] 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 completed.

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

[0165] A computer program product includes a computer program, and when the computer program is executed by a processor, the method described in embodiment 1 is implemented.

[0166] 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 included in a program module, which are executed in a device on a real or virtual processor of the target to perform the process / method as described above. Typically, 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 functions of program modules can be combined or divided between program modules as needed. Machine executable instructions for program modules can be executed in local or distributed devices. In distributed devices, program modules can be located in local and remote storage media.

[0167] 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 the processor of a general-purpose computer, a special-purpose computer or other programmable data processing device, so that the program code, when executed by the computer or other programmable data processing device, causes the function / operation specified in the flow chart and / or block diagram to be implemented. The program code can be executed completely on a computer, partially on a computer, as an independent software package, partially on a computer and partially on a remote computer or completely on a remote computer or server.

[0168] In the context of the present invention, computer program codes or related data may 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 may include electrical, optical, radio, acoustic or other forms of propagation signals, such as carrier waves, infrared signals, and the like.

[0169] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example 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. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0170] Although the above describes the specific implementation mode 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 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, the key exchange protocol is used to establish a secure channel between the trusted execution environment, the user end, and the security management service, and verifiable proofs are generated in the independent security management service based on the trusted execution environment. Each operation at each stage of the entire life cycle of the trusted application is recorded and signed to generate an irrefutable track. The verifiable proofs include initialization proof, operation proof, freezing proof and deletion proof.

2. A trusted application lifecycle security management method as claimed in claim 1, characterized in that: The initialization proves The following steps are involved: The user terminal constructs and sends an initialization request for a trusted application to the trusted execution environment, and the user terminal signs the initialization request using a private key; The trusted execution environment receives the initialization request and parses it; The trusted execution environment initializes the enclave based on the information of the initialization request 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 information. 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, the corresponding error message is returned; 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 the signature and returns it to the user end; The user end uses the initialization proof to perform subsequent proof verification work.

3. A trusted application lifecycle security management method as claimed in claim 1, characterized in that: The operation proof includes the following steps: The user terminal constructs and sends a running request of the trusted application to the trusted execution environment, and the user terminal signs the running request using a private key; The trusted execution environment receives the execution request and parses it; The trusted execution environment starts the enclave and executes the trusted application based on the information of the run request to obtain the execution result. If the execution is successful, the next step is performed. If the execution fails, the corresponding error information is returned. The trusted execution environment sends the execution results of the trusted application and related information of the running 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 running certificate based on the signature and returns it to the user end; The user end uses the operation certificate to perform subsequent certificate verification work.

4. A trusted application lifecycle security management method as claimed in claim 1, characterized in that: The freezing proof comprises the following steps: 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; The trusted execution environment receives the freeze request and parses it; 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 performed. If the execution fails, the corresponding error information is returned. The trusted execution environment sends the relevant information of the freeze 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 freezing certificate based on the signature and returns it to the user end; The user end uses the freezing certificate for subsequent certificate verification.

5. A trusted application lifecycle security management method as claimed in 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 to obtain the execution result. If the execution is successful, the next step is performed. 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 the signature and returns it to the user end; The user end uses the deletion certificate to perform subsequent certificate verification work.

6. A trusted application lifecycle security management method as claimed in 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 the deletion stage in the life cycle of the trusted application.

7. 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.

8. 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 6 is completed.

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

10. A computer program product, characterized in that The invention comprises a computer program, which, when executed by a processor, implements the method according to any one of claims 1 to 6.

Images