Remote certification methods, devices, electronic devices, and storage media

Abstract

This disclosure provides a remote certification method, apparatus, 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 being used to deploy the first application to the first trusted execution environment, the first file containing a read-only target file system; obtaining a first metric value of the target file system; loading the first file; writing the first metric value to a command line for invoking a kernel; invoking the kernel in the first file based on the command line to deploy the first application to the first trusted execution environment; metricing the kernel and other components to obtain a second metric value; and performing remote certification to the first application based on the second metric value.

Description

Technical Field

[0001] This application claims the priority of a Chinese patent application filed on December 29, 2023, with the invention name "Remote Authentication Method, Apparatus, Electronic Device, and Storage Medium" and the application number 202311864003.5, the entire content of which is incorporated herein by reference.

[0002] The present disclosure relates to the field of computer technology, and particularly to remote authentication methods, apparatuses, electronic devices, and storage media.

Background Art

[0003] A computing program for realizing reliable computing requirements is executed in a TEE (Trusted Execution Environment), which is a security area of a processor and constructs an isolated execution environment. This isolated execution environment provides security features such as isolated execution, the integrity of applications executed in the TEE, and the confidentiality of its assets. To realize communication between multiple TEE-trusted applications, it is necessary for the application to execute on a secure and reliable execution environment platform and verify through remote authentication that the logic of the application has not been tampered with. When performing remote authentication, it is necessary to compare the metric value returned by the authentication process with the reference value determined based on the source / image provided by the service provider to determine the remote authentication result.

[0004] However, in related technologies, it is not possible to measure the code and data in the operating system, and the user cannot verify that what the current application and the service provider generated are consistent.

Summary of the Invention

[0005] In light of this, this disclosure aims to provide remote certification methods, apparatus, electronic devices, and storage media.

[0006] Based on the above objectives, a first aspect of this disclosure is a remote certification method applicable to a first trusted execution environment, wherein a first file for a first application is obtained, the first file is used to deploy the first application to the first trusted execution environment, and the first file includes a read-only target file system. Obtain the first metric value of the target file system mentioned above, Load the first file mentioned above, write the first metric value mentioned above to the command line for starting the kernel, start the kernel in the first file based on the command line mentioned above, and deploy the first application to the first trusted execution environment mentioned above. The present invention provides a remote certification method that includes metricing the kernel and other components to obtain a second metric value, and performing remote certification on the first application based on the second metric value.

[0007] In some embodiments, the first file includes a virtual machine image file containing service information, component information, and environment information on which the first application runs.

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

[0009] In some embodiments, starting the kernel and executing the first file based on the above command line is: The kernel described above verifies the first metric value, If the above first metric value is correct, then the above kernel is metriced, including the following.

[0010] In some embodiments, verifying the first metric value using the above-mentioned core is In the process that starts the kernel in the first file mentioned above, the target file system in the first file mentioned above is metriced, and the third metric value is obtained. To determine whether the above third metric value and the above first metric value are the same, This includes the condition that if the above third metric value is the same as the above first metric value, then the above first metric value is correct.

[0011] In some embodiments, the kernel and other components described above are used to obtain a second metric value. The kernel image, command line, and other components of the kernel described above are metriced to generate a second metric value, and this second metric value includes a combination of one or more metric values. This includes storing the above-mentioned second metric value in a register that matches the above-mentioned first reliable execution environment.

[0012] In some embodiments, performing remote certification to the first application based on the above second metric value is: The system receives a remote certification request sent from the second application, and the second application executes it in the second trusted execution environment. To generate remote proof evidence including the second metric value based on the above remote proof request, This includes sending the above remote proof to the above second application or remote certification service, thereby allowing the above second application or remote certification service to obtain the above second metric value from the above remote certification service and to verify the above first application based on the above second metric value.

[0013] In some embodiments, the remote proof includes a remote proof report, the second metric value is stored in the remote proof report, and the method is The second application or remote certification service described above further includes obtaining code information and related information for the first file when the first application is running in the first trusted execution environment, obtaining a fourth metric value based on the code information and related information, wherein the metric method for the fourth metric value is the same as the metric method for the second metric value, Verifying the first application based on the above second metric value is: This includes verifying the second metric value and the fourth metric value based on a pre-configured verification strategy, and obtaining remote certification results for the first application.

[0014] In some embodiments, the remote proof includes a remote proof report and a log file of the startup phase of the first file, the second metric value is stored in the remote proof report, and the method is Based on the above remote certification report, obtain the above second metric value, This further includes obtaining the intermediate metric value for the startup phase of the first file based on the log file mentioned above, and calculating the fifth metric value based on the intermediate metric value mentioned above. Verifying the first application based on the above second metric value is: This includes verifying the second metric value and the fifth metric value based on a pre-configured verification strategy, and obtaining remote certification results for the first application.

[0015] In some embodiments, the intermediate metric value of the startup phase of the first file is obtained based on the above log file, and before calculating the fifth metric value based on the above intermediate metric value, The second application or remote certification service described above obtains code information and related information for the first file when the first application is running in the first trusted execution environment described above, and calculates the first log information at system startup based on the code information and related information described above. To determine whether the first log information above matches the second log information in the log file above, If the first log information described above matches the second log information in the log file, the fifth metric value described above is calculated based on the log file, and this further includes the calculation of the fifth metric value described above.

[0016] In some embodiments, the above method is Obtaining the encrypted block file, Interact with the provider of the encrypted block file using the encrypted storage service in the target file system to obtain the decryption key for the encrypted block file. Based on the above decryption key, decrypt the above encrypted block file and obtain the decrypted block file. The further includes mounting the above-mentioned decrypted block file to the system of a first trusted execution environment and responding to write requests to the first application based on the above-mentioned decrypted block file.

[0017] A second aspect of this disclosure includes a first acquisition module which acquires a first file for a first application, the first file being used to deploy the first application to a first trusted execution environment, and the first file being arranged to include a read-only target file system, A second acquisition module is configured to acquire the first metric value of the target file system, Load the first file, write the first metric value to the command line for starting the kernel, start the kernel in the first file based on the command line, and deploy the first application to the first trusted execution environment. An activation module is arranged to do so. A metric module is provided which metrics the kernel and other components to obtain a second metric value, and performs remote attestation on the first application based on the second metric value. A remote attestation device comprising the metric module is provided.

