Remote attestation method and apparatus, electronic device and storage medium

Abstract

Provided in the present disclosure are a remote attestation method and apparatus, an electronic device and a storage medium. The method is applied to a first trusted execution environment and comprises: acquiring a first file for a first application, the first file being used for deploying the first application in the first trusted execution environment, and the first file comprising a read-only target file system; acquiring a first metric value for the target file system; loading the first file, writing the first metric value into a command line for starting a kernel and, on the basis of the command line, starting the kernel in the first file so as to deploy the first application in the first trusted execution environment; and measuring the kernel and other components to obtain a second metric value, so as to perform remote attestation on the first application on the basis of the second metric value.

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 December 29, 2023, with application number 202311864003.5. The entire contents of that application are incorporated by reference into this application. Technical Field

[0002] The present disclosure relates to the field of computer technology, 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. During remote attestation, the measurement values ​​returned by the attestation process are compared with the baseline values ​​determined based on the source code / image provided by the service provider to determine the remote attestation results.

[0005] However, in related technologies, it is impossible to measure the code and data in the operating system, resulting in the user being unable to verify that the current application is consistent with that generated by the service provider. 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 objectives, the first aspect of the present disclosure provides a remote attestation method, which is applied to a first trusted execution environment; the method includes:

[0008] Obtaining a first file for a first application, where the first file is used to deploy the first application in the first trusted execution environment, and the first file includes a read-only target file system;

[0009] Obtaining a first metric value for the target file system;

[0010] Loading the first file, writing the first metric value into a command line for starting a kernel, and starting the kernel in the first file based on the command line to deploy the first application in the first trusted execution environment;

[0011] The kernel and other components are measured to obtain a second measurement value, so as to remotely attest to the first application based on the second measurement value.

[0012] In some embodiments, the first file includes a virtual machine image file, and the virtual machine image file includes service information, component information, and environment information for running the first application.

[0013] In some embodiments, the target file system is a root file system.

[0014] In some embodiments, starting the kernel to execute the first file based on the command line includes:

[0015] verifying the first metric value through the kernel;

[0016] If the first measurement value is correct, the kernel is measured.

[0017] In some embodiments, verifying the first metric value by the kernel includes:

[0018] During the process of starting the kernel in the first file, measuring the target file system in the first file to obtain a third measurement value;

[0019] Determining whether the third metric value is the same as the first metric value;

[0020] If the third metric value is the same as the first metric value, the first metric value is correct.

[0021] In some embodiments, measuring the kernel and other components to obtain a second metric value includes:

[0022] Measuring a kernel image, a command line, and other components of the kernel to generate a second metric value, where the second metric value includes one metric value or a combination of multiple metric values;

[0023] The second metric value is stored in a register matching the first trusted execution environment.

[0024] In some embodiments, remotely attesting the first application based on the second metric value includes:

[0025] receiving a remote attestation request sent by a second application, the second application running in a second trusted execution environment;

[0026] generating, based on the remote attestation request, remote attestation evidence including the second metric value;

[0027] The remote attestation evidence is sent to the second application or remote attestation service, so that the second application or the remote attestation service obtains the second metric value from the remote attestation evidence and verifies the first application based on the second metric value.

[0028] In some embodiments, the remote attestation evidence includes a remote attestation report, and the second metric value is stored in the remote attestation report; the method further includes:

[0029] The second application or the remote attestation service obtains code information and related information of the first file when the first application is running in the first trusted execution environment, and obtains a fourth metric value based on the code information and the related information, wherein a measurement method of the fourth metric value is the same as a measurement method of the second metric value;

[0030] The verifying the first application based on the second metric value includes:

[0031] The second metric value and the fourth metric value are verified based on a preset verification strategy to obtain a remote attestation result for the first application.

[0032] In some embodiments, the remote attestation evidence includes a remote attestation report and a log file of the first file startup phase, and the second metric value is stored in the remote attestation report; the method further includes:

[0033] obtaining the second metric value based on the remote attestation report;

[0034] Obtaining an intermediate metric value of the first file startup phase based on the log file, and calculating a fifth metric value based on the intermediate metric value;

[0035] The verifying the first application based on the second metric value includes:

[0036] The second metric value and the fifth metric value are verified based on a preset verification strategy to obtain a remote attestation result for the first application.

[0037] In some embodiments, before obtaining the intermediate metric value of the first file startup phase based on the log file and calculating the fifth metric value based on the intermediate metric value, the method further includes:

[0038] The second application or the remote attestation service obtains code information and related information of the first file when the first application is running in the first trusted execution environment, and calculates first log information when the system is started based on the code information and the related information;

[0039] Determining whether the first log information is consistent with the second log information in the log file;

[0040] If so, the fifth metric value is calculated based on the log file.

[0041] In some embodiments, the method further comprises:

[0042] Get the encrypted block file;

[0043] Utilizing the encryption storage service in the target file system to interact with the provider of the encrypted block file to obtain a decryption key for the encrypted block file;

[0044] Decrypting the encrypted block file based on the decryption key to obtain a decrypted block file;

