Remote certification method, device, electronic device and storage medium

Abstract

The present disclosure provides a remote attestation method, device, electronic device and storage medium. The method is applied to a first trusted execution environment, and includes: obtaining a first file for a first application, 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; obtaining a first measurement value for the target file system; loading the first file, writing the first measurement value into a command line for starting a kernel, starting the kernel in the first file based on the command line, so as to deploy the first application in the first trusted execution environment; measuring the kernel and other components to obtain a second measurement value, so as to remotely attest the first application based on the second measurement value.

Description

Technical Field

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

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

[0003] In order to achieve communication between trusted applications running in multiple TEEs, it is necessary to verify through remote attestation that the application is running on a secure trusted execution environment platform and that the logic of the application has not been tampered with. When performing remote attestation, it is necessary to compare the measurement value returned by the attestation process with the benchmark value determined based on the source code / image provided by the service provider to determine the remote attestation result.

[0004] However, in the related art, 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

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

[0006] Based on the above purpose, the first aspect of the present disclosure provides a remote attestation method, which is applied to a first trusted execution environment; the method comprises:

[0007] 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;

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

[0009] 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;

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

[0011] 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 the first application.

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

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

[0014] Verifying the first metric value by the kernel;

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

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

[0017] In 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;

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

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

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

[0021] 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;

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

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

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

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

[0026] The remote attestation evidence is sent to the second application or the 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.

[0027] 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:

[0028] 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;

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

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

[0031] 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:

[0032] Acquire the second metric value based on the remote attestation report;

[0033] Acquire 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;

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

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

[0036] 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:

[0037] The second application or the remote attestation service obtains code information and related information of the first file for the first application when it 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;

[0038] Determine whether the first log information is consistent with the second log information in the log file;

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

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

[0041] Get the encrypted block file;

[0042] Using 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;

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

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

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

[0046] 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;

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

[0048] 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;

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

[0050] 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 when the processor executes the program, the remote attestation method as described in the first aspect is implemented.

[0051] 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, wherein the computer instructions are used to enable the computer to execute the remote attestation method described in the first aspect.

[0052] From the above, it can be seen that the remote attestation method, device, electronic device and storage medium provided by the present disclosure use the second measurement value to remotely attest the first application, and the second measurement value based on it is generated based on the measurement result of the kernel, that is, the second measurement value in the present application is an overall measurement of the operating system running the first application. When performing 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 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, and the target file system is a file system mounted on the initial root file system (initrd), and the target file system manages the operating system and the data, metadata, files, etc. of the first application running in the operating system, so that the second measurement value generated based on the first measurement value of the target file system can realize the measurement of the application layer code of the confidential virtual machine, and complete the trust transfer from the initial root file system (initrd) -> operating system (OS) during measurement, so that when used for remote attestation through remote attestation, the security of the first trusted execution environment and the integrity of the running code and data can be verified. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] In order to more clearly illustrate the technical solutions in the present disclosure or related technologies, the drawings required for use in the embodiments or related technical descriptions are briefly introduced below. 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 creative work.

[0054] Figure 1 A hardware trust diagram of an exemplary remote attestation method provided by an embodiment of the present disclosure is shown.

[0055] Figure 2 A hardware trust diagram of an exemplary remote attestation method provided by an embodiment of the present disclosure is shown.

[0056] Figure 3 A flowchart of an exemplary method provided by an embodiment of the present disclosure is shown.

[0057] Figure 4 A schematic diagram of an exemplary device provided by an embodiment of the present disclosure is shown.