[0018] The third aspect of the present disclosure includes a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the program, an electronic device is provided which realizes the remote attestation method described in the first aspect.

[0019] The fourth aspect of the present disclosure provides a non-transitory computer-readable storage medium storing computer instructions, and the computer instructions cause the computer to execute the remote attestation method described in the first aspect.

Brief Description of the Drawings

[0020] To more clearly explain the technical aspects in the present disclosure or related technologies, the drawings necessary for use in the embodiments or related technical descriptions are briefly described. Clearly, the drawings in the following description are only embodiments of the present disclosure. For those skilled in the art, other drawings can also be obtained based on these drawings without creative labor.

[0021] [Figure 1] A schematic diagram of hardware trustworthiness of an exemplary remote attestation method according to some embodiments of the present disclosure is shown.

[0022] [Figure 2] A schematic diagram of hardware trustworthiness of an exemplary remote attestation method according to some embodiments of the present disclosure is shown.

[0023] [Figure 3] A schematic flowchart of an exemplary method provided by the embodiments of this disclosure is shown.

[0024] [Figure 4] A schematic diagram of an exemplary apparatus provided by embodiments of this disclosure is shown.

[0025] [Figure 5] The following are hardware configuration diagrams of exemplary computer devices provided by some embodiments of this disclosure. [Modes for carrying out the invention]

[0026] To further clarify the purpose, technical proposal, and advantages of this disclosure, specific embodiments are described below in more detail with reference to the drawings.

[0027] Unless otherwise defined, technical or scientific terms used in the embodiments of this disclosure should have their ordinary meanings as understood by a person with general skill in the art to which this disclosure belongs. The terms “first,” “second,” and similar terms used in the embodiments of this disclosure do not indicate order, number, or importance, but are used to distinguish different components. Similar terms such as “includes” or “equip” mean that the element or object preceding the term covers the elements or objects and their equivalents listed after the term without excluding other elements or objects. Similar terms such as “connected” or “linked” are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect. Terms such as “up,” “down,” “left,” and “right” are used only to describe relative positions, and if the absolute position of the described object changes, its relative position may change accordingly.

[0028] 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 data and applications managed by the cloud provider, the reliability of cloud services has become a major obstacle to the deployment of cloud applications.

[0029] To attract users and encourage them to use cloud services, cloud service providers must offer reliable services, assure users that the data and applications provided to the service are secure and protected, and that the service will only use this data and applications as the user expects.

[0030] Trusted services can be developed using trusted execution environments (TEEs) such as Intel SGX, TDX, AMD SEV, and ARM TrustZone. Trusted execution environments are hardware-based security technologies that create a secure computing environment isolated from the outside by dividing the CPU into a secure area designated as a trusted execution environment. This secure computing environment guarantees the confidentiality and integrity of the data and code loaded within it. Trusted applications running in a trusted execution environment have access to all the functions of the device's main processor and memory, so they are not affected by applications installed by the user running on the host operating system.

[0031] Here, TDX is a confidential virtualization technology that isolates confidential virtual machines from non-confidential domain software stacks (including virtual machine monitor hypervisors, VMMs, and other untrusted domain software stacks), ensuring that data on confidential virtual machines cannot be obtained or modified by non-confidential domain software.

[0032] SEV is a virtual machine memory encryption technology for isolating a virtual machine from other untrusted virtual machines and the hypervisor. SEV includes two derivative technologies, SEV-ES (Encrypted State) and SEV-SNP (Secure Nested Paging). SEV-ES adds secure encryption of the virtual machine register state based on SEV, while SEV-SNP adds stronger memory integrity protection for the virtual machine, preventing aggressive attacks on the hypervisor.

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

[0034] When trusted execution environment technology is implemented, a requester initiates a remote certification request to a trusted application, and the application obtains and provides a remote certification report to the requester. By verifying the remote certification report, the requester can confirm that the application is running on a trusted hardware platform, that the application's execution logic has not been altered, and that data security is ensured.

[0035] Remote certification reports typically include application metric values, 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. When performing remote certification, the requester receives the remote certification report sent by the application, retrieves the application metric values ​​from the remote certification report, and then compares these application metric values ​​to a pre-obtained baseline metric value, which is reconstructed based on the source code and images published by the service provider. If the application metric value matches the baseline metric value, it indicates that the application's integrity has not been compromised.

[0036] However, with conventional technologies, it was not possible to metric code and data within the operating system when performing remote certification, and users could not verify that the services provided by the current application matched those provided by the service provider.

[0037] The remote certification method, apparatus, electronic device, and storage medium provided in this disclosure perform remote certification against a first application using a second metric value, wherein the underlying second metric value is generated based on the kernel's metric result; that is, the second metric value in this application is an overall metric applied to the operating system running the first application. When performing remote certification, if the remote certification result for the operating system containing the first application passes, it indicates that the operating system containing the first application is complete and secure, and that the first application running on the operating system is also complete and secure. Simultaneously, since the kernel starts based on a command line containing the first metric value of the target file system at boot time, the second metric value is generated based on the first metric 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 data, metadata, files, etc. of the operating system and the first application running on the operating system. Therefore, by using the second metric value generated based on the first metric value of the target file system, metrics for the application layer code of a sensitive virtual machine are realized, and by complementing the trust transfer from the initial root file system (initrd) -> operating system (OS) when metricating, it becomes possible to verify the security and executable code and data integrity of the first trusted execution environment when performing remote certification using remote certification.

[0038] As shown in Figure 1, the reliable chain of metrics based on remote certification in a TDX environment is Firmware (OVMF) -> Bootloader (Shim) -> Multistart Manager (Grub) -> Kernel -> Initial Root File System (initrd) -> Operating System (OS). In other words, if it is necessary to guarantee that the Operating System (OS) is reliable, then it is necessary to guarantee that the Initial Root File System (initrd) is reliable, then it is necessary to guarantee that the Kernel is reliable, then it is necessary to guarantee that the Multistart Manager (Grub) is reliable, then it is necessary to guarantee that the Bootloader (Shim) is reliable, and then it is necessary to guarantee that the Bootloader (Shim) is reliable, then it is necessary to guarantee that the Firmware (OVMF) is reliable.