[0045] The decrypted block file is mounted to the system of the first trusted execution environment, and a write request for the first application is responded to based on the decrypted block file.

[0046] A second aspect of the present disclosure provides a remote attestation device, comprising:

[0047] A first acquisition module is configured to: acquire a first file for a first application, where the first file is used to deploy the first application in the first trusted execution environment, and the first file includes a read-only target file system;

[0048] A second acquisition module is configured to: acquire a first metric value for the target file system;

[0049] a startup module configured to: load the first file, write the first metric value into a command line for starting a kernel, and start the kernel in the first file based on the command line to deploy the first application in the first trusted execution environment;

[0050] The measurement module is configured to measure the kernel and other components to obtain a second measurement value, so as to remotely certify the first application based on the second measurement value.

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

[0052] 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

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

[0054] FIG1 shows a hardware trust diagram of an exemplary remote attestation method provided by an embodiment of the present disclosure.

[0055] FIG2 shows a hardware trust diagram of an exemplary remote attestation method provided by an embodiment of the present disclosure.

[0056] FIG3 shows a schematic flow chart of an exemplary method provided by an embodiment of the present disclosure.

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

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

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

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

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

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

[0063] 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 partitioning a secure area within the CPU as a TEE. This secure computing environment ensures the confidentiality and integrity of the data and code loaded within it. Trusted applications running in the TEE have access to the full functionality of the device's main processor and memory. Hardware isolation protects these components from user-installed applications running in the main operating system.

[0064] Among them, TDX is a confidential virtualization technology that isolates confidential virtual machines from non-confidential domain software stacks (including virtual machine monitor hypervisor, VMM and other non-trusted domain software stacks) to ensure that the data of confidential virtual machines cannot be obtained and modified by non-confidential domain software.

[0065] SEV is a virtual machine memory encryption technology designed to isolate virtual machines from untrusted virtual machines and hypervisors. SEV includes two derivative technologies: SEV-ES (Encrypted State) and SEV-SNP (Secure Nested Paging). SEV-ES builds on SEV by adding secure encryption of virtual machine register state, while SEV-SNP provides stronger memory integrity protection for virtual machines, preventing active hypervisor attacks.

[0066] A confidential virtual machine is a virtual machine deployed based on trusted execution environment technologies such as TDX, SEV, or CSV.

[0067] 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 its operating logic has not been modified, thereby ensuring data security.

[0068] 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 it. The requester then compares these application metrics with pre-obtained baseline metrics, which can be reproduced using the source code and images publicly available from the service provider. If the application metrics match the baseline metrics, the application's integrity has not been compromised.

[0069] However, in the prior art, when performing remote attestation, it is impossible to measure the code and data in the operating system, resulting in the user being unable to verify that the services provided by the current application are consistent with the services provided by the service provider.

[0070] The remote attestation method, device, electronic device, and storage medium provided by the present disclosure use a second measurement value to remotely attest a first application. The second measurement value based on the measurement result of the kernel is generated, that is, the second measurement value in this application is an overall measurement of the operating system running the first application. During remote attestation, if the remote attestation result of the operating system containing the first application passes, that is, the operating system containing the first application is complete and secure, indicating that the first application running in the operating system is also complete and secure; at the same time, since the kernel is started based on a command line including the first measurement value of the target file system at startup, the second measurement value is generated based on the first measurement value of the target file system. The target file system is a file system mounted on the initial root file system (initrd), which manages the operating system and the data, metadata, files, etc. of the first application running in the operating system. Therefore, the second measurement value generated based on the first measurement value of the target file system can be used to measure the application layer code of the confidential virtual machine, completing the trust transfer from the initial root file system (initrd) -> operating system (OS) during measurement, so that when remote attestation is performed through remote attestation, the security of the first trusted execution environment and the integrity of the running code and data can be verified.

[0071] As shown in Figure 1, for remote attestation-based measurement in a TDX environment, the trust chain is: Firmware (OVMF) -> Bootloader (Shim) -> Multiboot Manager (Grub) -> Kernel (Kernel) -> Initial Root File System (initrd) -> Operating System (OS). In other words, to ensure the operating system (OS) is trustworthy, the initial root file system (initrd) must be trusted; to ensure the initial root file system (initrd) is trustworthy, the kernel (Kernel) must be trusted; to ensure the kernel (Kernel) is trustworthy, the Multiboot Manager (Grub) must be trusted; to ensure the Multiboot Manager (Grub) is trustworthy, the bootloader (Shim) must be trusted; and to ensure the bootloader (Shim) is trustworthy, the firmware (OVMF) must be trusted.

[0072] For measurements in a TDX environment, the existing technology only measures the initial root file system (initrd), and the trust chain is only transferred to the initial root file system (initrd). That is, the trust transfer from the initial root file system (initrd) to the operating system (OS) is missing. This makes it impossible for service users to verify that the current service is consistent with the service provider's claim.