[0058] Figure 5 A schematic diagram of the hardware structure of an exemplary computer device provided in an embodiment of the present disclosure is shown. 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 combination 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 be 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. "Including" or "comprising" and similar words mean that the elements or objects appearing before the word cover 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 can include electrical connections, whether direct or indirect. "Up", "down", "left", "right" and the like are only used to indicate relative positional relationships. When the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0061] In the field of distributed computing environments, cloud computing has become increasingly important as a way to achieve more flexible, scalable, and efficient systems. However, as users of cloud computing services lose direct control over 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, ARM TrustZone, etc. The trusted execution environment is a hardware-based security technology that builds a secure computing environment isolated from the outside by dividing a secure area in the CPU as a trusted execution environment. This secure computing environment can ensure the confidentiality and integrity of the data and code loaded inside it. Trusted applications running in the trusted execution environment can access the full functionality of the device's main processor and memory, and hardware isolation protects these components from being affected by 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 that aims to isolate virtual machines from other untrusted virtual machines and hypervisors. SEV includes two derivative technologies, SEV-ES (Encrypted State) and SEV-SNP (Secure Nested Paging). SEV-ES adds secure encryption of virtual machine register states on the basis of SEV, and SEV-SNP adds stronger memory integrity protection for virtual machines to prevent active attacks from hypervisors.

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

[0067] When the trusted execution environment technology is implemented, a remote attestation mechanism will be provided. The requester initiates a remote attestation request to the trusted application, and the application can obtain the remote attestation report and provide 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 modified, thereby ensuring data security.

[0068] The remote attestation report usually includes application metrics, which are hash values ​​calculated based on the application code and data, and can be used to verify the identity and integrity of the application. When performing remote attestation, the requester receives the remote attestation report sent by the application and obtains the application metrics from the remote attestation report, and then compares the application metrics with the pre-acquired benchmark metrics, where the benchmark metrics can be reproduced based on the source code and image disclosed by the service provider. If the application metrics are consistent with the benchmark metrics, it means that the integrity of the application 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 service provided by the current application is consistent with the service provided by the service provider.

[0070] like Figure 1As shown in the figure, for the remote attestation-based measurement in the TDX environment, the trust chain is: firmware (OVMF) -> boot loader (Shim) -> multi-boot manager (Grub) -> kernel (Kernel) -> initial root file system (initrd) -> operating system (OS). That is, if the operating system (OS) needs to be trusted, the initial root file system (initrd) needs to be trusted; if the initial root file system (initrd) needs to be trusted, the kernel (Kernel) needs to be trusted; if the kernel (Kernel) needs to be trusted, the multi-boot manager (Grub) needs to be guaranteed; if the multi-boot manager (Grub) needs to be trusted, the boot loader (Shim) needs to be trusted; if the boot loader (Shim) needs to be trusted, the firmware (OVMF) needs to be trusted.

[0071] For the measurement in the TDX environment, the prior art 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) -> operating system (OS) is missing, which makes it impossible for the service user (Service User) to verify that the current service (service) is consistent with what the service provider (Service Provide) claims.

[0072] like Figure 2 As shown in the figure, for the remote attestation-based measurement in the SEV environment, the trust chain is: firmware (OVMF) -> multi-boot manager (Grub) -> kernel (Kernel) -> initial root file system (initrd) -> operating system (OS). That is, if the operating system (OS) needs to be trusted, the initial root file system (initrd) needs to be trusted; if the initial root file system (initrd) needs to be trusted, the kernel (Kernel) needs to be trusted; if the kernel (Kernel) needs to be trusted, the multi-boot manager (Grub) needs to be guaranteed; if the multi-boot manager (Grub) needs to be trusted, the firmware (OVMF) needs to be trusted.

[0073] For the measurement 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) -> operating system (OS) is missing, which makes it impossible for the service user (Service User) to verify that the current service (service) is consistent with what the service provider (Service Provide) claims.

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

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

[0076] like Figure 3 As shown, the remote attestation method comprises:

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

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

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

[0080] In this embodiment, the service provider needs to create a first file for deploying the first application, and provide the first file to a 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.

[0081] At the same time, the service provider also measures the target file system in the first file, thereby obtaining 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 may be a hash value.

[0082] In this embodiment, the target file system of the first file is set to read-only, which can ensure 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 attestation will not be adversely affected by the normal operation of the operating system.

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