[0039] In a TDX environment, metrics are only measured at the initial root file system (initrd) using conventional technologies, and the trust chain is also only propagated to the initial root file system (initrd). This means that the trust between the initial root file system (initrd) and the operating system (OS) is lost, making it impossible for the service user to verify that the claims of the current service and the service provider are consistent.

[0040] As shown in Figure 2, the reliable chain of metrics based on remote certification in a SEV environment is Firmware (OVMF) -> Multi-Start Manager (Grub) -> Kernel -> Initial Root File System (initrd) -> Operating System (OS). In other words, if you need to ensure that the Operating System (OS) is reliable, you need to ensure that the Initial Root File System (initrd) is reliable, you need to ensure that the Kernel is reliable, you need to ensure that the Kernel is reliable, you need to ensure that the Multiple Start Manager (Grub) is reliable, and you need to ensure that the Multi-Start Manager (Grub) is reliable, you need to ensure that the Firmware (OVMF) is reliable.

[0041] In an SEV environment, metrics are only measured at the initial root file system (initrd) using conventional technologies, and the trust chain is also only propagated to the initial root file system (initrd). This means that the trust between the initial root file system (initrd) and the operating system (OS) is lost, making it impossible for the service user to verify that the claims of the current service and the service provider are consistent.

[0042] In view of this, this disclosure provides a remote certification method for solving the above-mentioned problems.

[0043] Here, the remote proof method is applied to a first trusted execution environment, which is a trusted execution environment such as SGX, TDX, SEV, SEV-ES, SEV-SNP, or ARM TrustZone, and this embodiment is not limited to these. As shown in Figure 3, the above remote certification method is Step S101 includes obtaining a first file for a first application, which is used to deploy the first application to the first trusted execution environment, and which includes a read-only target file system.

[0044] In step S103, the first metric value of the target file system is obtained.

[0045] The first file of the first application and the first metric value of the target file system may be provided by a service provider or generated by other means, and this embodiment is not limited thereto.

[0046] In this embodiment, the service provider is required to create a first file for deploying the first application and provide this first file to a cloud service provider (CSP) that needs to deploy the first application, and the cloud service provider provides a cloud server containing a first trusted execution environment in order to deploy the first application based on the first file.

[0047] Simultaneously, the service provider obtains a first metric value for this target file system and metrics the target file system in the first file to provide to the cloud service provider. In some embodiments, the first metric value may be a hash value.

[0048] In this embodiment, the target file system of this first file is set to read-only, thereby ensuring that the first metric value obtained based on this target file system matches and does not change due to the normal operation of the operating system, and further ensuring that when remote certification is performed using the first metric value of the target file system thereafter, it is not adversely affected by the normal operation of the operating system.

[0049] In step S105, the first file is loaded, the first metric value is written to a command line to start the kernel, and the kernel in the first file is started based on the command line to deploy the first application to the first trusted execution environment.

[0050] In this embodiment, the kernel is part of the first file. When a service provider deploys the first application on a cloud server containing the first trusted execution environment, it is necessary to load the first file. The loading process of the first file starts the kernel within the first file, thereby enabling the deployment of the first application in the first trusted execution environment.

[0051] The kernel is the first layer of software extensions based on hardware in an operating system. It provides the most basic functions of the operating system, is the foundation of the operating system's work, manages the system's processes, memory, device drivers, files, and network system, and determines the system's performance and stability.

[0052] Here, this kernel may be the kernel brought by the first file, or a new kernel may be specified during the boot phase, but this embodiment is not limited to these.

[0053] Before booting the kernel, the primary metric value of this target filesystem must be written to the command line used to boot the kernel. The kernel's actions are then arranged and controlled based on the command line containing the primary metric value of the target filesystem, thereby enabling the kernel to boot.

[0054] Step S107 provides a remote certification method that includes metricing the kernel and other components to obtain a second metric value, and performing remote certification on the first application based on the second metric value.

[0055] Here, other components may include OVMF firmware, Grub, etc., and this embodiment is not limited to these.

[0056] In this embodiment, the command line for booting the kernel includes this first metric value, meaning the kernel boot process is affected by this first metric value, and the kernel image obtained after kernel booting is also affected by this first metric value. Therefore, when metricing the kernel and components such as OVMF firmware and Grub, the second metric value obtained from the kernel and component metrics such as OVMF firmware and Grub is actually affected by the first metric value, and is generated based on the first metric value, i.e., based on the metric results of the target file system.

[0057] In this case, when performing remote certification against the first application using the second metric value, the underlying second metric value is generated based on the kernel's metric results; that is, the second metric value in this application is an overall metric applied to the operating system running the first application. When performing remote certification, if the remote certification result for the operating system containing the first application passes, that is, the operating system containing the first application is complete and secure, and the first application running on the operating system is also complete and secure. At the same time, since the kernel is started based on a command line that includes the first metric value of the target file system at boot time, the second metric value is generated based on the first metric 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 data, metadata, files, etc. of the operating system and the first application running on the operating system. Therefore, by using the second metric value generated based on the first metric value of the target file system, metrics for the application layer code of a confidential virtual machine can be realized, and by complementing the trust transmission from the initial root file system (initrd) -> operating system (OS) when metricing, the security of the first trusted execution environment and the integrity of the executable code and data can be verified when performing remote certification using remote certification.

[0058] In some embodiments, the first file includes a virtual machine image file containing service information, component information, and environment information on which the first application runs. Here, the environment information on which the first application runs may be the operating system on which the first application runs. This virtual machine image file enables the deployment of the first application to the firmware.

[0059] In some embodiments, the target filesystem is the root filesystem (rootfs) of the first file. However, the root filesystem is not only responsible for storing data files of a normal filesystem, but is also the first filesystem that is mounted at kernel startup. The kernel code image file is stored in the root filesystem, and the system boot program loads and executes several initialization scripts (e.g., rcS, inittab) and services into memory after the root filesystem is mounted. The root filesystem also contains directories and important files necessary for the operating system to start, as well as files necessary for system booting and mounting other filesystems.

