Remote attestation method and apparatus, and electronic device and storage medium

Abstract

Provided in the present disclosure are a remote attestation method and apparatus, and an electronic device and a storage medium. The method is applied to a first application, wherein the first application runs in a first trusted execution environment. The method comprises: initiating a remote attestation request to a second application, wherein the second application runs in a second trusted execution environment; acquiring a first attestation response returned by the second application; acquiring first attestation evidence of the second application from a target trusted storage module, wherein the first attestation evidence is uploaded by means of the second application and is stored in the target trusted storage module; and performing remote attestation on the basis of the first attestation response and the first attestation evidence, so as to obtain a first remote attestation result for the second application.

Description

Remote certification method, device, electronic device and storage medium

[0001] This application claims priority to the Chinese invention patent application entitled “Remote Attestation Method, Device, Electronic Device and Storage Medium” filed on November 15, 2023, with application number 202311523826.1. The entire contents of that application are incorporated by reference into this application. Technical Field

[0002] The present disclosure relates to the field of computers, and in particular to a remote certification method, device, electronic device, and storage medium. Background Art

[0003] Implementing trusted computing requires that computing programs run in a TEE (Trusted Execution Environment). TEE is a secure area of ​​the processor that establishes an isolated execution environment. The isolated execution environment provides security features such as isolated execution, the integrity of applications running in the TEE, and the confidentiality of their assets.

[0004] To enable communication between trusted applications running in multiple TEEs, remote attestation is required to verify that the applications are running on a secure trusted execution environment platform and that the application logic has not been tampered with. However, existing remote attestation methods cannot meet the usage requirements of applications.

[0005] Summary of the Invention

[0006] In view of this, the purpose of the present disclosure is to provide a remote attestation method, device, electronic device and storage medium.

[0007] Based on the above-mentioned purpose, the first aspect of the present disclosure provides a remote attestation method, which is applied to a first application, and the first application runs in a first trusted execution environment; the method includes: initiating a remote attestation request to a second application, and the second application runs in a second trusted execution environment; obtaining a first attestation response returned by the second application; obtaining first attestation evidence of the second application from a target trusted storage module, and the first attestation evidence is uploaded by the second application and stored in the target trusted storage module; performing remote attestation based on the first attestation response and the first attestation evidence, and obtaining a first remote attestation result for the second application.

[0008] In some embodiments, the first attestation response includes a first remote attestation report generated based on the remote attestation request.

[0009] In some embodiments, the first attestation evidence includes baseline application metric information of the second application, the baseline application metric information being generated based on creation or update of the second application in the second trusted execution environment and uploaded to the target trusted storage module.

[0010] In some embodiments, the remote attestation is performed based on the first attestation response and the first attestation evidence to obtain a first remote attestation result for the second application, including: determining whether the first remote attestation report meets a preset condition; in response to the first remote attestation report meeting the preset condition, obtaining application measurement information of the second application based on the first remote attestation report, and verifying the baseline application measurement information and the application measurement information; in response to the baseline application measurement information and the application measurement information matching, determining that the first remote attestation result is attestation passed; in response to the baseline application measurement information and the application measurement information not matching, determining that the first remote attestation result is attestation failed.

[0011] In some embodiments, before performing remote attestation based on the first attestation response and the first attestation evidence, the method further includes: obtaining additional information in the first attestation response; obtaining first information based on the first remote attestation report, and determining the association relationship between the first remote attestation report and the second application based on the additional information and the first information.

[0012] In some embodiments, the method further includes: obtaining a first verification strategy for the first application from a target trusted storage module; the first verification strategy is uploaded and stored in the target trusted storage module through the first application, and the first verification strategy is used for the first application to remotely authenticate other applications, and the other applications include the second application; the remote authentication based on the first authentication response and the first authentication evidence includes: verifying the first authentication response and the first authentication evidence based on the first verification strategy.

[0013] In some embodiments, the method further includes: setting the attestation service in the smart contract of the target trusted storage module; the verification based on the first attestation response and the first attestation evidence includes: verifying the first attestation response and the first attestation evidence based on the first verification strategy through the smart contract.

[0014] In some embodiments, the first attestation evidence includes at least one of the following: application identification information of the second application; application version information of the second application; at least one remote attestation type of the second application; at least one application measurement value information of the second application, and the application measurement value information is associated with the remote attestation type.

[0015] In some embodiments, in response to the first remote attestation result being a passed attestation, the method further includes: generating a second attestation response and sending it to the second application, so that the second application performs the following steps: obtaining second attestation evidence of the first application from the target trusted storage module, the second attestation evidence being uploaded by the first application and stored in the target trusted storage module; remotely obtaining a second remote attestation result for the first application based on the second attestation response and the second attestation evidence.

[0016] In some embodiments, in response to the second remote attestation result being a passed attestation, the method further includes: obtaining the public key of the second application, generating a first session key based on the private key of the first application and the public key of the second application, and communicating with the second application based on the first session key; and enabling the second application to obtain the public key of the first application, generate a second session key based on the private key of the second application and the public key of the first application, and communicate with the first application based on the second session key; wherein the first session key is the same as the second session key.

[0017] In some embodiments, the method further includes: in response to the first application and / or the second application being open source applications, uploading and storing application code of the first application and / or the second application to a public address.

[0018] A second aspect of the present disclosure provides a remote attestation device, comprising a first application, which runs in a first trusted execution environment; the device further comprises: a request module, configured to initiate a remote attestation request to a second application, which runs in a second trusted execution environment; a return module, configured to obtain a first attestation response returned by the second application; an acquisition module, configured to obtain first attestation evidence of the second application from a target trusted storage module, the first attestation evidence being uploaded by the second application and stored in the target trusted storage module; and a attestation module, configured to perform remote attestation based on the first attestation response and the first attestation evidence, to obtain a first remote attestation result for the second application.

[0019] A third aspect of the present disclosure provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the remote attestation method as described in the first aspect when executing the program.

[0020] A fourth aspect of the present disclosure provides a non-transitory computer-readable storage medium, wherein the non-transitory computer-readable storage medium stores computer instructions, and the computer instructions are used to enable the computer to execute the remote attestation method described in the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] In order to more clearly illustrate the technical solutions in the present disclosure or related technologies, the following briefly introduces the drawings required for use in the embodiments or related technical descriptions. Obviously, the drawings described below are only embodiments of the present disclosure. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0022] FIG1 shows a flow chart of an exemplary method provided by an embodiment of the present disclosure.

[0023] FIG2 shows a schematic flow chart of an exemplary method according to an embodiment of the present disclosure.

[0024] FIG3 shows a schematic diagram of an exemplary network architecture according to an embodiment of the present disclosure.

[0025] FIG4 shows a schematic diagram of an exemplary device provided by an embodiment of the present disclosure.

[0026] FIG5 shows a schematic diagram of the hardware structure of an exemplary computer device provided by an embodiment of the present disclosure. DETAILED DESCRIPTION

[0027] In order to make the objectives, technical solutions and advantages of the present disclosure more clearly understood, the present disclosure is further described in detail below in conjunction with specific embodiments and with reference to the accompanying drawings.

[0028] It should be noted that, unless otherwise defined, the technical terms or scientific terms used in the embodiments of the present disclosure should have the usual meanings understood by people with ordinary skills in the field to which the present disclosure belongs. The "first", "second" and similar words used in the embodiments of the present disclosure do not indicate any order, quantity or importance, but are only used to distinguish different components. "Include" or "comprise" and similar words mean that the elements or objects appearing before the word include the elements or objects listed after the word and their equivalents, without excluding other elements or objects. "Connect" or "connected" and similar words are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect. "Up", "down", "left", "right" and the like are only used to indicate relative position relationships. When the absolute position of the described object changes, the relative position relationship may also change accordingly.