[0084] In this embodiment, the kernel is a part of the first file. When the service provider deploys the first application on a cloud server including the first trusted execution environment, the first file needs to be loaded, and the kernel in the first file is started during the loading of the first file, thereby implementing the deployment of the first application in the first trusted execution environment.

[0085] The kernel is the core of an operating system. It is the first layer of software expansion based on hardware. It provides the most basic functions of the operating system and 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.

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

[0087] 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 behavior of the kernel is configured and controlled based on the command line including the first metric value of the target file system to start the kernel.

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

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

[0090] In this embodiment, since the command line for starting the kernel includes the first metric value, that is, the process of kernel startup is affected by the first metric value, and the kernel image obtained after the kernel startup is also affected by the first metric value. Therefore, when measuring the kernel and components such as OVMF firmware and Grub, it is actually a measurement of the kernel and components such as OVMF firmware and Grub affected by the first metric value. Therefore, the second metric value obtained by measuring the kernel and components such as OVMF firmware and Grub is generated based on the first metric value, that is, based on the measurement result of the target file system.

[0091] In this case, when the first application is remotely certified using the second measurement value, the second measurement value based on it 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. When performing remote certification, if the remote certification 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, and 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, so 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, and the trust transfer from the initial root file system (initrd) -> operating system (OS) during measurement is completed, so that when it is used for remote certification through remote certification, the security of the first trusted execution environment and the integrity of the running code and data can be verified.

[0092] 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 the first application. The environment information for the first application can be an operating system for the first application. The first application can be deployed in the firmware through the virtual machine image file.

[0093] In some embodiments, the target file system is the root file system (rootfs) of the first file. The root file system not only has the function of storing data files of a common file system, but is also the first file system mounted when the kernel is started. The image file of the kernel code is stored in the root file system. After the root file system is mounted, the system boot program will load some initialization scripts (such as rcS, inittab) and services from the root file system into the memory to run. At the same time, the root file system contains the files necessary for system booting and for other file systems to be mounted, such as directories and key files necessary for the operating system to start.

[0094] Therefore, in the embodiment of the present disclosure, according to 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 then the kernel including the first measurement value and components such as OVMF firmware and Grub are measured to obtain a second measurement value, and then the second measurement value is used for remote attestation, thereby realizing the 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.

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

[0096] Step S201: verifying the first metric value through the kernel.

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

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

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

[0100] 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) under the target file system in the first file, thereby obtaining a third measurement value. Wherein, when the first measurement value is a hash value, the measurement tool is a tool that includes the hash value verification capability of the target file system.

[0101] In some embodiments, the third metric value may be obtained using the same metric tool as that 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, thereby making the values ​​of the first metric value and the third metric value the same when the target file system is the same.

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

[0103] Step S303: determine whether the third metric value is the same as the first metric value.

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

[0105] After obtaining the third measurement value, the third measurement value obtained by measuring 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.

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

[0107] In this embodiment, if the target file system has not changed, the first measurement value is correct, the kernel and the virtual machine can be started, and the kernel can be measured to obtain the second measurement value. If the target file system has changed, the third measurement value is different from the first measurement value, that is, the first measurement value is incorrect, the first trusted execution environment will deny access, the virtual machine cannot be started, and the first application cannot be deployed in the first trusted execution environment.

[0108] In some embodiments, the step S107 of measuring the kernel and other components to obtain a second measurement value includes:

[0109] Step S401, measuring the kernel image, command line and other components of the kernel to generate the second measurement value, where the second measurement value includes one measurement value or a combination of multiple measurement values.

[0110] Step S403: Store the second metric value in a register matching the first trusted execution environment.

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

[0112] Since different trusted execution environments correspond to different register types, and different trusted execution environments may provide multiple registers, the methods for generating and storing the second metric value are different. In this embodiment, the second metric value is calculated and stored according to the storage requirements required by the types of each register, thereby satisfying remote attestation in different types of trusted execution environments.

[0113] In some embodiments, the remotely attesting the first application based on the second metric value in step S107 includes:

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