[0060] Accordingly, in embodiments of the present disclosure, based on a first metric value of the read-only root file system, this first metric value of the read-only root file system is written to the kernel boot command line at kernel startup, the kernel is started based on the command line containing this first metric value of the read-only root file system, a second metric value is obtained by further metricing the kernel and components such as OVMF firmware and Grub containing this first metric value, and this second metric value is reused to perform remote certification, thereby enabling metricing of the application layer code of a sensitive virtual machine based on the metric results of the read-only root file system, and complementing the trust transmission from the initial root file system (initrd) -> operating system (OS) when metricing, thereby enabling verification of the security of the first trusted execution environment and the integrity of the executable code and data when performing remote certification using remote certification.

[0061] In some embodiments, step S105 involves starting the kernel in the first file based on the above command line. Step S201 includes verifying the above-mentioned first metric value using the kernel described above.

[0062] In step S201, the above-mentioned first metric value is verified using the above-mentioned core, Step S301 includes the process of starting the kernel in the first file, metricing the target file system in the first file, and obtaining a third metric value.

[0063] In this embodiment, a virtual machine is started using a kernel with metric value verification capability, and the first metric value is verified during the virtual machine startup process.

[0064] In some embodiments, the virtual machine startup process obtains a third metric value by using a kernel-associated metric tool to metric all files under the target filesystem (including self-service code) in a first file. Here, if the first metric value is a hash value, this metric tool is a tool that includes the ability to verify against the hash value of the target filesystem.

[0065] In some embodiments, the third metric value can be obtained using the same metric tool that the service provider uses to obtain the first metric value, ensuring that the metric processes for the first and third metric values ​​are the same, and that the values ​​of the first and third metric values ​​are the same if the target file systems are the same.

[0066] In some embodiments, when a service provider obtains a first metric value using a metric tool, it can 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.

[0067] In step S303, it is determined whether the third metric value and the first metric value are the same.

[0068] In step S305, if the third metric value is the same as the first metric value, then the first metric value is correct.

[0069] After obtaining the third metric value, compare the third metric value obtained by metric tooling with the first metric value provided by the service provider. If both are the same, it indicates that the target file system has not changed and the first metric value is correct.

[0070] In step S203, if the above first metric value is correct, the above kernel is metriced.

[0071] In this embodiment, if there is no change in the target file system, the first metric value is correct, the kernel and virtual machine start up, and the second metric value can be obtained by metricing the kernel. If the target file system changes, the third metric value will differ from the first metric value; that is, the first metric value is incorrect, the first trusted execution environment will deny access, the virtual machine cannot start, and the first application cannot be deployed to the first trusted execution environment.

[0072] In some embodiments, step S107 involves metricing the kernel and other components described above to obtain a second metric value.

[0073] In step S401, the kernel image, command line, and other components of the kernel are metriced to generate a second metric value, which includes a combination of one or more metric values.

[0074] In step S403, the above second metric value is stored in a register that matches the above first reliable execution environment.

[0075] In this embodiment, the kernel and other components are metriced after startup is complete, including the kernel image itself, the kernel command line, and components such as OVMF firmware and Grub. The second metric value obtained after metricing is written to a register. Because different CPUs have different register types and different register storage requirements, the method of writing the second metric value to the register differs 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 metric value to the register so that it matches the register type corresponding to the first trusted execution environment. If remote certification is required, the second metric value is taken from the register and written to a remote certification report, and remote certification to the first application is performed based on the remote certification report.

[0076] Because different trusted execution environments have different register types, and different trusted execution environments can provide multiple registers, the methods for generating and storing the second metric value also differ. In this embodiment, to satisfy remote proof in different types of trusted execution environments, the second metric value is calculated and stored in the storage request required for each register type.

[0077] In some embodiments, step S107 involves performing remote certification to the first application based on the above second metric value. Step S601 includes receiving a remote certification request sent from a second application and having the second application run in a second trusted execution environment.

[0078] 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 and second trusted execution environments may be deployed on the same trusted computing node, or they may be deployed on different trusted computing nodes, and this specification does not limit this. The first and second trusted execution environments may be the same trusted execution environment, or the first trusted execution environment may be different from the second trusted execution environment, and this embodiment does not limit this.

[0079] In this embodiment, if the second application wants to perform remote certification on the first application, the second application can issue a remote certification request to the first application by generating a request value and sending it to the first application. Here, the request value may be a random number generated by the second application.

[0080] In step S603, remote proof is generated that includes the second metric value based on the remote proof request.

[0081] After receiving the request values ​​sent by the second application, the first application retrieves the second metric value from its registers based on the remote certification request issued by the second application, and generates remote proof containing the second metric value. This remote proof includes a remote certification report, and the second metric value is stored in this remote certification report.

[0082] The second application can obtain remote proof of proof returned by the first application. This remote proof of proof is used to provide remote proof to the first application, which may include proof of the first application's execution environment and / or proof of the integrity of the application's code and execution logic.

[0083] In step S605, the remote proof is sent to the second application, which then obtains the second metric value from the remote proof service and verifies the first application based on the second metric value.

[0084] In this embodiment, if the second application does not trust the third party, the first application can obtain remote proof and then send that remote proof directly to the second application. The second application can obtain a second metric value from this remote proof and use this second metric value to verify the first application.

[0085] The verification process involves the second application obtaining code information and related information for the first file when the first application, disclosed by the service provider, is running in the first trusted execution environment. Based on this information, a fourth metric value is obtained, the metric method for the fourth metric value being the same as the metric method for the second metric value. The information for the first file is information for the virtual machine image file.

[0086] Step S605 involves verifying the first application based on the second metric value, which includes verifying the second metric value and the fourth metric value based on a pre-configured verification strategy, and obtaining a remote certification result for the first application.

[0087] In this embodiment, the service provider can pre-disclose code information and information about the first file when the first application is running in a first trusted execution environment to the second application, and after the second application obtains this information, it can run an authentication client locally, which can execute this code information to restore the fourth metric value corresponding to the second metric value, and further obtain a remote certification result for the first application by verifying the second and fourth metric values ​​based on a pre-configured authentication strategy.