[0029] In the field of distributed computing environments, cloud computing is becoming increasingly important as a way to achieve more flexible, scalable, and efficient systems. However, as users of cloud computing services lose direct control over the data and applications hosted by cloud providers, the trustworthiness of cloud services has become a major issue hindering the deployment of cloud applications.

[0030] To attract users to use cloud services, cloud / service providers offer trusted services to assure users that the data and applications provided to the service remain secure and protected, and that the service will only use these data and applications as intended by the user.

[0031] Trusted services can be developed using a trusted execution environment (TEE), such as Intel SGX, TDX, AMD SEV, and ARM TrustZone. A TEE is a hardware-based security technology that creates a secure computing environment isolated from the outside world by dividing it into secure and non-secure parts. This secure computing environment ensures the confidentiality and integrity of the data and code loaded within it.

[0032] When a trusted execution environment (TEE) is implemented, it provides a remote attestation mechanism. A requester initiates a remote attestation request to a trusted application. The application then obtains a remote attestation report and provides it to the requester. By verifying the remote attestation report, the requester can confirm that the application is running on a trusted hardware platform and that the application's operating logic has not been tampered with, thereby ensuring data security.

[0033] Remote attestation reports typically include application metrics, which are hash values ​​calculated based on the application's code and data and can be used to verify the application's identity and integrity. During remote attestation, the requester receives the remote attestation report from the application and obtains the application metrics from the report. The requester then compares the application metrics with pre-obtained baseline values, which are synchronized with other trusted applications after the application is developed. When remote attestation is performed between multiple trusted applications, the following issues arise:

[0034] (1) Bidirectional remote attestation between trusted applications requires obtaining the measurement values ​​of other applications as part of their own measurement content, which leads to a circular dependency problem.

[0035] Specifically, when application A is developed, its application measurement value MRE_A is obtained. When application B needs to verify application A, application A's application measurement value MRE_A is written into application B's code or configuration information as a reference value, and application B is measured to generate application B's application measurement value MRE_B. If application A also verifies application B, application B's application measurement value MRE_B needs to be written into application A's code or configuration information. This causes a change in application A's code or configuration information, which results in the application measurement value MRE_A' calculated at this time being different from MRE_A. This means that application A's application measurement value has changed, making subsequent remote attestation impossible.

[0036] (2) Before application A is upgraded, application B verifies application A using application A's application measurement value MRE_A as a benchmark value. After application A is upgraded, the code or configuration information of application A changes, causing application A's application measurement value MRE_A' to be different from MRE_A. This means that application A's application measurement value has also changed, and application B cannot subsequently verify application A's new benchmark value.

[0037] To address the above issues, the following methods can be used in related technologies to solve them:

[0038] Method A: The developer is used as a trusted third party, and the identity of each application is verified based on the developer's information. Taking the SGX environment as an example, each enclave within the SGX environment includes two identity credentials: the application measurement value (MRENCLAVE) and the developer's public key measurement value (MRSINGER). Once the developer's key is determined, each enclave is signed using the same public key. Multiple enclaves use the developer's public key measurement value to verify each other's identity. This method relies on a trusted developer, and applications do not verify the integrity of each other's code and operational logic.

[0039] In this case, if the developer key is lost, an attacker can create a malicious application and communicate with the original application through a qualified developer key. The user's data may be obtained by the attacker, and the user's data security cannot be guaranteed.

[0040] Method B: Group multiple enclaves together, use the application metrics of each application within the group as a baseline, and calculate an intermediate metric based on the application metrics of each application within the group. During remote attestation, the application uses its own tools or logic to calculate the final metrics of other applications from this intermediate metric, thereby implementing remote attestation based on the final metrics of other applications. This avoids the circular dependency issue caused by writing application metrics into application code or configuration information.

[0041] However, since the intermediate measurement value is calculated based on the application measurement value of the code of each application, when an application in the group of enclaves is updated and the application code or configuration information changes, the application measurement value of the application, that is, the baseline value, will also change. Other applications will not be able to calculate the final measurement value of the application from the intermediate measurement value, and remote attestation of the application will not be possible. At the same time, if a new application needs to be added to the group of enclaves, the application will not be able to obtain the final measurement value of other applications from the intermediate measurement value, and other applications will not be able to obtain the final measurement value of the newly added application from the intermediate measurement value, making it impossible for the newly added application to be remotely attested with other applications.

[0042] In view of this, the embodiment of the present disclosure provides a remote attestation method, which uses a trusted storage module to save identity information used for remote attestation to solve the above problems. From the above, it can be seen that the remote attestation method, device, electronic device and storage medium provided by the present disclosure, because the second application has already uploaded it to the target trusted storage module in advance as the first attestation evidence of the remote attestation benchmark value, when the first application needs to remotely attest the second application, it can directly obtain the first attestation evidence as the benchmark value from the target trusted storage module, and perform remote attestation in combination with the first attestation response directly obtained from the second application by initiating a remote attestation request, thereby obtaining the final remote attestation result. In this process, since the first proof evidence serving as the benchmark value is stored in the target trusted storage module rather than in the first application, this will not cause changes in the proof evidence of the first application itself, and will not affect the subsequent remote proof of the first application, that is, there is no need to worry about the circular dependency problem caused by two-way proof; at the same time, since the first proof evidence is uploaded and stored in the target trusted storage module, when the second application is a new application or the second application is updated, it is only necessary to obtain the proof evidence of the new version of the second application and upload and store it in the target trusted storage module. When the first application initiates a remote proof request to the second application, it will obtain the first proof evidence corresponding to the latest version of the second application from the target trusted storage module as the benchmark value for remote proof, thereby enabling remote proof between applications even in the case of new applications or application updates.

[0043] The remote attestation method is applied to a first application, and the first application runs in a first trusted execution environment. As shown in FIG1 , the method includes:

[0044] Step S101: Initiate a remote attestation request to a second application, where the second application runs in a second trusted execution environment.

[0045] The Trusted Execution Environment (TEE) involved in the embodiments of this specification can provide a secure execution environment for software. TEE is a secure extension based on CPU hardware and is completely isolated from the outside world. Take Intel SGX (hereinafter referred to as SGX) technology as an example. A trusted computing node can create an enclave (enclave or enclave) based on SGX technology to serve as a TEE for running the first application and the second application. Among them, using the newly added processor instructions in the CPU, a part of the area EPC (Enclave Page Cache, enclave page cache or enclave page cache) can be allocated in the memory to reside in the above-mentioned enclave. The memory area corresponding to the above-mentioned EPC is encrypted by the memory encryption engine MEE (Memory Encryption Engine) inside the CPU. The content in this memory area (code and data in the enclave) can only be decrypted in the CPU core, and the key used for encryption and decryption is only generated and stored in the CPU when the EPC is started. As can be seen, the enclave's security boundary only includes itself and the CPU. No privileged or unprivileged software can access the enclave. Even the operating system administrator and the VMM (virtual machine monitor, also known as the hypervisor) cannot affect the code and data in the enclave, thus having extremely high security. Under the premise of the above security guarantees, the CPU can process plaintext trusted storage module transactions in the enclave with extremely high computing efficiency, thus taking into account both data security and computing efficiency.

[0046] In this embodiment, the first application runs in a first trusted execution environment, and the second application runs in a second trusted execution environment. The first trusted execution environment and the second trusted execution environment can be deployed on the same trusted computing node, or they can be deployed on different trusted computing nodes, and this specification does not impose any restrictions on this. The first trusted execution environment and the second trusted execution environment can be the same trusted execution environment, or the first trusted execution environment can be different from the second trusted execution environment, and this embodiment does not impose any restrictions on this.

[0047] In this embodiment, when a first application wants to remotely authenticate a second application, the first application may generate a first request value and send it to the second application, thereby initiating a remote authentication request to the second application. The first request value may be a random number generated by the first application.