[0115] In this embodiment, the first application runs in the first trusted execution environment, and the second application runs in the 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 the first trusted execution environment and the second trusted execution environment 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 is different from the second trusted execution environment, and this embodiment does not impose any restrictions on this.

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

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

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

[0119] The second application can obtain the remote attestation evidence returned by the first application. The remote attestation evidence is used to implement remote attestation of the first application, and the remote attestation may include the proof of the running environment of the first application and / or the proof of the integrity of the application code and running logic.

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

[0121] In this embodiment, when the second application does not trust the third party, after the first application obtains the remote attestation evidence, it can directly send the remote attestation evidence to the second application. The second application can obtain the second metric value from the remote attestation evidence to verify the first application using the second metric value.

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

[0123] Then 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.

[0124] 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 it is 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 a 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.

[0125] In some embodiments, the remotely attesting the first application based on the second metric value in step S107 includes:

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

[0127] In this embodiment, the first application runs in the first trusted execution environment, and the second application runs in the 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 the first trusted execution environment and the second trusted execution environment 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 is different from the second trusted execution environment, and this embodiment does not impose any restrictions on this.

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

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

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

[0131] The second application can obtain the remote attestation evidence returned by the first application. The remote attestation evidence is used to implement remote attestation of the first application, and the remote attestation may include the proof of the running environment of the first application and / or the proof of the integrity of the application code and running logic.

[0132] Step S705: Send the remote attestation evidence to a remote attestation service, so that 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.

[0133] In this embodiment, when the second application trusts the remote attestation service, after the first application obtains the remote attestation evidence, the remote attestation evidence may be sent to the second application, and the second application then sends the remote attestation evidence to the remote attestation service. The remote attestation service may obtain the second metric value from the remote attestation evidence to verify the first application using the second metric value.

[0134] The verification process includes: the remote attestation service obtains the 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 the measurement method of the fourth metric value is the same as the measurement method of the second metric value. The code information and related information of the first file when the first application is running in the first trusted execution environment may be provided and disclosed by the service provider, or may be generated by other methods, which is not limited in this embodiment.

[0135] Then 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.

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

[0137] 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 is a remote attestation report that 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, the second measurement value will be obtained for remote attestation.

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

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

[0140] 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:

[0141] Step S801: Obtain the second measurement value based on the remote attestation report.

[0142] Step S803: 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.

[0143] In this embodiment, the log file of the first file startup phase records the events of the first file startup phase. Among them, 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 in 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.

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

[0145] In this embodiment, the second application or remote attestation service may not use the code information and related information disclosed by the service provider when the first application is 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, thereby obtaining a remote attestation result for the first application.

[0146] In the above embodiment, the second application or remote attestation service can remotely attest the first application based on the verification results of the second measurement value and the fifth measurement value, or can remotely attest the first application based on the verification results of the second measurement value and the fourth measurement value, or can remotely attest 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.

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

[0148] 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 related 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 metric value can be calculated based on the log file, and then the second metric value and the fifth metric value can be verified based on a preset verification strategy to obtain a remote attestation result for the first application.

[0149] In some embodiments, the firmware (OVMF), the boot loader (Shim), the multi-boot manager (Grub), the kernel (Kernel, including the kernel image itself and the kernel command line), and the initial root file system (initrd) are all measured and written into the register. That is to say, 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), the boot loader (Shim), the multi-boot manager (Grub), the kernel (Kernel, including the kernel image itself and the kernel command line), the initial root file system (initrd), etc.

[0150] The second measurement value may 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 respectively to obtain their respective measurement values, and then the respective measurement values ​​are further processed to obtain the second measurement value.

[0151] 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 may be a measurement value obtained by further processing respective measurement values ​​obtained after multiple measurements, which is not limited in this embodiment.

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

[0153] In this embodiment, when the second measurement value is used to remotely attest to 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.

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

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

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

[0157] Step S901, obtaining an encrypted block file.

[0158] Step S903: using 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.

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

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

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

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