[0073] As shown in Figure 2, for remote attestation-based measurements in the SEV environment, the trust chain is: Firmware (OVMF) -> Multiboot Manager (Grub) -> Kernel -> Initial Root File System (initrd) -> Operating System (OS). In other words, to ensure the operating system (OS) is trustworthy, the initial root file system (initrd) must be trusted; to ensure the initial root file system (initrd) is trustworthy, the kernel (Kernel) must be trusted; to ensure the kernel (Kernel) is trustworthy, the Multiboot Manager (Grub) must be trusted; and to ensure the Multiboot Manager (Grub) is trustworthy, the firmware (OVMF) must be trusted.

[0074] For measurements in the SEV environment, the existing technology only measures the initial root file system (initrd), and the trust chain is only transferred to the initial root file system (initrd). That is, the trust transfer from the initial root file system (initrd) to the operating system (OS) is missing. As a result, the service user (Service User) cannot verify that the current service (Service) is consistent with the service provider (Service Provide) claims.

[0075] In view of this, the present disclosure provides a remote attestation method to solve the above problems.

[0076] Among them, the remote attestation method is applied to the first trusted execution environment, and the first trusted execution environment can be a trusted execution environment such as SGX, TDX, SEV, SEV-ES, SEV-SNP, ARM TrustZone, etc., which is not limited in this embodiment.

[0077] As shown in FIG3 , the remote attestation method includes:

[0078] Step S101: Acquire a first file for a first application, where the first file is used to deploy the first application in the first trusted execution environment, and the first file includes a read-only target file system.

[0079] Step S103: Obtain a first metric value for the target file system.

[0080] The first file for the first application and the first metric value for the target file system may be provided by a service provider or generated in other ways, which is not limited in this embodiment.

[0081] In this embodiment, the service provider needs to create a first file for deploying the first application and provide the first file to the cloud service provider (CSP) that needs to deploy the first application. The cloud service provider provides a cloud server including a first trusted execution environment to deploy the first application based on the first file.

[0082] At the same time, the service provider also measures the target file system in the first file to obtain a first measurement value of the target file system and provides the first measurement value to the cloud service provider. In some embodiments, the first measurement value can be a hash value.

[0083] In this embodiment, the target file system of the first file is set to read-only, which ensures that the first measurement value obtained based on the target file system is consistent and will not change due to the normal operation of the operating system, thereby ensuring that the subsequent use of the first measurement value of the target file system for remote certification will not be adversely affected by the normal operation of the operating system.

[0084] Step S105 : Load the first file, write the first metric value into a command line for starting a kernel, and start the kernel in the first file based on the command line to deploy the first application in the first trusted execution environment.

[0085] In this embodiment, the kernel is part of the first file. When the service provider deploys the first application on a cloud server containing the first trusted execution environment, it needs to load the first file and start the kernel in the first file during the loading process, thereby implementing the deployment of the first application in the first trusted execution environment.

[0086] The kernel is the core of an operating system. It is the first layer of software expansion based on hardware, providing the most basic functions of the operating system. It is the basis for the operation of the operating system. It is responsible for managing the system's processes, memory, device drivers, files, and network systems, and determines the system's performance and stability.

[0087] The kernel may be a kernel that comes with the first file, or a new kernel may be specified during the startup phase, which is not limited in this embodiment.

[0088] Before starting the kernel, the first metric value of the target file system needs to be written into the command line when starting the kernel. When starting the kernel, the kernel behavior is configured and controlled based on the command line including the first metric value of the target file system to start the kernel.

[0089] Step S107: Measure the kernel and other components to obtain a second measurement value, so as to remotely certify the first application based on the second measurement value.

[0090] Among them, other components may include OVMF firmware, Grub, etc., which is not limited in this embodiment.

[0091] In this embodiment, since the command line used to boot the kernel includes the first metric value, the kernel boot process is affected by the first metric value, and the kernel image obtained after the kernel boot is also affected by the first metric value. Therefore, when measuring the kernel and components such as the OVMF firmware and Grub, the kernel, OVMF firmware, and Grub components are actually measured as being affected by the first metric value. Therefore, the second metric value obtained by measuring the kernel, OVMF firmware, and Grub components is generated based on the first metric value, that is, based on the measurement results of the target file system.

[0092] In this case, when the first application is remotely authenticated using the second measurement value, the second measurement value is generated based on the measurement result of the kernel, that is, the second measurement value in this application is an overall measurement of the operating system running the first application. During remote authentication, if the remote authentication result of the operating system containing the first application passes, that is, the operating system containing the first application is complete and secure, it means that the first application running in the operating system is also complete and secure; at the same time, since the kernel is started based on the command line including the first measurement value of the target file system at startup, the second measurement value is generated based on the first measurement value of the target file system. The target file system is a file system mounted on the initial root file system (initrd). The target file system manages the operating system and the data, metadata, files, etc. of the first application running in the operating system. Therefore, the second measurement value generated based on the first measurement value of the target file system can be used to measure the application layer code of the confidential virtual machine, completing the trust transfer from the initial root file system (initrd) -> operating system (OS) during measurement, so that when remote authentication is performed through remote authentication, the security of the first trusted execution environment and the integrity of the running code and data can be verified.

[0093] In some embodiments, the first file includes a virtual machine image file, which includes service information and component information for the first application, as well as information about the environment in which the first application runs. The environment in which the first application runs may include an operating system running the first application. The first application can be deployed in firmware using the virtual machine image file.