[0048] Step S103: Obtain a first certification response returned by the second application.

[0049] After receiving the first request value sent by the first application, the second application generates a first attestation response based on the remote attestation request initiated by the first application. The second application then sends the first attestation response to the first application, which then receives the first attestation response back from the second application. The first attestation response is used to remotely attest the second application. This remote attestation may include remote identity verification and / or verification of the integrity of the application's code and operational logic.

[0050] Step S105: Obtain first proof evidence of the second application from the target trusted storage module, where the first proof evidence is uploaded by the second application and stored in the target trusted storage module.

[0051] The first application can obtain the first attestation evidence of the second application from the target trusted storage module. The first attestation evidence is the benchmark value used for remote attestation of the second application. The first attestation evidence is pre-uploaded by the second application and stored in the target trusted storage module. For example, after the second application is developed or updated, the first attestation evidence of the second application is uploaded and stored in the target trusted storage module. In this way, when the first application needs to remotely attest the second application, it can obtain the latest first attestation evidence from the target trusted storage module as the benchmark value for remote attestation of the second application.

[0052] At the same time, since the first proof evidence is stored in the target trusted storage module, it does not need to be stored in the application. This will not cause changes in the proof evidence of the application itself, and will not affect the subsequent remote proof of the application. At the same time, when a new application is added or an application is updated, it is only necessary to obtain the proof evidence of the new application or the updated new version of the application and upload and store it in the trusted storage module. When other applications need to initiate a remote proof request for the new application or the new version of the application, the requester application can directly obtain its latest proof evidence from the trusted storage module as a baseline value to process remote proof, without having to worry about the latest proof evidence not being stored in the code or configuration information of the requester application.

[0053] In some embodiments, the target trusted storage module can be a decentralized trusted storage module unit, trusted storage module device, or trusted storage module space, such as a blockchain. Blockchain is a distributed ledger technology that links data in blocks to form an immutable, transparent, decentralized database. When trusted applications, such as the first application and the second application, upload information such as proof evidence and verification strategies to the blockchain, the blockchain ensures the secure transmission and storage of such information.

[0054] Step S107: Perform remote attestation based on the first attestation response and the first attestation evidence to obtain a first remote attestation result for the second application.

[0055] After obtaining the first attestation response returned by the second application and the first attestation evidence as a reference value, the first application can remotely attest the second application based on the first attestation response and the first attestation evidence, thereby obtaining a first remote attestation result for the second application.

[0056] In this embodiment, since the second application has already uploaded its first proof evidence as a remote proof reference value to the target trusted storage module in advance, when the first application needs to remotely prove the second application, it can directly obtain the first proof evidence as the reference value from the target trusted storage module, and perform remote proof in combination with the first proof response directly obtained from the second application by initiating a remote proof request, thereby obtaining the final remote proof result. In this process, since the first proof evidence as the reference value is stored in the target trusted storage module rather than in the first application, this will not cause the proof evidence of the first application itself to change, and will not affect the subsequent remote proof of the first application, that is, there is no need to worry about the circular dependency problem caused by two-way proof; at the same time, since the first proof evidence is uploaded and stored in the target trusted storage module, when the second application is a new application or the second application is updated, it only needs to obtain the proof evidence of the new version of the second application and upload and store it in the target trusted storage module. When the first application initiates a remote proof request to the second application, it will obtain the first proof evidence corresponding to the latest version of the second application from the target trusted storage module as the reference value for remote proof, thereby enabling remote proof between applications even in the case of new applications or application updates.

[0057] In some embodiments, the remote attestation method described in steps S101 to S107 can be applied to one-way remote attestation of a first application to a second application, or can be applied to two-way remote attestation between the first application and the second application.

[0058] In some embodiments, when the remote attestation method described in steps S101 to S107 is applied to a two-way remote attestation between a first application and a second application: for the remote attestation of the first application to the second application, the remote attestation method described in steps S101 to S107 may be used; for the remote attestation of the second application to the first application, the remote attestation method described in steps S101 to S107 may also be used, or other feasible remote attestation methods may also be used, and this embodiment does not impose any restrictions on this. In some embodiments, the first attestation response includes a first remote attestation report, and the first remote attestation report may include hardware TCB information, application measurement values, application-defined data, hardware signatures and other information. Through the first remote attestation report, the first application can confirm that the second application is running on a trusted hardware platform and that the application's operating logic has not been tampered with, thereby ensuring data security in subsequent communications with the second application. Wherein, the first remote attestation report is generated based on the remote attestation request initiated by the first application to the second application.

[0059] In some embodiments, the first attestation response may also include authentication information used to authenticate the second application, so that the first application can authenticate the second application based on the authentication information, thereby ensuring data security in subsequent communications with the second application. The first attestation response may also include other information used to remotely attest the second application to ensure secure communication between the first and second applications, which is not limited in this embodiment.

[0060] In some embodiments, the first attestation evidence includes baseline application metric information of the second application, the baseline application metric information being generated based on creation or update of the second application in the second trusted execution environment and uploaded to the target trusted storage module.

[0061] In this embodiment, when the second application is developed in the second trusted execution environment, a hash value is calculated based on the code and data of the second application to obtain the application measurement value of the second application, and the application measurement value is uploaded to the target trusted storage module for storage as a benchmark value for other applications to remotely verify the second application, that is, the benchmark application measurement value information.

[0062] Alternatively, when the second application is updated in the second trusted execution environment, the hash value is recalculated based on the code and data of the new version of the second application to obtain a new application metric value of the new version of the second application, and the new application metric value is uploaded to the target trusted storage module, and the new application metric value is used to replace the old application metric value of the second application stored in the target trusted storage module; or, the new application metric value and the version information of the second application are also stored in the target trusted storage module, and when other applications make remote requests to the second application, based on the current version of the second application (for example, the version information of the second application can be stored in the remote attestation report), the corresponding version of the application metric value is obtained from the target trusted storage module as the baseline application metric value information to achieve remote attestation of the second application. This embodiment does not impose any restrictions on this.

[0063] In this embodiment, since the application measurement value of the second application is stored in the target trusted storage module and does not need to be stored in the code or configuration information of the application, it will not cause the application measurement value of each application used as the baseline value to change; at the same time, when the second application is a newly added application or an updated new version application, it is only necessary to obtain the new application measurement value of the newly added second application or the updated new version second application and upload and store it to the target trusted storage module. When other applications such as the first application need to initiate a remote certification request for the newly added second application or the new version second application, the requester application can directly obtain the latest application measurement value of the first application from the target trusted storage module as the baseline application measurement value information to process remote certification without worrying about the latest certification evidence not being stored in the code or configuration information of the requester application.

[0064] In some embodiments, when the first attestation evidence includes baseline application metric information of the second application, as shown in FIG2 , performing remote attestation based on the first attestation response and the first attestation evidence in step S107 to obtain a first remote attestation result for the second application includes:

[0065] Step S201, determining whether the first remote certification report meets preset conditions.

[0066] In this embodiment, the first remote attestation report includes a hardware signature. After obtaining the first remote attestation report, the hardware signature in the first remote attestation report can be obtained and verified to determine whether the first remote attestation report meets preset conditions, thereby determining whether the first remote attestation report is a remote attestation report generated by a trusted application running in a trusted execution environment.

[0067] Among them, the smart contract can be called to verify the hardware signature, or other feasible methods can be used to verify the hardware signature to determine whether the first remote attestation report meets the preset conditions. This embodiment does not impose any restrictions on this.

[0068] Step S203: In response to the first remote attestation report meeting a preset condition, obtaining application metric information of the second application based on the first remote attestation report, and verifying the baseline application metric information and the application metric information.

[0069] Step S205: In response to the benchmark application metric information and the application metric information matching, determining that the first remote attestation result is attestation passed.