[0088] In some embodiments, step S107 involves performing remote certification to the first application based on the above second metric value. Step S701 includes receiving a remote certification request sent from a second application and having the second application run in a second trusted execution environment.

[0089] 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 and second trusted execution environments may be deployed on the same trusted computing node, or they may be deployed on different trusted computing nodes, and this specification does not limit this. The first and second trusted execution environments may be the same trusted execution environment, or the first trusted execution environment may be different from the second trusted execution environment, and this embodiment does not limit this. In this embodiment, if the second application wants to perform remote certification on the first application, the second application can issue a remote certification request to the first application by generating a request value and sending it to the first application. Here, the request value may be a random number generated by the second application.

[0090] In step S703, remote proof is generated that includes the second metric value based on the remote proof request.

[0091] After receiving the request values ​​sent by the second application, the first application retrieves the second metric value from its registers based on the remote certification request issued by the second application, and generates remote proof containing the second metric value. This remote proof includes a remote certification report, and the second metric value is stored in this remote certification report.

[0092] The second application can obtain remote proof of proof returned by the first application. This remote proof of proof is used to provide remote proof to the first application, which may include proof of the first application's execution environment and / or proof of the integrity of the application's code and execution logic.

[0093] In step S705, the remote certification evidence is sent to the remote certification service, which then obtains the second metric value from the remote certification service and verifies the first application based on the second metric value.

[0094] In this embodiment, if the second application trusts the remote certification service, the first application can obtain remote proof and then send that proof to the second application, which can then send this proof to the remote certification service. The remote certification service can obtain a second metric value from this remote proof and use this second metric value to verify the first application.

[0095] The verification process includes the remote certification service obtaining code information and related information for the first file when the first application is running in the first trusted execution environment, obtaining a fourth metric value based on the code information and related information, wherein the metric method for the fourth metric value is the same as the metric method for the second metric value. The information regarding the code information and the first file when the first application is running in the first trusted execution environment may be provided and disclosed by a service provider, or generated in other ways, and this embodiment is not limited thereto.

[0096] Step S705 involves verifying the first application based on the second metric value, which includes verifying the second metric value and the fourth metric value based on a pre-configured verification strategy, and obtaining a remote certification result for the first application.

[0097] In this embodiment, the service provider can pre-disclose code information and information about the first file regarding the virtual machine when the first application is running in the first trusted execution environment to the remote certification service, and after the remote certification service obtains this code information and the above-mentioned related information, it can use this code information and the above-mentioned related information to restore the fourth metric value corresponding to the second metric value, and further obtain a remote certification result for the first application by verifying the second metric value and the fourth metric value based on a pre-configured authentication strategy.

[0098] In some embodiments, the remote certification report may also include a hardware signature. After obtaining the remote certification report, the second application or remote certification service obtains the hardware signature in the remote certification report and verifies the hardware signature in the remote certification report to determine whether the remote certification report is a remote certification report that meets pre-configured conditions and whether the remote certification report is a remote certification report generated by a trusted application running in a trusted execution environment. If the remote certification report is a remote certification report generated by a trusted application running in a trusted execution environment, the second metric value is obtained and remote certification is performed.

[0099] In some embodiments, the remote proof may include additional information, such as the public key of the first application or a random number generated by the second application, and this embodiment is not limited thereto.

[0100] Simultaneously, a second application or remote certification service can also obtain primary information from the remote certification report, such as the public key of the first application or a random number generated by the second application. By comparing the additional information obtained from this remote proof with the primary information obtained from the remote proof, the second application or remote certification service can determine whether the remote certification report originated from the first application based on the additional information and the primary information obtained from the remote certification report. If the random number in the additional information matches the random number in the primary information, it explains that this remote proof originated from the first application and no replay attack has occurred. If the random number in the additional information does not match the random number in the primary information, it means that this remote certification report did not originate from the first application and a replay attack has occurred. Therefore, replay attacks can be prevented by setting the additional information.

[0101] In some embodiments, the remote proof includes a remote proof report and a kernel boot phase log file.

[0102] The above method, Step S801 involves obtaining the above second metric value based on the above remote certification report, Step S803 further includes obtaining the startup intermediate metric value of the first file based on the log file, and calculating the fifth metric value based on the intermediate metric value.

[0103] In this embodiment, the log file for the startup phase of the first file records the events of the startup phase of the first file. Here, the startup phase of the first file refers to the entire process of loading the first file, starting the operating system in the virtual machine image file, and deploying the first application. Because the kernel was metriced during the startup phase of the first file, the log file for the startup phase of the first file records each intermediate metric value of the startup phase of the first file. Therefore, after obtaining the log file for the startup phase of the first file, the second application or remote certification service can calculate each intermediate metric value of the startup phase of the first file obtained, and then restore the fifth metric value corresponding to the second metric value based on each intermediate metric value on the second application or remote certification service.

[0104] Step S107 involves verifying the first application based on the second metric value, which includes verifying the second metric value and the fifth metric value based on a pre-configured verification strategy, and obtaining a remote certification result for the first application.

[0105] In this embodiment, the second application or remote certification service can also obtain remote certification results for the first application by directly using and verifying the second and fifth metric values, rather than using runtime code information and related information in the first trusted execution environment of the first application disclosed by the service provider to reconstruct the fourth metric value.

[0106] In the above embodiment, the second application or remote certification service may perform remote certification to the first application based on the verification result using the second metric value and the fifth metric value, or it may perform remote certification to the first application based on the inspection result using the second metric value and the fourth metric value, or it may perform remote certification to the first application based on a combination of the above two methods, and the specific remote certification method may be implemented based on a pre-configured verification strategy, and this embodiment is not limited thereto.

[0107] In some embodiments, step S803 further includes, before obtaining an intermediate metric value for the first file startup phase based on the log file and calculating a fifth metric value based on the intermediate metric value, the second application or the remote certification service obtains runtime code information and related information for the first file of the first application under the first trusted execution environment disclosed by the service provider, calculates first log information at system startup based on the code information and related information, determines whether the first log information matches the second log information in the log file, and if so, calculates the fifth metric value based on the log file.