[0163] Therefore, in this embodiment, after the virtual machine is started, the service provider will also send an encrypted block file to the cloud service provider, and interact with the cloud service provider based on the first storage service in the target file system, and verify the first trusted execution environment. After the verification, a secure communication channel can be established between the service provider and the first trusted execution environment, and the decryption key for the encrypted block file can be sent to the virtual machine through the secure communication channel. The virtual machine decrypts the encrypted block file based on the decryption key to obtain a decrypted block file, and then mounts the decrypted block file to the system of the first trusted execution environment, and uses the decrypted block file to respond to the write request for the first application, so that the first application running in the virtual machine can have a partition that can be securely read and written, and can achieve secure read and write operations.

[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 receiving an active request from a user, a prompt message is sent to the user to clearly remind the user that the operation requested to be performed will require obtaining and using the user's personal information. Thus, the user can independently choose whether to provide personal information to software or hardware such as an electronic device, application, server, or storage medium that performs the operation of the technical solution of the present disclosure according to the prompt message.

[0166] As an optional but non-limiting implementation, in response to receiving the 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. In addition, the pop-up window may also carry a selection control for the user to choose "agree" or "disagree" to provide personal information to the electronic device.

[0167] It is understandable that the above notification and the process of obtaining user authorization are merely illustrative and do not constitute a limitation on the implementation of the present disclosure. Other methods that meet 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 embodiment of the present disclosure can be performed by a single device, such as a computer or a server. The method of the present embodiment can also be applied in a distributed scenario and completed by multiple devices cooperating with each other. In the case of such a distributed scenario, one of the multiple devices can only perform one or more steps in the method of the embodiment of the present disclosure, and the multiple devices will interact with each other to complete the described method.

[0169] It should be noted that the above describes some embodiments of the present disclosure. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the above embodiments and still achieve the desired results. In addition, the processes depicted in the accompanying drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some 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 embodiment methods, the present disclosure also provides a remote certification device.

[0171] refer to Figure 4 , the device comprises:

[0172] 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;

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

[0174] 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;

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

[0176] 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 the first application.

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

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

[0179] verifying the first metric value by the kernel;

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

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

[0182] 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;

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

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

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

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

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

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

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

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

[0191] The remote attestation evidence is sent to the second application or the 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.

[0192] 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:

[0193] 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;

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

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

[0196] 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 device is further configured to:

[0197] Acquire the second metric value based on the remote attestation report;

[0198] Acquire 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;

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

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

[0201] 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 device is further configured to:

[0202] The second application or the remote attestation service obtains code information and related information of the first file for the first application when it 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;

[0203] Determine whether the first log information is consistent with the second log information in the log file;

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

[0205] In some embodiments, the device is further configured to:

[0206] Get the encrypted block file;

[0207] Using 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;

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

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

[0210] For the convenience of description, the above device is described by dividing it into various modules according to its functions. Of course, when implementing the present disclosure, the functions of each module can be implemented in the same or multiple software and / or hardware.

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

[0212] 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 executable on the processor, wherein when the processor executes the program, the remote attestation method described in any of the above embodiments is implemented.

[0213] Figure 5 A more specific schematic diagram of the hardware structure of an electronic device provided in this embodiment is shown, and 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 connected to each other through the bus 1050 in the device.

[0214] The processor 1010 can be implemented by 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.

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

[0216] The input / output interface 1030 is used to connect the input / output module to realize information input and output. The input / output module can be configured in the device as a component (not shown in the figure), or it can be externally connected to the device to provide corresponding functions. The input device may include a keyboard, a mouse, a touch screen, a microphone, various sensors, etc., and the output device may include a display, a speaker, a vibrator, an indicator light, etc.

[0217] The communication interface 1040 is used to connect a communication module (not shown) to realize communication interaction between the device and other devices. The communication module can realize communication through a wired mode (such as USB, network cable, etc.) or a wireless mode (such as mobile network, WIFI, Bluetooth, etc.).

[0218] The bus 1050 includes a path that transmits 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).