[0094] In some embodiments, the target file system is the root file system (rootfs) of the first file. The root file system not only stores data files like a regular file system, but is also the first file system mounted when the kernel boots. The kernel code image file is stored in the root file system. After the root file system is mounted, the system boot program loads initialization scripts (such as rcS and inittab) and services from the root file system into memory for execution. The root file system also contains files necessary for system booting and for mounting other file systems, such as directories and critical files required for operating system startup.

[0095] Therefore, in the embodiment of the present disclosure, based on the first measurement value of the read-only root file system, the first measurement value of the read-only root file system is written into the command line for starting the kernel when starting the kernel, and the kernel is started based on the command line including the first measurement value of the read-only root file system, and the kernel and components such as the OVMF firmware and Grub including the first measurement value are measured to obtain a second measurement value, and then the second measurement value is used for remote attestation, thereby achieving measurement of the application layer code of the confidential virtual machine based on the measurement result of the read-only root file system, completing the trust transfer from the initial root file system (initrd) -> operating system (OS) during measurement, so that when remote attestation is performed through remote attestation, the security of the first trusted execution environment and the integrity of the running code and data can be verified.

[0096] In some embodiments, starting the kernel in the first file based on the command line in step S105 includes:

[0097] Step S201: Verify the first metric value through the kernel.

[0098] The verifying the first metric value by the kernel in step S201 includes:

[0099] Step S301: During the process of starting the kernel in the first file, measure the target file system in the first file to obtain a third measurement value.

[0100] In this embodiment, a kernel with a metric value verification capability is used to start the virtual machine, and the first metric value is verified during the process of starting the virtual machine.

[0101] In some embodiments, during the process of starting the virtual machine, a measurement tool associated with the kernel can be used to measure all files (including the service code itself) in the target file system in the first file to obtain a third measurement value. When the first measurement value is a hash value, the measurement tool is a tool that includes hash value verification capabilities for the target file system.

[0102] In some embodiments, the third metric value can be obtained using the same metric tool as the metric tool used by the service provider to obtain the first metric value to ensure that the measurement process of the first metric value and the third metric value are the same, so that the values ​​of the first metric value and the third metric value are the same when the target file system is the same.

[0103] In some embodiments, when the service provider obtains the first metric value using a metric tool, it may generate a hash tree of files in the virtual machine image rootfs, and obtain the hash value of the root node as the first metric value of the read-only root file system.

[0104] Step S303: Determine whether the third metric value is the same as the first metric value.

[0105] Step S305: If the third metric value is the same as the first metric value, the first metric value is correct.

[0106] After obtaining the third measurement value, the third measurement value obtained by measurement based on the measurement tool is compared with the first measurement value provided by the service provider. If the two are the same, it means that the target file system has not changed and the first measurement value is correct.

[0107] Step S203: If the first metric value is correct, the kernel performs measurement.

[0108] In this embodiment, if the target file system has not changed, the first metric is correct, and the kernel and virtual machine can be started. The kernel can then be measured to obtain the second metric. If the target file system has changed, the third metric differs from the first metric, indicating that the first metric is incorrect. The first trusted execution environment will deny access, preventing the virtual machine from starting and, consequently, preventing the first application from being deployed within the first trusted execution environment.

[0109] In some embodiments, measuring the kernel and other components to obtain a second metric value in step S107 includes:

[0110] Step S401 : Measuring the kernel image, command line, and other components of the kernel to generate the second metric value, where the second metric value includes one metric value or a combination of multiple metric values.

[0111] Step S403: Store the second metric value in a register that matches the first trusted execution environment.

[0112] In this embodiment, the kernel and other components after the startup is completed are measured, including the kernel image of the kernel itself, the kernel command line, and components such as OVMF firmware and Grub. The second measurement value obtained after the measurement will be written into the register. Since different CPUs have different register types and different storage requirements for registers of different types, the method of writing the second measurement value into the register is not the same for different types of trusted execution environments provided by different CPU devices. In this embodiment, it is necessary to determine the register type corresponding to the first trusted execution environment, and write the second measurement value into the register in a manner that matches the register type corresponding to the first trusted execution environment. When remote attestation is required, the second measurement value is taken out of the register and written into the remote attestation report to implement remote attestation of the first application based on the remote attestation report.

[0113] Because different trusted execution environments correspond to different register types and can provide multiple registers, the methods for generating and storing the second metric value vary. In this embodiment, the second metric value is calculated and stored based on the storage requirements of each register type, thereby meeting the requirements for remote attestation in different trusted execution environments.

[0114] In some embodiments, the remote attestation of the first application based on the second metric value in step S107 includes:

[0115] Step S601: receiving a remote attestation request sent by a second application, where the second application runs in a second trusted execution environment.

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

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

[0118] Step S603: Generate remote attestation evidence including the second metric value based on the remote attestation request.

[0119] After receiving the request value sent by the second application, the first application obtains the second measurement value from the register based on the remote attestation request initiated by the second application, and generates remote attestation evidence including the second measurement value. The remote attestation evidence may include a remote attestation report, and the second measurement value is stored in the remote attestation report.