[0108] In other words, in this embodiment, the second application or remote certification service calculates first log information at system startup based on runtime code information and related information in the first trusted execution environment of the first application disclosed by the service provider, compares the calculated first log information with second log information in the log file, and if both match, indicates that the log file is trusted, calculates a fifth metric value based on this log file, and further verifies the second metric value and the fifth metric value based on a pre-configured verification strategy to obtain a remote certification result for the first application.

[0109] In this embodiment, the firmware (OVMF), bootloader (Shim), multi-start manager (Grub), kernel (including the kernel image itself and the kernel command line), and initial root file system (initrd) are all metriced and written to registers. In other words, the second metric value includes not only the metric value generated by metricing the kernel, but also the metric values ​​obtained by metricing the firmware (OVMF), bootloader (Shim), multi-start manager (Grub), kernel (including the kernel image itself and the kernel command line), and initial root file system (initrd).

[0110] The second metric value may consist of only one metric value. For example, the firmware (OVMF), boot loader (Shim), multi-start manager (Grub), kernel (including the kernel image itself and the kernel command line), and initial root file system (initrd) may be metriced, their respective metric values ​​obtained, and then each metric value processed further to obtain the second metric value.

[0111] The second metric value may be a combination of multiple metric values, where each metric value is obtained by metricating only one of the following: firmware (OVMF), boot loader (Shim), multi-start manager (Grub), kernel (including the kernel image itself and the kernel command line), or initial root file system (initrd). It may also be a metric value obtained by further processing each of the metric values ​​obtained by metricating multiple items, and this embodiment is not limited thereto.

[0112] If 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, but this embodiment is not limited thereto.

[0113] In this embodiment, when remote certification is performed to the first application using the second metric value, the acquired second metric value includes not only the metric value generated by metricizing the kernel, but also metric values ​​obtained by metricizing the firmware (OVMF), boot loader (Shim), multi-start manager (Grub), kernel (the kernel image itself and the kernel command line), initial root file system (initrd), etc.

[0114] Accordingly, when a service provider exposes code information to a first application while it is running in a first trusted execution environment, this code information includes information such as firmware (OVMF), bootloader (Shim), multistart manager (Grub), kernel (including the kernel image itself and the kernel command line), and initial root filesystem (initrd).

[0115] Simultaneously, when a second application or remote certification service calculates a fourth metric value based on this code information, the second metric value is obtained not only by metricing the kernel, but also by metricing information such as the firmware (OVMF), bootloader (Shim), multi-start manager (Grub), kernel (including the kernel image itself and the kernel command line), and initial root filesystem (initrd).

[0116] In some embodiments, the above method is Step S901 involves obtaining the encrypted block file, Step S903 further includes interacting with the provider of the encrypted block file using the encrypted storage service in the target file system to obtain the decryption key for the encrypted block file.

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

[0118] In step S905, the encrypted block file is decrypted based on the decryption key, and the decrypted block file is obtained.

[0119] In step S907, the decrypted block file is mounted to the system of the first trusted execution environment, and the system responds to write requests to the first application based on the decrypted block file.

[0120] 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 and cannot respond to write requests.

[0121] Therefore, in this embodiment, once the virtual machine has finished starting up, the service provider sends the encrypted block file to the cloud service provider, interacts with the first storage service in the target file system based on the cloud service provider, verifies the first trusted execution environment, and after successful verification, establishes a secure communication channel between the service provider and the first trusted execution environment, and sends the decryption key for this encrypted block file to the virtual machine via this secure communication channel. The virtual machine decrypts this encrypted block file based on this decryption key, obtains the decrypted block file, mounts the decrypted block file to the system of the first trusted execution environment, and uses this decrypted block file to respond to write requests to the first application. Thus, the first application running on the virtual machine has a secure read / write partition and can perform secure read / write operations.

[0122] It is understood that, before using any of the technical aspects of each embodiment of this disclosure, the user should be notified in an appropriate manner about the type of personal information, the scope of use, the usage scenario, etc., and the user's permission should be obtained.

[0123] For example, in response to receiving a proactive request from a user, the system sends the user information to explicitly inform the user that the action requested to be performed requires the acquisition and use of the user's personal information. This allows the user to autonomously choose, based on the information provided, whether to provide personal information to software or hardware such as electronic devices, applications, servers, or storage media that perform the actions of the technical aspects of this disclosure.

[0124] An alternative but non-restrictive embodiment is a method of sending information to a user in response to a proactive request from the user, such as a pop-up window that can display the information in text. The pop-up window may also include a selection control that allows the user to choose "agree" or "disagree" to provide personal information to the electronic device.

[0125] The process for notifying and obtaining user authentication described above is merely illustrative and does not limit the embodiments of this disclosure. It should be understood that other methods that comply with other relevant laws and regulations can also be applied to the embodiments of this disclosure.

[0126] Furthermore, the methods of the embodiments of this disclosure can be performed by a single device such as a computer or server. The methods of these embodiments can also be applied to distributed scenes, where multiple devices can cooperate to complete the process. In such distributed scenes, one of the multiple devices can perform only one or more steps of the methods of the embodiments of this disclosure, and these multiple devices can interact with each other to complete the method.

[0127] The above describes some embodiments of the present disclosure. Other embodiments are within the scope of the appended claims. In some cases, the operations or steps described in the claims can be performed in a different order than those in the embodiments described above, and the desired results can still be achieved. Also, the processes depicted in the drawings do not necessarily require the specific order or sequence shown, and the desired results can still be achieved. In some embodiments, multitasking and parallel processing are possible or advantageous.

[0128] Based on the same concept of invention, and corresponding to the methods of any of the embodiments described above, the present disclosure further provides a remote certification device.

[0129] Referring to Figure 4, the device acquires a first file for a first application, and the first file is used to deploy the first application to the first trusted execution environment, and the first file is arranged to include a read-only target file system in the first acquisition module 11, A second acquisition module 13 is configured to acquire the first metric value of the target file system, A boot module 15 is positioned to load the above-mentioned first file, write the above-mentioned first metric value to a command line for starting the kernel, and start the kernel in the above-mentioned first file based on the above command line, thereby deploying the above-mentioned first application to the above-mentioned first trusted execution environment. The present invention provides a remote certification device comprising: a metric module 17 that measures the kernel and other components to obtain a second metric value and is configured to perform remote certification on the first application based on the second metric value; and a metric module 17 that is configured to perform remote certification on the first application based on the second metric value.