[0070] Step S207: In response to the mismatch between the benchmark application metric information and the application metric information, determining that the first remote attestation result is attestation failure.

[0071] In this embodiment, when the first attestation evidence is the baseline application measurement information of the second application, the first remote attestation report is parsed to obtain the application measurement information of the second application from the first remote attestation report, and verification is performed based on the baseline application measurement information obtained from the target trusted storage module and the application measurement information sent from the second application: when the baseline application measurement information and the application measurement information match, it can be determined that the first remote attestation result of the first application to the second application is passed; when the baseline application measurement information and the application measurement information do not match, it can be determined that the first remote attestation result of the first application to the second application is failed.

[0072] In some embodiments, before performing remote attestation based on the first attestation response and the first attestation evidence in step S107, the method further includes:

[0073] Step S301: Obtain additional information in the first certification response.

[0074] Step S303: Acquire first information based on the first remote attestation report, and determine an association relationship between the first remote attestation report and the second application based on the additional information and the first information.

[0075] The additional information may include the request value of the first application, the public key of the second application, or a random number generated by the second application, etc. This embodiment does not impose any limitation on this.

[0076] At the same time, the first remote attestation report also stores information such as the request value of the first application, the public key of the second application, or the random number generated by the second application, i.e., the first information. In this embodiment, whether the first remote attestation report comes from the second application is determined based on the additional information and the first information obtained from the first remote attestation report. When the additional information is consistent with the first information, it indicates that the first remote attestation report comes from the second application and no replay attack occurs; when the additional information is inconsistent with the first information, it indicates that the first remote attestation report does not come from the second application and a replay attack occurs. Therefore, protection against replay attacks can be achieved by setting additional information.

[0077] In some embodiments, the method further includes: obtaining a first verification strategy of the first application from a target trusted storage module; the first verification strategy is uploaded and stored in the target trusted storage module through the first application, and the first verification strategy is used for the first application to remotely authenticate other applications, and the other applications include the second application.

[0078] The remote attestation based on the first attestation response and the first attestation evidence in step S107 includes: verifying the first attestation response and the first attestation evidence based on the first verification strategy.

[0079] When a first application is created or updated in the first trusted execution environment, the first application can upload and store the first verification policy in the target trusted storage module. When the first application needs to remotely attest other applications, including the second application, it retrieves its first verification policy from the target trusted storage module and verifies the other applications, including the second application, based on the first verification policy.

[0080] The first verification policy is the policy used by the first application when remotely attesting other applications, including the second application, and includes information such as verification content and verification logic. The first verification policy can be configured based on usage requirements. For example, the first verification policy may include: the second application is a trusted application, the remote attestation type of the second application is SGX DCAP, and verification of application metrics is required during verification.

[0081] When a first application remotely attests a second application, the first application may first determine whether the remote attestation type of the second application is SGX DCAP, and then use the first verification strategy to match the benchmark application measurement information and application measurement information of the second application to obtain a first remote attestation result.

[0082] In this embodiment, when the first application's verification policy for other applications changes, or when a new application is added and the first application needs to verify the newly added application, it is necessary to add a verification policy for the newly added application to the first verification policy. Since the first application's first verification policy is stored in the target trusted storage module, the first verification policy can be directly modified and uploaded and stored in the target trusted storage module. In this way, when the first application subsequently needs to remotely verify the application with the changed verification policy or the newly added application, it can directly obtain the modified first verification policy from the target trusted storage module, thereby solving the verification problem of application updates or newly added applications.

[0083] In some embodiments, the method further includes: setting the attestation service in the smart contract of the target trusted storage module; the verification based on the first attestation response and the first attestation evidence in step S107 includes: verifying the first attestation response and the first attestation evidence based on the first verification strategy through the smart contract.

[0084] In this embodiment, after the hardware manufacturer implements the TEE and remote attestation mechanism, it will provide basic libraries and interfaces related to verifying the remote attestation report. Developers or cloud service providers can provide easy-to-use attestation services based on the basic interfaces, and deploy the attestation service as a smart contract in the trusted storage module; the attestation service can verify the remote attestation report according to the configured verification strategy and return detailed remote attestation results.

[0085] That is, in this embodiment, the attestation service used to implement remote attestation can be deployed as a smart contract to the target trusted storage module. When the first application needs to remotely attest the second application, the attestation service can be called in the target trusted storage module to match the benchmark application measurement information and the application measurement information according to the first verification strategy, thereby obtaining the first remote attestation result.

[0086] In some embodiments, the first application may also obtain the attestation service and the first verification strategy from the target trusted storage module, and locally call the attestation service in the first application to match the benchmark application measurement information and the application measurement information according to the first verification strategy, thereby obtaining a first remote attestation result. This embodiment does not impose any restrictions on this.

[0087] In some embodiments, the first proof evidence includes at least one of the following:

[0088] The application identification information of the second application, where the application identification information (ID) is used to uniquely identify the second application.

[0089] The application version information (version) of the second application is used to mark the current version of the second application.

[0090] At least one remote attestation type of the second application. Since the second application may run in different trusted execution environments, for example, it may run in trusted execution environments such as Intel SGX, TDX, AMD SEV, ARM TrustZone, etc., different remote attestation methods are used for second applications in different trusted execution environments. Therefore, different remote attestation types are set to distinguish the remote attestation of second applications running in different environments.

[0091] At least one application metric information of the second application, the application metric information being associated with the remote attestation type. Since the second application may run in different trusted execution environments, the code and data of the second application in different trusted execution environments may differ to a certain extent, and thus the corresponding application metric information may also differ. Furthermore, since both are related to the trusted execution environment in which the second application runs, and the application metric information is related to the remote attestation method, the remote attestation type and the application metric information are associated, for example, there is a one-to-one correspondence between the remote attestation type and the application metric information.

[0092] In some embodiments, the first attestation evidence is uploaded and stored in the target trusted storage module when the second application is created or updated, that is, the application identification information, application version information, at least one remote attestation type and at least one application measurement value information of the second application are uploaded and stored in the target trusted storage module when the second application is created or updated.

[0093] In some embodiments, when the second application is created or updated, it also obtains its own developer measurement value, uploads it, and stores it in the target trusted storage module for use when needed.

[0094] In some embodiments, when the second application is created or updated, it will also obtain its own second verification policy and store it in the target trusted storage module, so that when the second application needs to remotely certify other applications including the first application, it can obtain the second verification policy from the target trusted storage module, and then call the certification service deployed in the target trusted storage module to remotely certify other applications including the first application according to the second verification policy.

[0095] Taking the bidirectional remote attestation between a first application and a second application as an example, when the first application is developed or updated in the first trusted execution environment, the first application needs to upload and store the second attestation evidence in the target trusted storage module. The second attestation evidence includes at least one of the following:

[0096] The application identification information of the first application, where the application identification information (ID) is used to uniquely identify the first application.

[0097] The application version information (version) of the first application is used to mark the current version of the first application.

[0098] At least one remote attestation type of the first application. Since the first application may run in different trusted execution environments, for example, it may run in trusted execution environments such as Intel SGX, TDX, AMD SEV, ARM TrustZone, etc., different remote attestation methods are used for first applications in different trusted execution environments. Therefore, different remote attestation types are set to distinguish the remote attestation of the first application running in different environments.

[0099] At least one application metric information of the first application, the application metric information being associated with the remote attestation type. Since the first application may run in different trusted execution environments, the code and data of the first application in different trusted execution environments may differ to a certain extent, and thus the corresponding application metric information may also differ. Furthermore, since both are related to the trusted execution environment in which the first application runs, and the application metric information is related to the remote attestation method, the remote attestation type and the application metric information are associated, for example, there is a one-to-one correspondence between the remote attestation type and the application metric information.

[0100] For the bidirectional remote attestation between the first application and the second application, when the first remote attestation result is that the attestation passes, the method further includes:

[0101] Step S401: Generate a second certification response and send it to the second application.

[0102] After the first application successfully completes the remote attestation of the second application, it generates a second attestation response and sends the second attestation response to the second application. After the second application receives the second attestation response, it executes step S403.

[0103] Step S403: Instruct the second application to execute steps S4031 to S4033:

[0104] Step S4031: Obtain second proof evidence of the first application from a target trusted storage module, where the second proof evidence is uploaded by the first application and stored in the target trusted storage module.

[0105] The second application can obtain the second attestation evidence of the first application from the target trusted storage module. The second attestation evidence is the benchmark value used for remote attestation of the first application. The second attestation evidence is pre-uploaded by the first application and stored in the target trusted storage module. For example, after the first application is developed or updated, the second attestation evidence of the first application is uploaded and stored in the target trusted storage module. In this way, when the second application needs to remotely attest the first application, it can obtain the latest second attestation evidence from the target trusted storage module as the benchmark value for remote attestation of the first application.

[0106] At the same time, since the second proof evidence is stored in the target trusted storage module, it does not need to be stored in the application. This will not cause changes in the proof evidence of the application itself, and will not affect the subsequent remote proof of the application. At the same time, when a new application is added or an application is updated, it is only necessary to obtain the proof evidence of the new application or the updated new version of the application and upload and store it in the trusted storage module. When other applications need to initiate a remote proof request for the new application or the new version of the application, the requester application can directly obtain its latest proof evidence from the trusted storage module as a baseline value to process remote proof, without having to worry about the latest proof evidence not being stored in the code or configuration information of the requester application.

[0107] Step S4033: remotely obtain a second remote attestation result for the first application based on the second attestation response and the second attestation evidence.

[0108] After the second application obtains the second attestation response returned by the first application and the second attestation evidence as a reference value, the second application can remotely attest to the first application based on the second attestation response and the second attestation evidence, thereby obtaining a second remote attestation result for the first application.

[0109] In this embodiment, since the first application has already uploaded the second proof evidence as the remote proof reference value to the target trusted storage module in advance, when the second application needs to remotely prove the first application, it can directly obtain the second proof evidence as the reference value from the target trusted storage module, and perform remote proof in combination with the second proof response directly obtained from the first application, thereby obtaining the final remote proof result. In this process, since the second proof evidence as the reference value is stored in the target trusted storage module rather than in the second application, this will not cause the proof evidence of the second application itself to change, and will not affect the subsequent remote proof of the second application, that is, there is no need to worry about the circular dependency problem caused by two-way proof; at the same time, since the second proof evidence is uploaded and stored in the target trusted storage module, when the first application is a new application or the first application is updated, it only needs to obtain the proof evidence of the new version of the first application and upload and store it in the target trusted storage module. When the second application remotely proves the second application, it will obtain the second proof evidence corresponding to the latest version of the first application from the target trusted storage module as the reference value for remote proof, thereby enabling remote proof between applications even in the case of new applications or application updates.

[0110] In some embodiments, the second attestation response includes a second remote attestation report, which may include hardware TCB information, application metrics, application-defined data, hardware signatures, and other information. Through the second remote attestation report, the second application can confirm that the first application is running on a trusted hardware platform and that the application's operating logic has not been tampered with, thereby ensuring data security in subsequent communications with the first application.

[0111] In some embodiments, the second attestation response may also include authentication information used to authenticate the first application, so that the first application can authenticate the first application based on the authentication information, thereby ensuring data security in subsequent communications with the first application. The second attestation response may also include other information used to remotely attest the first application to ensure secure communication between the second application and the first application, which is not limited in this embodiment.

[0112] In some embodiments, the second attestation evidence includes baseline application metric information of the first application, where the baseline application metric information is generated based on creation or update of the first application in the first trusted execution environment and uploaded to the target trusted storage module.

[0113] In some embodiments, when the second attestation evidence includes baseline application metric information of the first application, performing remote attestation based on the second attestation response and the second attestation evidence to obtain a second remote attestation result for the first application includes:

[0114] Step S501, determining whether the second remote certification report meets preset conditions.

[0115] In this embodiment, the second remote attestation report also includes a hardware signature. After obtaining the second remote attestation report, the hardware signature in the second remote attestation report can be obtained and verified to determine whether the second remote attestation report meets preset conditions, thereby determining whether the second remote attestation report is a remote attestation report generated by a trusted application running in a trusted execution environment.

[0116] Among them, the smart contract can be called to verify the hardware signature, or other feasible methods can be used to verify the hardware signature to determine whether the second remote attestation report meets the preset conditions. This embodiment does not impose any restrictions on this.

[0117] Step S503: In response to the second remote attestation report meeting a preset condition, obtaining application metric information of the first application based on the second remote attestation report, and verifying the baseline application metric information and the application metric information.

[0118] Step S505: In response to the benchmark application metric information and the application metric information matching, determining that the second remote attestation result is attestation passed.

[0119] Step S507: In response to the mismatch between the benchmark application metric information and the application metric information, determining that the second remote attestation result is attestation failure.

[0120] In this embodiment, when the second attestation evidence is the baseline application measurement information of the first application, the second remote attestation report is parsed to obtain the application measurement information of the first application from the second remote attestation report, and verification is performed based on the baseline application measurement information obtained from the target trusted storage module and the application measurement information sent from the first application: when the baseline application measurement information and the application measurement information match, it can be determined that the second remote attestation result of the second application to the first application is passed; when the baseline application measurement information and the application measurement information do not match, it can be determined that the second remote attestation result of the second application to the first application is failed.

[0121] In some embodiments, before performing remote attestation based on the second attestation response and the second attestation evidence in step S107, the method further includes:

[0122] Step S601: Obtain additional information in the second certification response.

[0123] Step S603: Acquire second information based on the second remote attestation report, and determine an association relationship between the second remote attestation report and the first application based on the additional information and the second information.

[0124] The additional information may include the public key of the first application or a random number generated by the first application, and this embodiment does not impose any limitation on this.

[0125] At the same time, the second remote attestation report also stores information such as the public key of the first application or the random number generated by the first application, i.e., the second information. In this embodiment, whether the second remote attestation report comes from the first application is determined based on the additional information and the second information obtained from the second remote attestation report. When the additional information is consistent with the second information, it indicates that the second remote attestation report comes from the first application and no replay attack has occurred; when the additional information is inconsistent with the second information, it indicates that the second remote attestation report does not come from the first application and a replay attack has occurred. Therefore, the setting of additional information can prevent replay attacks.

[0126] In some embodiments, the method further includes: obtaining a second verification strategy for the second application from a target trusted storage module; the second verification strategy is uploaded and stored in the target trusted storage module by the second application, and the second verification strategy is used for the second application to remotely authenticate other applications, and the other applications include the first application.

[0127] The remote attestation based on the second attestation response and the second attestation evidence includes: verifying the second attestation response and the second attestation evidence based on the second verification strategy.

[0128] When a second application is created or updated in the second trusted execution environment, it can upload and store the second verification policy in the target trusted storage module. When the second application needs to remotely attest other applications, including the first application, it retrieves its second verification policy from the target trusted storage module and verifies the other applications, including the first application, based on the second verification policy.

[0129] Among them, the second verification strategy is the strategy used by the second application when remotely certifying other applications including the first application, including verification content, verification logic and other information.

[0130] In some embodiments, the method further includes: setting the attestation service in the smart contract of the target trusted storage module; the verification based on the second attestation response and the second attestation evidence includes: verifying the second attestation response and the second attestation evidence based on the second verification strategy through the smart contract.

[0131] That is, in this embodiment, the attestation service used to implement remote attestation can be deployed as a smart contract to the target trusted storage module. When the second application needs to remotely attest to the first application, the attestation service can be called in the target trusted storage module to match the benchmark application measurement information and the application measurement information according to the second verification strategy, thereby obtaining the second remote attestation result.