[0120] The second application can then obtain the remote attestation evidence returned by the first application. The remote attestation evidence is used to implement remote attestation of the first application. The remote attestation may include proof of the first application's operating environment and / or proof of the integrity of the application's code and operating logic.

[0121] Step S605: Send the remote attestation evidence to the second application, so that the second application obtains the second measurement value from the remote attestation evidence and verifies the first application based on the second measurement value.

[0122] In this embodiment, when the second application does not trust the third party, the first application can directly send the remote attestation evidence to the second application after obtaining the remote attestation evidence. The second application can obtain the second metric value from the remote attestation evidence and use the second metric value to verify the first application.

[0123] The verification process includes: the second application obtaining code information and related information of the first file disclosed by the service provider for the first application when running in the first trusted execution environment, and obtaining a fourth metric value based on the information, wherein the fourth metric value is measured using the same method as the second metric value. The related information of the first file is information related to the virtual machine image file.

[0124] The verification of the first application based on the second measurement value in step S605 includes: verifying the second measurement value and the fourth measurement value based on a preset verification strategy to obtain a remote certification result for the first application.

[0125] In this embodiment, the service provider may disclose in advance to the second application the code information and related information of the first file for the first application when running in the first trusted execution environment. After the second application obtains this information, it may run a verification client locally on the second application, run the code information through the verification client to reproduce the fourth measurement value corresponding to the second measurement value, and then verify the second measurement value and the fourth measurement value based on a preset verification strategy, thereby obtaining a remote proof result for the first application.

[0126] In some embodiments, the remote attestation of the first application based on the second metric value in step S107 includes:

[0127] Step S701: receiving a remote attestation request sent by a second application, where the second application runs in a second trusted execution environment.

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

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

[0130] Step S703: Generate remote attestation evidence including the second metric value based on the remote attestation request.

[0131] After receiving the request value sent by the second application, the first application obtains the second measurement value from the register based on the remote attestation request initiated by the second application, and generates remote attestation evidence including the second measurement value. The remote attestation evidence may include a remote attestation report, and the second measurement value is stored in the remote attestation report.

[0132] The second application can then obtain the remote attestation evidence returned by the first application. The remote attestation evidence is used to implement remote attestation of the first application. The remote attestation may include proof of the first application's operating environment and / or proof of the integrity of the application's code and operating logic.

[0133] Step S705: Send the remote attestation evidence to a remote attestation service, so that the remote attestation service obtains the second metric value from the remote attestation evidence and verifies the first application based on the second metric value.

[0134] In this embodiment, when the second application trusts the remote attestation service, the first application can obtain remote attestation evidence and send it to the second application. The second application then sends it to the remote attestation service. The remote attestation service can obtain the second metric from the remote attestation evidence and use it to verify the first application.

[0135] The verification process includes: the remote attestation service obtaining code information and related information about the first file for the first application when running in the first trusted execution environment, and obtaining a fourth metric based on the code information and related information, wherein the fourth metric is measured using the same method as the second metric. The code information and related information about the first file for the first application when running in the first trusted execution environment may be provided and disclosed by a service provider, or may be generated by other means, which is not limited in this embodiment.

[0136] The verification of the first application based on the second measurement value in step S705 includes: verifying the second measurement value and the fourth measurement value based on a preset verification strategy to obtain a remote certification result for the first application.

[0137] In this embodiment, the service provider may disclose in advance to the remote attestation service the code information related to the virtual machine and the related information of the first file when the first application is running in the first trusted execution environment. After the remote attestation service obtains the code information and the related information, it runs the code information and the related information to reproduce the fourth measurement value corresponding to the second measurement value, and then verifies the second measurement value and the fourth measurement value based on a preset verification strategy, thereby obtaining a remote attestation result for the first application.

[0138] In some embodiments, the remote attestation report may also include a hardware signature. After obtaining the remote attestation report, the second application or remote attestation service may obtain the hardware signature in the remote attestation report and verify the hardware signature in the remote attestation report to determine whether the remote attestation report meets preset conditions, thereby determining whether the remote attestation report is a remote attestation report generated by a trusted application running in a trusted execution environment. Only when the remote attestation report is a remote attestation report generated by a trusted application running in a trusted execution environment will the second measurement value be obtained for remote attestation.

[0139] In some embodiments, the remote attestation evidence may further include additional information, which may include information such as the public key of the first application or a random number generated by the second application. This embodiment does not impose any limitation on this.

[0140] At the same time, the second application or remote attestation service can also obtain the first information such as the public key of the first application or the random number generated by the second application from the remote attestation report. The second application or remote attestation service can compare the additional information obtained from the remote attestation evidence with the first information obtained from the remote attestation report, so as to determine whether the remote attestation report comes from the first application based on the additional information and the first information obtained from the remote attestation report. When the random number in the additional information is consistent with the random number in the first information, it means that the remote attestation report comes from the first application and no replay attack occurs; when the random number in the additional information is inconsistent with the random number in the first information, it means that the remote attestation report does not come from the first application and a replay attack occurs. Therefore, anti-replay attack can be achieved by setting additional information.