[0130] In some embodiments, the first file includes a virtual machine image file containing service information, component information, and environment information on which the first application runs.

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

[0132] In some embodiments, the startup module 15 is The kernel described above verifies the first metric value, If the above first metric value is correct, the kernel will be configured to perform the metric.

[0133] In some embodiments, verifying the first metric value using the above-mentioned core is In the process of starting the kernel described above and executing the first file described above, the target file system in the first file described above is metriced and the third metric value is obtained, To determine whether the above third metric value and the above first metric value are the same, This includes the condition that if the above third metric value is the same as the above first metric value, then the above first metric value is correct.

[0134] In some embodiments, the metric module 17 is The kernel image and command line of the above kernel are metriced to generate a second metric value. The above second metric value is arranged to be stored in a register that matches the above first reliable execution environment.

[0135] In some embodiments, the metric module 17 is The system receives a remote certification request sent from the second application, and the second application executes it in the second trusted execution environment. Based on the above remote proof request, generate remote proof containing the above second metric value, By sending the above remote proof to the second application or remote certification service, the second application or remote certification service is configured to obtain the second metric value from the remote certification service and verify the first application based on the second metric value.

[0136] In some embodiments, the remote proof includes a remote proof report, the second metric value is stored in the remote proof report, and the device is The second application or the remote certification service described above obtains code information and related information for the first file when the first application is running in the first trusted execution environment, obtains a fourth metric value based on the code information and related information, and the metric method for the fourth metric value is configured to be the same as the metric method for the second metric value. Verifying the first application based on the above second metric value is: This includes verifying the second metric value and the fourth metric value based on a pre-configured verification strategy, and obtaining remote certification results for the first application.

[0137] In some embodiments, the remote proof includes a remote proof report and a log file of the startup phase of the first file, the second metric value is stored in the remote proof report, and the device is Based on the above remote certification report, obtain the above second metric value, Based on the above log file, the system is configured to obtain the intermediate metric value for the startup phase of the first file and to calculate the fifth metric value based on the above intermediate metric value. Verifying the first application based on the above second metric value is: This includes verifying the second metric value and the fifth metric value based on a pre-configured verification strategy, and obtaining remote certification results for the first application.

[0138] In some embodiments, the device obtains an intermediate metric value for the startup phase of the first file based on the above log file, and before calculating the fifth metric value based on the above intermediate metric value, The second application or the remote certification service described above obtains code information and related information for the first file when the first application is running in the first trusted execution environment described above, and calculates the first log information at system startup based on the code information and related information described above. Determine whether the first log information above matches the second log information in the log file above. If the first log information described above matches the second log information in the log file, the system is configured to calculate the fifth metric value based on the log file.

[0139] In some embodiments, the apparatus is Obtain the encrypted block file, By using the encrypted storage service in the target file system mentioned above, interact with the provider of the encrypted block file mentioned above to obtain the decryption key for the encrypted block file mentioned above. Based on the above decryption key, the above encrypted block file is decrypted and the decrypted block file is obtained. The above decryption block file is mounted on the system of the first trusted execution environment and positioned to respond to write requests to the first application based on the above decryption block file.

[0140] For the sake of explanation, the above-mentioned device will be described by dividing it into various modules according to their function. Of course, when implementing this disclosure, the functions of each module can be realized with the same or multiple software and / or hardware.

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

[0142] Based on the same concept of the invention, and corresponding to the method of any embodiment described above, the present disclosure further provides an electronic device that includes memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the remote certification method described in any embodiment described above.

[0143] Figure 5 shows a schematic diagram of the hardware configuration of a more specific electronic device provided by this embodiment, which may include a processor 1010, memory 1020, input / output interface 1030, communication interface 1040, and bus 1050. Here, the processor 1010, memory 1020, input / output interface 1030, and communication interface 1040 enable internal communication connections within the device via the bus 1050.

[0144] The processor 1010 can be implemented in the form of a general-purpose CPU (Central Processing Unit), a microprocessor, an Application Specific Integrated Circuit (ASIC), or one or more integrated circuits, and executes the relevant program to implement the technical proposal provided by the embodiments herein.

[0145] Memory 1020 can be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage devices, dynamic storage devices, etc. Memory 1020 can store the operating system and other applications, and when implementing the technical proposals provided by the embodiments herein by software or firmware, the relevant program code is stored in memory 1020 and called and executed by processor 1010.

[0146] The input / output interface 1030 is used to connect input / output modules to enable the input and output of information. The input / output modules may be placed as components within a device (not shown) or may be externally attached to the device to provide corresponding functions. Here, input devices may include keyboards, mice, touchscreens, microphones, various sensors, etc., and output devices may include displays, speakers, vibrators, lamps, etc.

[0147] The communication interface 1040 is used to connect a communication module (not shown) to enable communication interaction between the device and other devices. The communication module can communicate via a wired method (e.g., USB, network cable, etc.) or a wireless method (e.g., mobile network, Wi-Fi, Bluetooth, etc.).

[0148] Bus 1050 includes circuitry for transmitting information between each component of the device (e.g., processor 1010, memory 1020, input / output interface 1030, communication interface 1040).

[0149] Although the above-described apparatus only shows the processor 1010, memory 1020, input / output interface 1030, communication interface 1040, and bus 1050, in specific embodiments, this apparatus may include other components necessary to achieve normal operation. Furthermore, those skilled in the art will know that the above-described apparatus may not include all the components shown in the figures, but only the components necessary to implement the embodiments specified herein.

[0150] The electronic devices of the above embodiments are used to implement the corresponding remote certification method in any of the above embodiments and have beneficial effects of the corresponding method embodiments, which will not be described again here.

[0151] Based on the same concept of the invention and corresponding to the methods of any of the embodiments described above, the present disclosure provides a non-temporary computer-readable storage medium for storing computer instructions, the computer instructions for causing the computer to execute the remote certification method described in the methods of any of the embodiments described above.