[0132] In some embodiments, the second application may also obtain the attestation service and the second verification strategy from the target trusted storage module, and locally call the attestation service in the second application to match the benchmark application measurement information and the application measurement information according to the second verification strategy, thereby obtaining a second remote attestation result. This embodiment does not impose any restrictions on this.

[0133] In some embodiments, when the second remote attestation result is that the attestation is passed, the method further includes:

[0134] Step S701: Obtain the public key of the second application, generate a first session key based on the private key of the first application and the public key of the second application, and communicate with the second application based on the first session key; and

[0135] Step S703: Enable the second application to obtain the public key of the first application, generate a second session key based on the private key of the second application and the public key of the first application, and communicate with the first application based on the second session key; wherein the first session key is the same as the second session key.

[0136] In this embodiment, when the second application generates a first remote attestation report, it also generates a key pair, and sends the public key in the key pair together with the first remote attestation report to the first application; correspondingly, when the first application generates a second remote attestation report, it also generates a key pair, and sends the public key in the key pair together with the second remote attestation report to the second application.

[0137] When the two-way remote attestation between the first application and the second application is successful, the first application and the second application each calculate a session key based on their own private key and the other party's public key, and the session keys calculated by the two are the same. In this way, the first application and the second application can encrypt and protect the interactive data between them based on the session key.

[0138] In some embodiments, the method further includes: in response to the first application and / or the second application being open source applications, uploading and storing application codes of the first application and / or the second application to a public address.

[0139] In this embodiment, when the first application and / or the second application are open source applications, after the development of the first application and / or the second application is completed or the application is updated, the application code of the first application and / or the second application is uploaded to a public address in the form of source code or image, so that users or other developers can review the code and reproduce the measurement values.

[0140] The public address may be a target trusted storage module or other platforms, which is not limited in this embodiment.

[0141] In this embodiment, by uploading information such as application measurement values ​​and verification strategies to a trusted storage module, the trusted application information and verification strategies are saved through the trusted storage module, thereby avoiding the application directly using the application measurement values ​​to be verified as part of its own code, solving the circular dependency problem during two-way remote attestation between trusted applications, and enabling verification between multiple trusted applications; when the application undergoes version iteration, the latest application information or verification strategy can be uploaded to the trusted storage module. When performing remote attestation, the latest application information is obtained as a verification benchmark value, and verification is performed according to the latest strategy, thereby solving the verification problem during application updates.

[0142] FIG3 shows a schematic diagram of an exemplary network architecture according to an embodiment of the present disclosure.

[0143] As shown in FIG3 , the network architecture includes a first trusted computing node and a second trusted computing node, wherein the first trusted computing node may be the second trusted computing node, or the first trusted computing node is different from the second trusted computing node.

[0144] A first trusted execution environment is deployed in the first trusted computing node, and a first application is running in the first trusted execution environment. A second trusted execution environment is deployed in the second trusted computing node, and a second application is running in the second trusted execution environment. Both the first trusted execution environment and the second trusted execution environment include interface programs for callers to communicate, as well as trusted computing programs that actually perform computing processes.

[0145] The first application and the second application can communicate with the interface program through a network connection. For example, when the first trusted computing node is different from the second trusted computing node, the first application, the second application and the interface program establish an encrypted channel to achieve encrypted communication between the first application and the second application. When the first trusted computing node and the second trusted computing node are the same hardware node, it can be considered that the first trusted execution environment and the second trusted execution environment are both deployed on the first trusted computing node, that is, the trusted application and the interface program run on the same hardware node. Therefore, the trusted application can directly make local calls to the interface program without establishing a network connection. Of course, communication can also be carried out through a network connection. It should also be pointed out that when the first trusted computing node and the second trusted computing node are the same hardware node, the second trusted execution environment and the first trusted execution environment can be the same trusted execution environment, or the second trusted execution environment can be different from the first trusted execution environment. This specification does not impose any restrictions on this.

[0146] The first trusted computing node and the second trusted computing node involved in the embodiments of this specification may be hardware / virtual devices that can run computer programs to implement arbitrary logical functions.

[0147] The Trusted Execution Environment (TEE) involved in the embodiments of this specification can provide a secure execution environment for software. TEE is a trusted execution environment based on the security extension of CPU hardware and is completely isolated from the outside world.

[0148] The first application and the second application involved in the embodiments of this specification are trusted applications. Trusted applications refer to applications that run in TEE and are implemented using verifiable computing technology.

[0149] The following takes the remote certification method between the first application and the second application as an example to further illustrate the technical solution of this application.

[0150] First, after hardware manufacturers implement TEE and remote attestation mechanisms, they will provide basic libraries and interfaces related to verifying remote attestation reports. Developers or cloud service providers can provide easy-to-use attestation services based on these basic interfaces and deploy these attestation services as smart contracts in the target trusted storage module.

[0151] After development is complete, the first and second applications upload their respective application information and verification strategies to the target trusted storage module. The first application's application information includes its application identification information, application version information, remote attestation type, and application metrics; the second application's application information includes its application identification information, application version information, remote attestation type, and application metrics.

[0152] The first application uploads and stores its application information to the target trusted storage module as the second proof evidence, which is the benchmark value used by other applications when remotely certifying the first application; the second application uploads and stores its application information to the target trusted storage module as the first proof evidence, which is the benchmark value used by other applications when remotely certifying the second application.

[0153] At the same time, the first application will also upload and store its second verification information to the target trusted storage module. The second verification strategy is the strategy used by the second application when remotely certifying the first application, including verification content, verification logic and other information; the second application will upload and store its first verification information to the target trusted storage module. The first verification strategy is the strategy used by the first application when remotely certifying the second application, including verification content, verification logic and other information.

[0154] When the first application and / or the second application are open source applications, the application code of the first application and / or the second application will also be uploaded to a public address in the form of source code or image, so that users or other developers can review the code and reproduce the measurement values.

[0155] When a first application wants to remotely authenticate a second application, the first application may generate a first request value and send it to the second application, thereby initiating a remote authentication request to the second application. The first request value may be a random number generated by the first application.

[0156] After receiving the first request value sent by the first application, the second application generates a first remote attestation report, a key pair, and additional information based on the remote attestation request initiated by the first application. The second application then returns the first remote attestation report, the public key in the key pair, and the additional information to the first application as a first attestation response. The first application obtains the application information uploaded by the second application, namely the first attestation evidence, from the target trusted storage module. Simultaneously, the first application also obtains the first verification policy of the first application from the target trusted storage module.

[0157] Afterwards, the first application takes the first verification strategy, the application information of the second application, the first remote attestation report, and the additional information as input, calls the smart contract on the target trusted storage module, verifies it through the attestation service, and returns the attestation result.

[0158] In this process, based on the verification content, verification logic and other information of the first verification strategy, the first application first verifies whether the first remote attestation report is an attestation report that meets the preset conditions, thereby determining whether the first remote attestation report is a remote attestation report generated by a trusted application running in a trusted execution environment; after proving that the report meets the preset conditions, the first remote attestation report is parsed to obtain the application measurement information in the first remote attestation, and it is verified whether the application measurement information matches the benchmark application measurement information in the first attestation evidence, and whether the first information obtained from the first remote attestation report is consistent with the additional information, and the first remote attestation result is returned to the first application.

[0159] When the first remote attestation result is verification passed, the first application also generates a key pair, a second remote attestation report and additional information as a second attestation response and sends them to the second application.

[0160] The second application uses the same method to remotely attest the first application. This involves: The second application retrieves the application information uploaded by the first application, known as the second attestation evidence, from the target trusted storage module. Simultaneously, the second application also retrieves the second verification policy for the second application from the target trusted storage module. The second application then uses the second verification policy, the first application's application information, the second remote attestation report, and additional information as input. It then invokes the smart contract on the target trusted storage module, verifies the information through the attestation service, and returns the second remote attestation result.