[0141] In some embodiments, the remote attestation evidence includes a remote attestation report and a log file of the kernel boot phase. The method further includes:

[0142] Step S801: Obtain the second metric value based on the remote attestation report.

[0143] Step S803: Obtain an intermediate metric value of the first file startup phase based on the log file, and calculate a fifth metric value based on the intermediate metric value.

[0144] In this embodiment, the log file of the first file startup phase records the events of the first file startup phase. The first file startup phase refers to the entire phase of loading the first file to start the operating system in the virtual machine image file and deploying the first application. Since the kernel is measured during the first file startup phase, the log file of the first file startup phase records the various intermediate measurement values ​​of the first file startup phase. Therefore, after obtaining the log file of the first file startup phase, the second application or remote attestation service can calculate the various intermediate measurement values ​​of the first file startup phase, and then reproduce the fifth measurement value corresponding to the second measurement value on the second application or remote attestation service based on the various intermediate measurement values.

[0145] The verifying of the first application based on the second measurement value in step S107 includes: verifying the second measurement value and the fifth measurement value based on a preset verification strategy to obtain a remote certification result for the first application.

[0146] In this embodiment, the second application or remote attestation service may not use the code information and the related information disclosed by the service provider for the first application when running in the first trusted execution environment to reproduce the fourth measurement value, but directly use the second measurement value and the fifth measurement value for verification to obtain the remote attestation result for the first application.

[0147] In the above embodiment, the second application or remote attestation service can remotely attest to the first application based on the verification results of the second measurement value and the fifth measurement value, or can remotely attest to the first application based on the verification results of the second measurement value and the fourth measurement value, or can remotely attest to the first application based on a combination of the above two methods. The specific remote attestation method can be implemented according to a preset verification strategy, which is not limited in this embodiment.

[0148] In some embodiments, before the step S803 of obtaining the intermediate measurement value of the first file startup phase based on the log file and calculating the fifth measurement value based on the intermediate measurement value, it also includes: the second application or the remote attestation service obtains the code information and related information of the first file disclosed by the service provider for the first application when running in the first trusted execution environment, and calculates the first log information at system startup based on the code information and the related information; determines whether the first log information is consistent with the second log information in the log file; and if so, calculates the fifth measurement value based on the log file.

[0149] That is, in this embodiment, the second application or remote attestation service can also calculate the first log information at system startup based on the code information and the relevant information disclosed by the service provider for the first application when running in the first trusted execution environment, and compare the calculated first log information with the second log information in the log file. If the two are consistent, it means that the log file is credible, and the fifth measurement value can be calculated based on the log file. The second measurement value and the fifth measurement value are then verified based on the preset verification strategy to obtain the remote attestation result for the first application.

[0150] In some embodiments, the firmware (OVMF), boot loader (Shim), multi-boot manager (Grub), kernel (including the kernel image itself and the kernel command line), and initial root file system (initrd) are all measured and written into registers. In other words, the second measurement value is not only the measurement value generated by measuring the kernel, but also includes the measurement value obtained by measuring the firmware (OVMF), boot loader (Shim), multi-boot manager (Grub), kernel (including the kernel image itself and the kernel command line), initial root file system (initrd), etc.

[0151] The second measurement value can be just one measurement value. For example, the firmware (OVMF), boot loader (Shim), multi-boot manager (Grub), kernel (Kernel, including the kernel image itself and the kernel command line), and initial root file system (initrd) are measured separately to obtain their respective measurement values, and then the respective measurement values ​​are further processed to obtain the second measurement value.

[0152] The second measurement value may be a combination of multiple measurement values, each of which may be a measurement value obtained by measuring only one of the firmware (OVMF), boot loader (Shim), multi-boot manager (Grub), kernel (Kernel, including the kernel image itself and the kernel command line), and initial root file system (initrd), or a measurement value obtained by further processing each measurement value obtained after multiple measurements. This embodiment does not limit this.

[0153] When the second metric value includes a combination of multiple metric values, each metric value may be stored in the same register or in different registers, which is not limited in this embodiment.

[0154] In this embodiment, when the second measurement value is used to remotely prove the first application, the second measurement value obtained is not only the measurement value generated by measuring the kernel, but also includes the measurement values ​​obtained by measuring the firmware (OVMF), boot loader (Shim), multi-boot manager (Grub), kernel (Kernel, including the kernel image itself and the kernel command line), initial root file system (initrd), etc.

[0155] Accordingly, when the service provider discloses code information for the first application running in the first trusted execution environment, the code information includes firmware (OVMF), boot loader (Shim), multi-boot manager (Grub), kernel (Kernel, including the kernel image itself and the kernel command line), initial root file system (initrd) and other information.

[0156] At the same time, when the second application or remote attestation service calculates the fourth measurement value based on the code information, it is also obtained by measuring information such as the firmware (OVMF), boot loader (Shim), multi-boot manager (Grub), kernel (Kernel, including the kernel image itself and the kernel command line), and initial root file system (initrd).

[0157] In some embodiments, the method further comprises:

[0158] Step S901: Obtain an encrypted block file.