[0219] 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 the specific implementation process, the device may also include other components necessary for normal operation. In addition, it can be understood by those skilled in the art that the above device may also only include the components necessary for implementing the embodiments of the present specification, and does not necessarily include all the components shown in the figure.

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

[0221] 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, 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 any of the above embodiments.

[0222] The computer-readable medium of this embodiment includes permanent and non-permanent, removable and non-removable media, and information storage can be implemented by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, 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 disk read-only memory (CD-ROM), digital versatile disk (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.

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

[0224] 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. Based on the concept 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.

[0225] In addition, to simplify the description and discussion, and in order not to make the embodiments of the present disclosure difficult to understand, the known power / ground connections to the integrated circuit (IC) chips and other components may or may not be shown in the provided figures. In addition, the device can be shown in the form of a block diagram to avoid making the embodiments of the present disclosure difficult to understand, 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 will be implemented (that is, these details should be fully within the scope of understanding of those skilled in the art). Where specific details (e.g., circuits) are set forth to describe exemplary embodiments of the present disclosure, it is apparent to those skilled in the art that the embodiments of the present disclosure can be implemented without these specific details or with changes in these specific details. Therefore, these descriptions should be considered illustrative rather than restrictive.

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

[0227] 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 comprising: 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; Obtaining a first metric value for the target file system, where the target file system is a root file system of the first file; 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; The kernel image, command line and other components of the kernel are measured to obtain a second measurement value, so as to remotely prove the first application based on the second measurement value, wherein the second measurement value includes one measurement value or a combination of multiple measurement values.

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 and component information for the first application and environment information in which the first application runs.

3. The method according to claim 1, wherein: The starting the kernel in the first file based on the command line includes: verifying the first metric value by the kernel; If the first measurement value is correct, the kernel is measured.

4. The method according to claim 3, wherein: The verifying the first metric value by the kernel includes: In 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; Determining whether the third metric value is the same as the first metric value; If the third metric value is the same as the first metric value, then the first metric value is correct.

5. The method according to claim 1, wherein: The step of measuring the kernel image, command line and other components of the kernel to obtain a second measurement value includes: The second metric value is stored in a register matching the first trusted execution environment.

6. The method according to claim 1, wherein: The remotely attesting the first application based on the second metric value includes: receiving a remote attestation request sent by a second application, the second application running in a second trusted execution environment; generating, based on the remote attestation request, remote attestation evidence including the second metric value; The remote attestation evidence is sent to the second application or the 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.

7. The method according to claim 6, wherein: The remote attestation evidence includes a remote attestation report, and the second metric value is stored in the remote attestation report; The method further comprises: 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; The verifying the first application based on the second metric value includes: The second metric value and the fourth metric value are verified based on a preset verification strategy to obtain a remote certification result for the first application.

8. The method according to claim 6, wherein: 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 comprises: Acquire the second metric value based on the remote attestation report; Acquire 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; The verifying the first application based on the second metric value includes: The second metric value and the fifth metric value are verified based on a preset verification strategy to obtain a remote certification result for the first application.

9. The method according to claim 8, wherein: 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: The second application or the remote attestation service obtains code information and related information of the first file for the first application when it 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; Determine whether the first log information is consistent with the second log information in the log file; If so, the fifth metric value is calculated based on the log file.

10. The method according to claim 1, further comprising: Get the encrypted block file; Using 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; Decrypting the encrypted block file based on the decryption key to obtain a decrypted block file; 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.

11. A remote certification device, comprising: 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 a first trusted execution environment, and the first file includes a read-only target file system; A second acquisition module is configured to: acquire a first metric value for the target file system, where the target file system is a root file system of the first file; 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; The measurement module is configured to measure the kernel image, command line and other components of the kernel to obtain a second measurement value, so as to remotely certify the first application based on the second measurement value, wherein the second measurement value includes one measurement value or a combination of multiple measurement values.

12. 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 10 is implemented.

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

Images