[0161] If the second remote attestation result is also verified, the two-way remote attestation between the first application and the application is passed. The first application and the second application both calculate the session key based on their own private key and the other party's public key, and the session keys calculated by the two are the same. In this way, the first application and the second application can encrypt and protect the interactive data between them based on the session key.

[0162] If the application is updated, taking the update of the second application as an example: the second application will upload and store the new application measurement information obtained after the update to the target trusted storage module; when the first application remotely certifies the second application, it will obtain the latest application measurement information of the second application from the target trusted storage module as a baseline value, and then compare it with the application measurement information in the remote certification report obtained from the second application, so as to realize the remote certification of the second application by the first application.

[0163] If a new trusted application is added, take the newly added third application as an example: after the development of the third application is completed, its own application measurement information will be uploaded and stored in the target trusted storage module. When the first application needs to remotely certify the third application or needs to update the verification method for the application, the developer can update the first inspection strategy of the first application, add the inspection strategy for the third application to the first inspection strategy, and upload the new first inspection strategy to the target trusted storage module. When the first application remotely certifies the third application, it can obtain the latest first inspection strategy and the application measurement information of the third application from the target trusted storage module to verify the remote certification report process obtained from the third application, thereby obtaining the remote certification result of the first application to the third application.

[0164] It is understandable that before using the technical solutions of each embodiment of the present disclosure, the type, scope of use, usage scenarios, etc. of the personal information involved will be informed to the user in an appropriate manner, and the user's authorization will be obtained.

[0165] For example, in response to a user's active request, a prompt message is sent to the user to clearly inform the user that the requested operation will require the acquisition and use of the user's personal information. This allows the user to independently choose whether to provide personal information to the electronic device, application, server, storage medium, or other software or hardware that performs the operation of the disclosed technical solution based on the prompt message.

[0166] As an optional but non-limiting implementation, in response to a user's active request, the prompt information may be sent to the user in the form of a pop-up window, in which the prompt information may be presented in text form. Furthermore, the pop-up window may also contain a selection control for the user to select "agree" or "disagree" to provide personal information to the electronic device.

[0167] It is understandable that the above notification and user authorization process are merely illustrative and do not constitute a limitation on the implementation of the present disclosure. Other methods that comply with relevant laws and regulations may also be applied to the implementation of the present disclosure.

[0168] It should be noted that the method of the embodiments of the present disclosure can be performed by a single device, such as a computer or server. The method of the embodiments of the present disclosure can also be applied in a distributed scenario, where multiple devices cooperate to perform the method. In such a distributed scenario, one of the multiple devices may only perform one or more steps of the method of the embodiments of the present disclosure, and the multiple devices will interact with each other to complete the method.

[0169] It should be noted that the above description is limited to some embodiments of the present disclosure. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in an order different from that described in the above embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the specific order or sequential order shown to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0170] Based on the same inventive concept, corresponding to any of the above-mentioned embodiments and methods, the present disclosure further provides a remote attestation device, which includes a first application running in a first trusted execution environment.

[0171] Referring to FIG4 , the apparatus includes:

[0172] The request module 11 is configured to: initiate a remote attestation request to a second application, where the second application runs in a second trusted execution environment;

[0173] The returning module 13 is configured to: obtain a first certification response returned by the second application;

[0174] The acquisition module 15 is configured to: acquire first attestation evidence of the second application from a target trusted storage module, the first attestation evidence being uploaded by the second application and stored in the target trusted storage module;

[0175] The attestation module 17 is configured to: perform remote attestation based on the first attestation response and the first attestation evidence, and obtain a first remote attestation result for the second application.

[0176] In some embodiments, the first attestation response includes a first remote attestation report generated based on the remote attestation request.

[0177] In some embodiments, the first attestation evidence includes baseline application metric information of the second application, the baseline application metric information being generated based on creation or update of the second application in the second trusted execution environment and uploaded to the target trusted storage module.

[0178] In some embodiments, the certification module 17 is further configured to:

[0179] Determining whether the first remote attestation report meets a preset condition;

[0180] In response to the first remote attestation report meeting a preset condition, obtaining application metric information of the second application based on the first remote attestation report, and verifying the baseline application metric information and the application metric information;

[0181] In response to the benchmark application metric information and the application metric information matching, determining the first remote attestation result as attestation passed;

[0182] In response to the baseline application metric information and the application metric information not matching, determining the first remote attestation result as attestation failure.

[0183] In some embodiments, before performing remote attestation based on the first attestation response and the first attestation evidence, the device is further configured to: obtain additional information in the first attestation response; obtain first information based on the first remote attestation report, and determine the association relationship between the first remote attestation report and the second application based on the additional information and the first information.

[0184] In some embodiments, the apparatus is further configured to: obtain a first verification policy of the first application from a target trusted storage module; the first verification policy is uploaded by the first application and stored in the target trusted storage module, the first verification policy being used for remote attestation of other applications by the first application, the other applications including the second application;

[0185] The certification module 17 is further configured to verify the first certification response and the first certification evidence based on the first verification strategy.

[0186] In some embodiments, the apparatus is further configured to: set an attestation service in a smart contract of the target trusted storage module;

[0187] The certification module 17 is further configured to: verify the first certification response and the first certification evidence based on the first verification strategy through the smart contract.

[0188] In some embodiments, the first proof evidence includes at least one of the following:

[0189] application identification information of the second application;

[0190] application version information of the second application;

[0191] at least one remote attestation type of the second application;

[0192] at least one application metric information of the second application, wherein the application metric information is associated with the remote attestation type.

[0193] In some embodiments, in response to the first remote attestation result being a passed attestation, the apparatus is further configured to:

[0194] Generate a second attestation response and send it to the second application, causing the second application to perform the following steps:

[0195] Obtaining second attestation evidence of the first application from a target trusted storage module, where the second attestation evidence is uploaded by the first application and stored in the target trusted storage module;

[0196] A second remote attestation result for the first application is remotely obtained based on the second attestation response and the second attestation evidence.

[0197] In some embodiments, in response to the second remote attestation result being a passed attestation, the apparatus is further configured to:

[0198] obtaining a public key of the second application, generating a first session key based on the private key of the first application and the public key of the second application, and communicating with the second application based on the first session key; and

[0199] enabling the second application to obtain the public key of the first application, generate a second session key based on the private key of the second application and the public key of the first application, and communicate with the first application based on the second session key;

[0200] The first session key is the same as the second session key.

[0201] In some embodiments, the apparatus is further configured to:

[0202] In response to the first application and / or the second application being open source applications, application codes of the first application and / or the second application are uploaded and stored to a public address.

[0203] For the convenience of description, the above devices are described as being functionally divided into various modules. Of course, when implementing the present disclosure, the functions of each module can be implemented in the same or multiple software and / or hardware.

[0204] The apparatus of the above embodiment is used to implement the corresponding remote attestation method in any of the above embodiments, and has the beneficial effects of the corresponding method embodiment, which will not be described in detail here.

[0205] Based on the same inventive concept, corresponding to any of the above-mentioned embodiments and methods, the present disclosure also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and runnable on the processor, wherein when the processor executes the program, the remote attestation method described in any of the above embodiments is implemented.

[0206] FIG5 shows a more specific schematic diagram of the hardware structure of an electronic device provided in this embodiment. The device may include: a processor 1010, a memory 1020, an input / output interface 1030, a communication interface 1040, and a bus 1050. The processor 1010, the memory 1020, the input / output interface 1030, and the communication interface 1040 are communicatively connected to each other within the device via the bus 1050.

[0207] The processor 1010 can be implemented using a general-purpose CPU (Central Processing Unit), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this specification.