[0152] The computer-readable media of this embodiment include persistent and non-persistent, removable and non-removable media, and can be implemented by any method or technique for implementing information storage. The information may 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 technologies, read-only optical disc memory (CD-ROM), digital multifunction optical disc (DVD) or other optical storage, magnetic cassette tape, magnetic tape, magnetic disk storage device or other magnetic storage device or other non-transmission media that can be used to store information accessible by a computer.

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

[0154] Those skilled in the art should understand that the discussion of any of the embodiments described above is illustrative and not intended to imply that the scope of the disclosure (including the requirements) is limited to these examples, and that, in the spirit of the disclosure, the technical features of the embodiments described above or different embodiments may be combined, the steps may be carried out in any order, and that many other variations of the various aspects of the embodiments of the disclosure described above exist and are not provided in detail.

[0155] Furthermore, in order to simplify the explanation and discussion and to avoid making the embodiments of this disclosure difficult to understand, the provided drawings may or may not show known power / ground connections to integrated circuit (IC) chips and other components. Furthermore, in order to avoid making the embodiments of this disclosure difficult to understand, devices may be shown in the form of block diagrams, and it should be considered that the details of embodiments of these block diagram devices are highly dependent on the platform for implementing the embodiments of this disclosure (i.e., these details should be entirely within the understanding of those skilled in the art). If specific details (e.g., circuits) are described to describe exemplary embodiments of this disclosure, it will be obvious to those skilled in the art that embodiments of this disclosure can be implemented without these specific details or with variations in these specific details. Therefore, these descriptions should be considered illustrative rather than restrictive.

[0156] While this disclosure is described in relation to specific embodiments thereof, many alternatives, modifications, and variations of these embodiments will be apparent to those skilled in the art as described above. For example, other memory architectures (e.g., dynamic RAM (DRAM)) may be used with the embodiments discussed.

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

Claims

1. A remote proof method applicable to a first trusted execution environment, A first file is obtained for a first application, and the first file is used to deploy the first application to a 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, Loading the first file, writing the first metric value to a command line for starting the kernel, starting the kernel in the first file based on the command line, and deploying the first application to the first trusted execution environment, This includes metricing the kernel and other components to obtain a second metric value, and performing remote certification to the first application based on the second metric value, Remote verification methods.

2. The first file includes a virtual machine image file containing service information, component information, and environment information on which the first application runs. The method according to claim 1.

3. The aforementioned target file system is the root file system. The method according to claim 1.

4. Starting the kernel in the first file based on the aforementioned command line means The kernel verifies the first metric value, If the first metric value is correct, the kernel is metriced, The method according to claim 1.

5. Verifying the first metric value using the aforementioned core means The process of starting the kernel in the first file includes metricing the target file system in the first file and obtaining a third metric value, To determine whether the third metric value and the first metric value are the same, If the third metric value is the same as the first metric value, the first metric value is correct, including, The method according to claim 4.

6. Metricing the kernel and other components as described above to obtain a second metric value is: The kernel image, command line, and other components of the kernel are metriced to generate a second metric value, and the second metric value includes a combination of one or more metric values. The method according to claim 1, comprising storing the second metric value in a register that matches the first reliable execution environment.

7. Performing remote certification on the first application based on the aforementioned second metric value is: The system receives a remote certification request sent from a second application, and the second application executes in a second trusted execution environment. To generate remote proof evidence including the second metric value based on the remote proof request, The process includes transmitting the remote proof to the second application or remote certification service, thereby allowing the second application or remote certification service to obtain the second metric value from the remote certification service and verify the first application based on the second metric value, The method according to claim 1.

8. The remote certification evidence includes a remote certification report, and the second metric value is stored in the remote certification report. The aforementioned method, The second application or the remote certification service further includes obtaining code information and related information of a first file when the first application is running in the first trusted execution environment, obtaining a fourth metric value based on the code information and the related information, wherein the metric method for the fourth metric value is the same as the metric method for the second metric value, Verifying the first application based on the aforementioned second metric value is: This includes verifying the second metric value and the fourth metric value based on a pre-configured verification strategy and obtaining a remote certification result for the first application, The method according to claim 7.

9. The remote proof includes a remote proof report and a log file of the startup phase of the first file, and the second metric value is stored in the remote proof report. The aforementioned method, Obtaining the second metric value based on the remote certification report, The method further includes obtaining an intermediate metric value for the startup phase of the first file based on the log file, and calculating a fifth metric value based on the intermediate metric value. Verifying the first application based on the aforementioned second metric value is: This includes verifying the second metric value and the fifth metric value based on a pre-configured verification strategy, and obtaining a remote certification result for the first application. The method according to claim 7.

10. Based on the aforementioned log file, obtain the intermediate metric value for the startup phase of the first file, and before calculating the fifth metric value based on the intermediate metric value, The second application or the remote certification 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 at system startup based on the code information and related information. To determine whether the first log information and the second log information in the log file match, If the first log information matches the second log information in the log file, the fifth metric value is calculated based on the log file, further comprising: The method according to claim 9.

11. Obtaining the encrypted block file, Interacting with the provider of the encrypted block file using the encrypted storage service in the target file system to obtain the decryption key for the encrypted block file, Based on the decryption key, decrypt the encrypted block file and obtain the decrypted block file. The further includes mounting the decrypted block file to the system of a first trusted execution environment and responding to write requests to the first application based on the decrypted block file, The method according to claim 1.

12. A first acquisition module obtains a first file for a first application, the first file is used to deploy the first application to a first trusted execution environment, and the first file is arranged to include a read-only target file system, A second acquisition module is configured to acquire a first metric value for the target file system, A boot module is configured to load the first file, write the first metric value to a command line for starting the kernel, start the kernel in the first file based on the command line, and deploy the first application to the first trusted execution environment, The system comprises a metric module configured to perform remote certification to the first application based on the kernel and other components, which are metriced to obtain a second metric value, and which is configured to perform remote certification to the first application based on the second metric value. Remote certification device.

13. The system includes memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the remote certification method described in any one of claims 1 to 11. electronic equipment.

14. A computer instruction is stored, and the computer instruction causes the computer to execute the remote certification method described in any one of the requirements 1 to 11. Non-temporary computer-readable storage medium.

Images