[0159] Step S903: Utilize the encryption storage service in the target file system to interact with the provider of the encrypted block file to obtain a decryption key for the encrypted block file.

[0160] The encrypted block file may be provided by a service provider, and the provider of the encrypted block file may be the service provider.

[0161] Step S905: decrypt the encrypted block file based on the decryption key to obtain a decrypted block file.

[0162] Step S907: Mount the decrypted block file to the system of the first trusted execution environment, and respond to a write request for the first application based on the decrypted block file.

[0163] In this embodiment, since the target file system is read-only, the first application deployed in the first trusted execution environment can only respond to read requests but cannot respond to write requests.

[0164] Therefore, in this embodiment, after the virtual machine is booted, the service provider also sends an encrypted block file to the cloud service provider. The service provider interacts with the cloud service provider based on the first storage service in the target file system and verifies the first trusted execution environment. Once verification is successful, a secure communication channel is established between the service provider and the first trusted execution environment. The decryption key for the encrypted block file is sent to the virtual machine via this secure communication channel. The virtual machine decrypts the encrypted block file based on the decryption key to obtain a decrypted block file. The decrypted block file is then mounted to the system of the first trusted execution environment and used to respond to write requests from the first application. This allows the first application running in the virtual machine to have a partition that can be securely read and written, enabling secure read and write operations.

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

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

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

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

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

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

[0171] Based on the same inventive concept, corresponding to any of the above-mentioned embodiment methods, the present disclosure also provides a remote certification device.

[0172] Referring to FIG4 , the apparatus includes:

[0173] A first acquisition module 11 is configured to: acquire a first file for a first application, where the first file is used to deploy the first application in the first trusted execution environment, and the first file includes a read-only target file system;

[0174] The second acquisition module 13 is configured to: acquire a first metric value for the target file system;

[0175] A startup module 15 is configured to: load the first file, write the first metric value into a command line for starting a kernel, and start the kernel in the first file based on the command line to deploy the first application in the first trusted execution environment;

[0176] The measurement module 17 is configured to measure the kernel and other components to obtain a second measurement value, so as to remotely certify the first application based on the second measurement value.

[0177] In some embodiments, the first file includes a virtual machine image file, and the virtual machine image file includes service information, component information, and environment information for running the first application.

[0178] In some embodiments, the target file system is a root file system.

[0179] In some embodiments, the startup module 15 is further configured to:

[0180] verifying the first metric value through the kernel;

[0181] If the first measurement value is correct, the kernel is measured.

[0182] In some embodiments, verifying the first metric value by the kernel includes:

[0183] In the process of starting the kernel to execute the first file, measuring the target file system in the first file to obtain a third measurement value;

[0184] Determining whether the third metric value is the same as the first metric value;

[0185] If the third metric value is the same as the first metric value, the first metric value is correct.

[0186] In some embodiments, the measurement module 17 is further configured to:

[0187] Measuring the kernel image and command line of the kernel to generate the second measurement value;

[0188] The second metric value is stored in a register matching the first trusted execution environment.

[0189] In some embodiments, the measurement module 17 is further configured to:

[0190] receiving a remote attestation request sent by a second application, the second application running in a second trusted execution environment;

[0191] generating, based on the remote attestation request, remote attestation evidence including the second metric value;

[0192] The remote attestation evidence is sent to the second application or remote attestation service, so that the second application or the remote attestation service obtains the second metric value from the remote attestation evidence and verifies the first application based on the second metric value.

[0193] In some embodiments, the remote attestation evidence includes a remote attestation report, and the second metric value is stored in the remote attestation report; the apparatus is further configured to:

[0194] The second application or the remote attestation service obtains code information and related information of the first file when the first application is running in the first trusted execution environment, and obtains a fourth metric value based on the code information and the related information, wherein a measurement method of the fourth metric value is the same as a measurement method of the second metric value;

[0195] The verifying the first application based on the second metric value includes:

[0196] The second metric value and the fourth metric value are verified based on a preset verification strategy to obtain a remote attestation result for the first application.

[0197] In some embodiments, the remote attestation evidence includes a remote attestation report and a log file of the first file startup phase, and the second metric value is stored in the remote attestation report; the apparatus is further configured to:

[0198] obtaining the second metric value based on the remote attestation report;

[0199] Obtaining an intermediate metric value of the first file startup phase based on the log file, and calculating a fifth metric value based on the intermediate metric value;

[0200] The verifying the first application based on the second metric value includes:

[0201] The second metric value and the fifth metric value are verified based on a preset verification strategy to obtain a remote attestation result for the first application.

[0202] In some embodiments, before obtaining the intermediate metric value of the first file startup phase based on the log file and calculating the fifth metric value based on the intermediate metric value, the apparatus is further configured to:

[0203] The second application or the remote attestation service obtains code information and related information of the first file when the first application is running in the first trusted execution environment, and calculates first log information when the system is started based on the code information and the related information;

[0204] Determining whether the first log information is consistent with the second log information in the log file;

[0205] If so, the fifth metric value is calculated based on the log file.

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

[0207] Get the encrypted block file;