[0208] The memory 1020 can be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage devices, dynamic storage devices, etc. The memory 1020 can store an operating system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 1020 and is called and executed by the processor 1010.

[0209] The input / output interface 1030 is used to connect input / output modules to implement information input and output. The input / output modules can be configured as components within the device (not shown in the figure) or can be externally connected to the device to provide corresponding functions. Input devices may include a keyboard, mouse, touch screen, microphone, various sensors, etc., and output devices may include a display, speaker, vibrator, indicator light, etc.

[0210] The communication interface 1040 is used to connect to a communication module (not shown) to enable communication between the device and other devices. The communication module can communicate via a wired method (such as USB, network cable, etc.) or a wireless method (such as mobile network, WiFi, Bluetooth, etc.).

[0211] The bus 1050 comprises a path for transmitting information between the various components of the device (eg, the processor 1010 , the memory 1020 , the input / output interface 1030 , and the communication interface 1040 ).

[0212] It should be noted that although the above device only shows the processor 1010, the memory 1020, the input / output interface 1030, the communication interface 1040, and the bus 1050, in a specific implementation, the device may also include other components necessary for normal operation. In addition, it will be understood by those skilled in the art that the above device may only include the components necessary to implement the embodiments of this specification, and does not necessarily include all the components shown in the figure.

[0213] The electronic device of the above embodiment is used to implement the corresponding remote certification method in any of the above embodiments, and has the beneficial effects of the corresponding method embodiment, which will not be repeated here.

[0214] Based on the same inventive concept, corresponding to any of the above-mentioned embodiment methods, the present disclosure also provides a non-transitory computer-readable storage medium, which stores computer instructions, and the computer instructions are used to enable the computer to execute the remote attestation method described in any of the above embodiments.

[0215] The computer-readable media of this embodiment include permanent and non-permanent, removable and non-removable media that can be used to store information by any method or technology. The information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, read-only compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device.

[0216] The computer instructions stored in the storage medium of the above embodiment are used to enable the computer to execute the remote certification method described in any of the above embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0217] Those skilled in the art should understand that the discussion of any of the above embodiments is merely illustrative and is not intended to imply that the scope of the present disclosure (including the claims) is limited to these examples. Within the scope of the present disclosure, the technical features in the above embodiments or different embodiments may be combined, the steps may be implemented in any order, and there are many other variations of the different aspects of the embodiments of the present disclosure as described above, which are not provided in detail for the sake of simplicity.

[0218] In addition, to simplify the description and discussion, and so as not to obscure the embodiments of the present disclosure, known power / ground connections to integrated circuit (IC) chips and other components may or may not be shown in the provided figures. In addition, devices may be shown in the form of block diagrams to avoid obscuring the embodiments of the present disclosure, and this also takes into account the fact that the details of the implementation of these block diagram devices are highly dependent on the platform on which the embodiments of the present disclosure are to be implemented (i.e., these details should be fully within the purview of those skilled in the art). Where specific details (e.g., circuits) are set forth to describe exemplary embodiments of the present disclosure, it will be apparent to those skilled in the art that the embodiments of the present disclosure may be implemented without these specific details or with variations in these specific details. Therefore, these descriptions should be considered illustrative rather than restrictive.

[0219] Although the present disclosure has been described in conjunction with specific embodiments thereof, many alternatives, modifications, and variations of these embodiments will be apparent to those skilled in the art based on the foregoing description. For example, other memory architectures (e.g., dynamic RAM (DRAM)) may use the embodiments discussed.

[0220] The embodiments of the present disclosure are intended to cover all such substitutions, modifications, and variations that fall within the broad scope of the appended claims. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the embodiments of the present disclosure should be included in the scope of protection of the present disclosure.

Claims

1. A remote attestation method, applied to a first application, wherein the first application runs in a first trusted execution environment; the method comprises: Initiating a remote attestation request to a second application, the second application running in a second trusted execution environment; Obtaining a first certification response returned by the second application; Acquire a first proof evidence of the second application from a target trusted storage module, the first proof evidence being uploaded by the second application and stored in the target trusted storage module; Remote attestation is performed based on the first attestation response and the first attestation evidence to obtain a first remote attestation result for the second application.

2. The method according to claim 1, wherein: The first attestation response includes a first remote attestation report generated based on the remote attestation request.

3. The method according to claim 2, wherein: The first attestation evidence includes benchmark application metric information of the second application, where the benchmark application metric information is generated based on creation or update of the second application in the second trusted execution environment and uploaded to the target trusted storage module.

4. The method according to claim 3, wherein: The performing remote attestation based on the first attestation response and the first attestation evidence to obtain a first remote attestation result for the second application includes: Determining whether the first remote attestation report meets a preset condition; In response to the first remote attestation report meeting a preset condition, obtaining application metric information of the second application based on the first remote attestation report, and verifying the baseline application metric information and the application metric information; In response to the benchmark application metric information and the application metric information matching, determining that the first remote attestation result is attestation passed; In response to the baseline application metric information and the application metric information not matching, determining the first remote attestation result as attestation failure.

5. The method according to claim 2, wherein: Before performing remote attestation based on the first attestation response and the first attestation evidence, the method further includes: Obtaining additional information in the first attestation response; First information is obtained based on the first remote attestation report, and an association relationship between the first remote attestation report and the second application is determined based on the additional information and the first information.

6. The method according to claim 1, further comprising: Acquire a first verification strategy for the first application from a target trusted storage module; The first verification strategy is uploaded by the first application and stored in the target trusted storage module, the first verification strategy is used for the first application to remotely prove other applications, and the other applications include the second application; The performing remote attestation based on the first attestation response and the first attestation evidence includes: The first attestation response and the first attestation evidence are verified based on the first verification strategy.

7. The method according to claim 6, further comprising: Setting the attestation service in the smart contract of the target trusted storage module; The verifying based on the first attestation response and the first attestation evidence includes: The first attestation response and the first attestation evidence are verified by the smart contract based on the first verification strategy.

8. The method according to claim 1, wherein: The first proof includes at least one of the following: application identification information of the second application; application version information of the second application; at least one remote attestation type of the second application; At least one application metric information of the second application, wherein the application metric information is associated with the remote attestation type.

9. The method according to any one of claims 1 to 8, wherein: In response to the first remote attestation result being that the attestation is passed, the method further includes: Generate a second attestation response and send it to the second application, so that the second application performs the following steps: Acquire a second proof evidence of the first application from a target trusted storage module, the second proof evidence being uploaded by the first application and stored in the target trusted storage module; A second remote attestation result for the first application is remotely obtained based on the second attestation response and the second attestation evidence.

10. The method according to claim 9, wherein: In response to the second remote attestation result being that the attestation is passed, the method further includes: obtaining a public key of the second application, generating a first session key based on the private key of the first application and the public key of the second application, and communicating with the second application based on the first session key; and, enabling the second application to obtain the public key of the first application, generating a second session key based on the private key of the second application and the public key of the first application, and communicating with the first application based on the second session key; The first session key is the same as the second session key.

11. The method according to claim 1, further comprising: In response to the first application and / or the second application being open source applications, application codes of the first application and / or the second application are uploaded and stored at a public address.

12. A remote attestation device, comprising a first application, wherein the first application runs in a first trusted execution environment; The device also includes: A request module is configured to: initiate a remote attestation request to a second application, wherein the second application runs in a second trusted execution environment; A return module is configured to: obtain a first certification response returned by the second application; an acquisition module, configured to: acquire first proof evidence of the second application from a target trusted storage module, the first proof evidence being uploaded by the second application and stored in the target trusted storage module; The attestation module is configured to: perform remote attestation based on the first attestation response and the first attestation evidence to obtain a first remote attestation result for the second application.

13. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, the remote attestation method according to any one of claims 1 to 11 is implemented.

14. A non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause the computer to execute the remote attestation method according to any one of claims 1 to 11.

Images