[0208] Utilizing the encryption storage service in the target file system to interact with the provider of the encrypted block file to obtain a decryption key for the encrypted block file;

[0209] Decrypting the encrypted block file based on the decryption key to obtain a decrypted block file;

[0210] The decrypted block file is mounted to the system of the first trusted execution environment, and a write request for the first application is responded to based on the decrypted block file.

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

[0212] The apparatus 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 described in detail here.

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

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

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

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

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

[0218] 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.).

[0219] 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 ).

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

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

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

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

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

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

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

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

[0228] 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 trusted execution environment; the method includes: Obtain a first file for a first application, where the first file is used to deploy the first application in the first trusted execution environment, and the first file includes a read-only target file system; Obtain a first measurement value for the target file system; Load the first file, write the first measurement value into the command line for starting the kernel, and start the kernel in the first file based on the command line to deploy the first application in the first trusted execution environment; Measure the kernel and other components to obtain a second measurement value, so as to perform remote attestation on the first application based on the second measurement value.

2. The method according to claim 1, wherein The first file includes a virtual machine image file, and the virtual machine image file includes service information, component information for the first application, and environment information for running the first application.

3. The method according to claim 1, wherein, The target file system is a root file system.

4. The method according to claim 1, wherein The starting the kernel in the first file based on the command line includes: Verify the first measurement value through the kernel; If the first measurement value is correct, measure the kernel.

5. The method according to claim 4, wherein, The verifying the first measurement value through the kernel includes: During the process of starting the kernel in the first file, measure the target file system in the first file to obtain a third measurement value; Determine whether the third measurement value is the same as the first measurement value; If the third measurement value is the same as the first measurement value, the first measurement value is correct.

6. The method according to claim 1, wherein, The measuring the kernel and other components to obtain a second measurement value includes: Measure the kernel image, command line, and other components of the kernel to generate the second measurement value, and the second measurement value includes a combination of one measurement value or multiple measurement values; Store the second measurement value in a register matching the first trusted execution environment.

7. The method according to claim 1, wherein The performing remote attestation on the first application based on the second measurement value includes: Receive a remote attestation request sent by a second application, where the second application runs in a second trusted execution environment; Generate remote attestation evidence including the second measurement value based on the remote attestation request; Send the remote attestation evidence to the second application or a remote attestation service, so that the second application or the remote attestation service obtains the second measurement value from the remote attestation evidence, and verifies the first application based on the second measurement value.

8. The method according to claim 7, wherein The remote attestation evidence includes a remote attestation report, and the second measurement value is stored in the remote attestation report; The method further includes: The second application or the remote attestation service obtains code information for the first application when running in the first trusted execution environment and relevant information of the first file, and obtains a fourth measurement value based on the code information and the relevant information, where the measurement method of the fourth measurement value is the same as the measurement method of the second measurement value; The verifying the first application based on the second measurement value includes: Verify the second measurement value and the fourth measurement value based on a preset verification policy to obtain a remote attestation result for the first application.

9. The method according to claim 7, wherein, The remote attestation evidence includes a remote attestation report and a log file of the first file startup phase, and the second measurement value is stored in the remote attestation report; The method further includes: Obtain the second measurement value from the remote attestation report; Obtain an intermediate measurement value of the first file startup phase based on the log file, and calculate a fifth measurement value based on the intermediate measurement value; The verifying the first application based on the second measurement value includes: Verify the second measurement value and the fifth measurement value based on a preset verification policy to obtain a remote attestation result for the first application.

10. The method according to claim 9, wherein, Before obtaining the intermediate measurement value of the first file startup phase based on the log file and calculating the fifth measurement value based on the intermediate measurement value, it further includes: The second application or the remote attestation service obtains code information of the first application when running in the first trusted execution environment and related information of the first file, and calculates first log information at system startup based on the code information and the related information; Determine whether the first log information is consistent with the second log information in the log file; If so, calculate the fifth measurement value based on the log file.

11. The method according to claim 1, further includes: Obtain an encrypted block file; Interact with the provider of the encrypted block file by using the encrypted storage service in the target file system to obtain a decryption key for the encrypted block file; Decrypt the encrypted block file based on the decryption key to obtain a decrypted block file; Mount the decrypted block file to the system of the first trusted execution environment, and respond to a write request for the first application based on the decrypted block file.

12. A remote attestation device, including: A first acquisition module, configured to: acquire a first file for the first application, where the first file is used to deploy the first application in the first trusted execution environment, and the first file includes a read-only target file system; A second acquisition module, configured to: acquire a first measurement value for the target file system; A startup module, configured to: load the first file, write the first measurement value into the command line of the startup kernel, and start the kernel in the first file based on the command line to deploy the first application in the first trusted execution environment; A measurement module, configured to: measure the kernel and other components to obtain a second measurement value, so as to perform remote attestation on the first application based on the second measurement value.

13. An electronic device, including a memory, a processor, and a computer program stored on the memory and executable on the processor, where when the processor executes the program, it implements the remote attestation method according to any one of claims 1 to 11.

14. A non-transitory computer-readable storage medium storing computer instructions for causing a computer to execute the remote attestation method according to any one of claims 1 to 11.

Images