Remote attestation method, apparatus, medium, electronic device, and program product

Abstract

A remote attestation method, device, medium, electronic device and program product. The method comprises: loading a virtual machine image file of a first application, the virtual machine image file being used to deploy the first application in a first trusted execution environment, the virtual machine image file comprising a root file system, a joint file system and a kernel; starting the kernel and measuring the root file system to deploy the first application in the first trusted execution environment; measuring the kernel and a lower component of the kernel to obtain a first measurement value, and after the kernel is started, measuring the joint file system using an integrity measurement architecture in the kernel to obtain a second measurement value, so as to remotely attest the first application based on the first measurement value and the second measurement value. When remotely attesting the first application, the first measurement value and the second measurement value are generated based on the measurement results of the kernel and the lower component thereof and the joint file system above the kernel, so as to realize the measurement of the code and data at the application level.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and more specifically, to a remote authentication method, apparatus, medium, electronic device, and program product. Background Technology

[0002] In cloud computing scenarios, many service providers deploy their services within Trusted Execution Environments (TEEs) to meet compliance requirements, achieving data availability without visibility. TEEs can ensure confidentiality through memory encryption and guarantee integrity through remote attestation mechanisms. Service providers can use remote attestation to ensure their services are deployed in a secure TEE environment and to demonstrate to service users that the service's operating environment is secure and its operational logic meets expectations. Specifically, service users determine benchmark values ​​based on the source code / image published by the service provider and then compare them with the metrics returned by the remote attestation process. If they match, it indicates that the service's integrity has not been compromised. However, the remote attestation mechanisms in these technologies cannot measure application-level code and data, making it difficult to prove to users that the confidential services running are absolutely secure. Summary of the Invention

[0003] This summary section is provided to briefly introduce the concepts, which will be described in detail in the detailed description section below. This summary section is not intended to identify key or essential features of the claimed technical solution, nor is it intended to limit the scope of the claimed technical solution.

[0004] In a first aspect, this disclosure provides a remote proof method applied to a first trusted execution environment, the method comprising:

[0005] Load the virtual machine image file of the first application, wherein the virtual machine image file is used to deploy the first application in the first trusted execution environment, and the virtual machine image file includes a root file system, a union file system, and a kernel;

[0006] The kernel is started and the root file system is metric to deploy the first application in the first trusted execution environment, wherein an integrity measurement architecture is set on the kernel;

[0007] The kernel and its underlying components are quantified to obtain a first quantification value. After the kernel starts, the integrity quantification architecture is used to quantify the union file system to obtain a second quantification value. The first application is then remotely authenticated based on the first quantification value and the second quantification value.

[0008] Secondly, this disclosure provides a remote verification device applied in a first trusted execution environment, the method comprising:

[0009] A loading module is used to load a virtual machine image file of a first application, wherein the virtual machine image file is used to deploy the first application in the first trusted execution environment, and the virtual machine image file includes a root file system, a union file system, and a kernel;

[0010] A kernel boot module is used to boot the kernel and measure the root file system to deploy the first application in the first trusted execution environment, wherein the kernel is equipped with an integrity measurement architecture.

[0011] The first measurement module is used to measure the kernel and its lower-level components to obtain a first measurement value, and after the kernel starts, to measure the union file system using the integrity measurement architecture to obtain a second measurement value, so as to remotely verify the first application based on the first measurement value and the second measurement value.

[0012] Thirdly, this disclosure provides a computer-readable medium having a computer program stored thereon, which, when executed by a processing device, implements the steps of the remote proof method provided in the first aspect of this disclosure.

[0013] Fourthly, this disclosure provides an electronic device, comprising:

[0014] A storage device on which computer programs are stored;

[0015] A processing device is configured to execute the computer program in the storage device to implement the steps of the remote proof method provided in the first aspect of this disclosure.

[0016] Fifthly, this disclosure provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the remote proof method provided in the first aspect of this disclosure.

[0017] In the above technical solution, firstly, a virtual machine image file of the first application is loaded. This virtual machine image file is used to deploy the first application in the first trusted execution environment, and it includes a root file system, a union file system, and a kernel. Then, the kernel is started, and the root file system is measured to deploy the first application in the first trusted execution environment. The kernel has an integrity measurement architecture. Next, the kernel and its lower-level components are measured to obtain a first measurement value. After the kernel starts, the union file system is measured using the integrity measurement architecture to obtain a second measurement value. The first and second measurement values ​​are then used to remotely authenticate the first application. When remotely authenticating the first application using the first and second measurement values, these values ​​are generated based on the measurement results of the kernel, its lower-level components, and the union file system above the kernel. This achieves measurement of application-level code and data, enabling verification of the security of the first trusted execution environment and the integrity of the running code and data during remote authentication.

[0018] Other features and advantages of this disclosure will be described in detail in the following detailed description section. Attached Figure Description

[0019] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and the originals and elements are not necessarily drawn to scale. In the drawings:

[0020] Figure 1 This is an architecture diagram of an operating system for an application, illustrated according to an exemplary embodiment.

[0021] Figure 2 This is a flowchart illustrating a remote proof method according to an exemplary embodiment.

[0022] Figure 3 This is a schematic diagram illustrating a remote proof method according to an exemplary embodiment.

[0023] Figure 4 This is a schematic diagram illustrating a process for obtaining remote proof evidence according to an exemplary embodiment.

[0024] Figure 5 This is a block diagram illustrating a remote verification device according to an exemplary embodiment.

[0025] Figure 6 This is a schematic diagram of the structure of an electronic device according to an exemplary embodiment. Detailed Implementation

[0026] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0027] It should be understood that the steps described in the method embodiments of this disclosure may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of this disclosure is not limited in this respect.

[0028] The term "comprising" and its variations as used herein are open-ended inclusions, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the description below.

[0029] It should be noted that the concepts of "first" and "second" mentioned in this disclosure are used only to distinguish different devices, modules or units, and are not used to limit the order of functions performed by these devices, modules or units or their interdependencies.

[0030] It should be noted that the terms "a" and "a plurality of" used in this disclosure are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0031] The names of messages or information exchanged between multiple devices in the embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of such messages or information.

[0032] It is understood that before using the technical solutions disclosed in the various embodiments of this disclosure, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this disclosure in an appropriate manner in accordance with relevant laws and regulations, and user authorization should be obtained.

[0033] For example, upon receiving a user's active request, a prompt message is sent to the user to explicitly inform them that the requested operation will require the acquisition and use of the user's personal information. This allows the user to independently choose whether to provide personal information to the software or hardware, such as the electronic device, application, server, or storage medium performing the operations of this disclosed technical solution, based on the prompt message.

[0034] As an optional but non-limiting implementation, in response to a user's active request, sending a prompt message to the user can be done via a pop-up window, where the prompt message can be presented in text format. Furthermore, the pop-up window can also include a selection control allowing the user to choose "agree" or "disagree" to provide personal information to the electronic device.

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

[0036] Meanwhile, it is understood that the data involved in this technical solution (including but not limited to the data itself, the acquisition or use of the data) shall comply with the requirements of relevant laws, regulations and related provisions.

[0037] The TEE (Transmission Equipment) is a secure area within the Central Processing Unit (CPU). It runs in an isolated environment and in parallel with the operating system. The CPU ensures the confidentiality and integrity of code and data within the TEE. By using both hardware and software to protect data and code, the TEE is more secure than the operating system itself. Trusted applications running within the TEE can access the full functionality of the device's main processor and memory, while hardware isolation protects these components from user-installed applications running on the main operating system.

[0038] TEE implementations vary across different CPUs: a) Intel CPUs utilize technologies such as Software Guard eXtensions (SGX) and Trust Domain eXtensions (TDX); b) Mobile CPUs employ TrustZone; c) Advanced Micro Devices, Inc. (AMD) uses Secure Encrypted Virtualization (SEV) to implement TEE. These can be further categorized based on their protection granularity:

[0039] Process-level protection: SGX, TrustZone.

[0040] Virtual machine level protection: SEV, TDX, China Secure Virtualization (CSV), etc.

[0041] TDX is a confidential virtualization solution designed to isolate confidential virtual machines from non-confidential domain software stacks, ensuring that the data of confidential virtual machines is not accessed or tampered with by non-confidential domain software.

[0042] SEV is a virtual machine memory encryption technology designed to isolate virtual machines from untrusted other virtual machines and virtual machine monitors (Hypervisors).

[0043] Confidential virtual machines are virtual machines deployed based on technologies such as TDX, SEV, or CSV.

[0044] Trusted execution environment (TEX) technologies provide a remote authentication mechanism. A requester initiates a remote authentication request to a trusted application, which then retrieves the remote authentication report and provides it to the requester. By verifying the remote authentication report, the requester can confirm that the application is running on a trusted hardware platform and that its operational logic has not been modified, thereby ensuring data security.

[0045] Remote attestation reports typically include application metrics, which are hash values ​​calculated based on the application's code and data. These metrics are used to verify the application's identity and integrity. During remote attestation, the requester receives the application's remote attestation report, retrieves the application metrics from it, and compares these metrics with a pre-obtained benchmark value. This benchmark value can be reproduced from the service provider's publicly available source code and image. If the application metrics match the benchmark value, it indicates that the application's integrity has not been compromised.

[0046] like Figure 1 As shown, common virtual machine-level TEE technologies such as SEV, TDX, and CSV can only measure the firmware, GRand Unified Bootloader (Grub), and kernel of the application's operating system. They cannot measure application-layer content above the kernel, such as the root file system (rootfs), union file system, and confidential containers. Therefore, it is difficult to prove to users that the confidential services running are absolutely secure. Union file systems can be, for example, overlay file systems.

[0047] In view of this, the present disclosure provides a remote verification method, apparatus, medium, electronic device and program product.

[0048] Figure 2This is a flowchart illustrating a remote proof method according to an exemplary embodiment. The remote proof method is applied to a first trusted execution environment, which can be a virtual machine-level trusted execution environment such as SEV, TDX, or CSV; this disclosure does not limit this type of environment. Figure 2 As shown, the remote proof method may include the following S101 to S103.

[0049] In S101, the virtual machine image file of the first application is loaded. The virtual machine image file is used to deploy the first application in the first trusted execution environment, and the virtual machine image file includes the root file system, the union file system, and the kernel.

[0050] In this disclosure, the virtual machine image file of the first application may be provided by the service provider or generated in other ways, and this disclosure does not limit this.

[0051] The service provider needs to pre-create a virtual machine image file for deploying the first application and provide this virtual machine image file to the cloud service provider (CSP) that needs to deploy the first application. The cloud service provider provides a cloud server including the first trusted execution environment to deploy the first application based on the virtual machine image file. The root file system in the virtual machine image file is a read-only file system, while the union file system in the virtual machine image file, such as an overlay file system, is a read-write file system.

[0052] The kernel of a virtual machine image file is the core of an operating system. It is the first layer of software extension based on the hardware, providing the most basic functions of the operating system. It is the foundation for the operation of the operating system, responsible for managing system processes, memory, device drivers, files, and network systems, and determining the system's performance and stability.

[0053] In S102, the kernel is started and the root file system is metric to deploy the first application in the first trusted execution environment, where an integrity measurement architecture is set up on the kernel.

[0054] In this disclosure, when the service provider deploys the first application on a cloud server containing the first trusted execution environment, it needs to load the virtual machine image file of the first application and start the kernel in the virtual machine image file of the first application during the loading process, thereby realizing the deployment of the first application in the first trusted execution environment.

[0055] When creating a virtual machine image file, the service provider can configure the measurement policy of the Integrity Measurement Architecture (IMA) in the kernel. This policy instructs which files in the union file system to be measured. The IMA is part of the kernel's integrity subsystem; integrity assessment refers to the kernel's proactive integrity checks on file contents when performing specific kernel operations. For example, the measurement policy might be... Figure 3 The contents recorded in / sys / kernel / * / * / policy shown in the figure.

[0056] When the service provider boots the kernel based on the root filesystem in the virtual machine image file, it also measures the root filesystem and provides the measurement value of the root filesystem to the cloud service provider. Alternatively, a kernel with measurement verification capabilities can be used to boot the virtual machine, verifying the eighth measurement value during the boot process.

[0057] The kernel can be started and the root filesystem metric measured in the following way: First, obtain the eighth metric value for the root filesystem; then, write the eighth metric value to the command line for starting the kernel; next, start the kernel based on the command line; during the kernel startup process, the root filesystem can be measured to obtain a ninth metric value; if the eighth metric value is the same as the ninth metric value, then the kernel and its underlying components can be measured. In one possible implementation, the eighth metric value can be a hash value.

[0058] In one possible implementation, during the virtual machine startup process, a kernel-associated metrics tool can be used to measure all files (including its own service code) under the root file system to obtain a ninth metrics value. Wherein, when the eighth metrics value is a hash value, this metrics tool includes the ability to verify the hash value of the root file system. Alternatively, the same metrics tool used by the service provider to obtain the eighth metrics value can be used to obtain the ninth metrics value, ensuring that the measurement processes for the eighth and ninth metrics values ​​are identical, thus making the values ​​of the eighth and ninth metrics values ​​the same when the root file system is the same.

[0059] In one possible implementation, when the service provider obtains the eighth metric value using a metric tool, it can generate a hash tree of the virtual machine image file and use the hash value of the root node as the eighth metric value of the read-only root file system.

[0060] Before booting the kernel, the eighth metric of the root file system needs to be written to the command line when booting the kernel. At the same time, IMA needs to be enabled in the kernel command line. When booting the kernel, the kernel behavior is configured and controlled based on the command line including the eighth metric of the root file system, so as to realize the kernel boot.

[0061] After obtaining the ninth metric, it can be compared with the eighth metric. If they are the same, it means that the root file system has not changed and the eighth metric is correct. Then, the kernel can be measured. If they are different, it means that the integrity of the files in the root file system has been damaged and the virtual machine cannot start normally.

[0062] It should be noted that the eighth metric of the root file system can be provided by the service provider or generated in other ways, and this disclosure does not limit this.

[0063] The root file system is set to read-only. This ensures that the eighth metric value obtained based on the root file system is consistent and will not change due to the normal operation of the operating system. This ensures that when using the eighth metric value of the root file system for remote verification, the normal operation of the operating system will not have an adverse impact.

[0064] In S103, the kernel and its lower-level components are measured to obtain a first metric value. After the kernel starts, the integrity metric architecture is used to measure the union file system to obtain a second metric value. The first application is then remotely authenticated based on the first and second metric values.

[0065] In this disclosure, the lower-level components of the kernel may include firmware, Grub, etc., and this disclosure does not limit them. Since the command line used to boot the kernel includes an eighth metric, meaning the kernel boot process is affected by this eighth metric, and the kernel image obtained after kernel boot is also affected by this eighth metric, measuring the kernel and its components such as firmware and Grub is actually measuring the kernel and its components affected by the eighth metric. Therefore, the first metric obtained from measuring the kernel and its components such as firmware and Grub is generated based on the eighth metric, that is, based on the measurement results of the root file system.

[0066] In this scenario, when remotely verifying the first application using the first and second metrics, the first and second metrics are generated based on the measurement results of the kernel and its lower-level components, as well as the union file system at the kernel level, thereby achieving the measurement of application-level code and data.

[0067] In the above technical solution, firstly, a virtual machine image file of the first application is loaded. This virtual machine image file is used to deploy the first application in the first trusted execution environment, and it includes a root file system, a union file system, and a kernel. Then, the kernel is started, and the root file system is measured to deploy the first application in the first trusted execution environment. The kernel has an integrity measurement architecture. Next, the kernel and its lower-level components are measured to obtain a first measurement value. After the kernel starts, the union file system is measured using the integrity measurement architecture to obtain a second measurement value. The first and second measurement values ​​are then used to remotely authenticate the first application. When remotely authenticating the first application using the first and second measurement values, these values ​​are generated based on the measurement results of the kernel, its lower-level components, and the union file system above the kernel. This achieves measurement of application-level code and data, enabling verification of the security of the first trusted execution environment and the integrity of the running code and data during remote authentication.

[0068] The following is a detailed description of the specific implementation method for measuring the kernel and its lower-level components in S103 above to obtain the first measurement value.

[0069] Specifically, the kernel includes a kernel image and a command line. The kernel image, command line and their underlying components can be metricd to generate a first metric value, which includes one metric value or a combination of multiple metric values. Then, the first metric value is stored in a register that matches the first trusted execution environment.

[0070] In this disclosure, the kernel and its underlying components are metric after booting, including the kernel image itself, the kernel command line, firmware, Grub, and other components. The first metric value obtained after measurement is written to one or more registers matching the first trusted execution environment (TEX). Because different CPUs have different register types and different storage requirements, the method for writing the second metric value to the registers differs depending on the type of TEX provided by different CPU devices. In this disclosure, the register type corresponding to the first TEX needs to be determined, and the first metric value is written to the register in a manner matching the register type of the first TEX. When remote verification is required, the first metric value is retrieved from the register and written to a remote verification report, thereby enabling remote verification of the first application based on this report.

[0071] For example, in TDX, the measurement kernel and its lower-level components can be implemented through the interface of the extended register (extend_rtmr) provided by the underlying layer, storing the first measurement value in the Run-time Measurement Register (RTMR). For example, the first measurement value can be stored in the first register RTMR[2], the third register RTMR[1], and the fourth register RTMR[0].

[0072] As another example, in SEV, the kernel and its underlying components can be metricd using a modified IMA, while the first metric value is stored in the Platform Configuration Register (PCR) of the Virtual Trusted Platform Module (VTPM).

[0073] Additionally, to facilitate subsequent remote verification, when measuring the kernel and its lower-level components, the corresponding events can be recorded in the second event log during the virtual machine image file startup phase (e.g., Figure 3 In the CCEL shown.

[0074] Because different trusted execution environments (TEX) correspond to different register types, and different TEXs can provide multiple registers, the methods for generating and storing the first metric value are not the same. In this disclosure, the first metric value is calculated and stored according to the storage requirements of each register type, thereby satisfying remote proof in different types of TEX environments.

[0075] The following is a detailed description of the specific implementation method for measuring the union file system using the integrity measurement architecture in S103 above to obtain a second measurement value. Specifically, it can be achieved through the following steps (a1) to (a4).

[0076] Step (a1): Obtain the preset measurement strategy using the integrity measurement architecture.

[0077] Step (a2): For each file in at least one file, use the integrity measurement architecture to record the file's measurement value, the file's path information, and a third measurement value in the first event log, and record the third measurement value in the second event log of the virtual machine image file startup phase.

[0078] Step (a3): Use the integrity metric architecture to perform a hash operation on the current metric value and the third metric value in the first register that matches the first trusted execution environment to obtain the first hash value.

[0079] Step (a4): Update the current metric in the first register to the first hash value.

[0080] In this disclosure, the third metric is obtained by hashing the metric of the file, and the second metric includes the current metric in the first register.

[0081] In this disclosure, the hash value of a file can be used as a metric for the file. For example... Figure 3 As shown, after the kernel starts, the IMA running in the kernel will, when a file that conforms to the metric policy is opened, written to, or executed, assign the file's hash value (such as...) to the file's hash value. Figure 3 The IMAEL event log shown includes "1ld53f2d673f9f8cr00dfd87f8n66t26dfg2efd5" and file path (e.g., Figure 3 The IMAEL event log shown includes " / root / *", and the third metric (such as...). Figure 3 The IMAEL event log shown includes the Template hash "1d8d532d463c9f8c205d0df7787669a85f93e260" and the hash algorithm Template name "cima-policy" used to perform hash operations on the file's hash value, recorded as an event in the first event log " / sys / kernel / s* / * / * / IMAEL" (denoted as IMAEL). Simultaneously, when the file is opened, an extension register request (e.g., an extend_rtmr request) is triggered, extending the file's third metric to the first register matching the first trusted execution environment (e.g., ...). Figure 3 In the RTMR[2] shown, where, Figure 3 The IMR index in the table is an identifier for the register to which the third metric is to be extended. Figure 3 The "sha384" in the IMAEL event log is the hash algorithm used to generate the file hash value.

[0082] Since the first register has only one storage location, the third metric needs to be extended into the first register. This is done by using the integrity metric architecture to perform a hash operation on the current metric in the first register and the third metric to obtain a first hash value. Then, the current metric in the first register is updated with the first hash value. When the first register is empty, no hash operation is needed, and the third metric can be directly stored in the first register.

[0083] The following is a detailed description of the specific implementation method for remotely certifying the first application based on the first and second metric values ​​in S103 described above. Specifically, it can be achieved through the following steps (b1) to (b3).

[0084] Step (b1): Receive a remote authentication request sent by the second application, which runs in the second trusted execution environment.

[0085] In this disclosure, 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 can be deployed on the same trusted computing node, or they can be deployed on different trusted computing nodes; this disclosure does not impose any restrictions in this regard. The first and second trusted execution environments can be the same trusted execution environment, or the first trusted execution environment can be different from the second trusted execution environment; this disclosure does not impose any restrictions in this regard.

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

[0087] Step (b2): Generate remote proof evidence including a first metric and a second metric based on the remote proof request.

[0088] After receiving the request value sent by the second application, the first application retrieves a first metric and a second metric from the register based on the remote proof request initiated by the second application, and generates remote proof evidence containing the first and second metric values. This remote proof evidence may include a remote proof report (Quote), in which the first and second metric values ​​are stored.

[0089] The second application can then obtain the remote proof evidence returned by the first application. The remote proof evidence is used to remotely prove the existence of the first application, and this remote proof may include proof of the first application's runtime environment, and / or proof of the integrity of the application's code and runtime logic.

[0090] In one implementation, a remote proof request sent by a second application can be responded to via an Evidence Provision Service (EPS) to generate remote proof evidence. For example, such as... Figure 3 As shown, the requester can send a remote proof request (get_evidence request) to EPS through the second application. EPS can obtain the first metric and the second metric by accessing the RTMR register, generate remote proof evidence containing the first metric and the second metric, and feed it back to the requester.

[0091] Step (b3): ​​Send the remote proof evidence to the second application or remote proof service, wherein the second application or remote proof service is used to verify the first application based on the first metric and the second metric obtained from the remote proof evidence.

[0092] In this disclosure, when the second application does not trust the third party, after the first application obtains remote proof evidence, it can directly send the remote proof evidence to the second application. The second application can obtain a first metric and a second metric from the remote proof evidence to verify the first application.

[0093] like Figure 3 As shown, when the second application trusts the Remote Attestation Service (RAS), after the first application obtains the remote attestation evidence, it can send the evidence to the second application. The second application then sends a verify request containing the remote attestation evidence to the RAS. The RAS can obtain a first metric and a second metric from the remote attestation evidence, use the second metric and the second metric to verify the first application, and then return the verification result to the second application.

[0094] The verification process includes: the second application or remote verification service obtaining the code information of the first application running in the first trusted execution environment and the relevant information of the virtual machine image file disclosed by the service provider, and obtaining the baseline values ​​of the first metric and the second metric based on this information. The measurement method for the baseline value of the first metric is the same as that for the first metric, and the measurement method for the baseline value of the second metric is the same as that for the second metric. The relevant information of the virtual machine image file is information related to the virtual machine image file, such as... Figure 4 The components shown include Kernel, Initial Root File System (Initrd), Firmware (OVMF), Grub, and Bootloader (Shim).

[0095] When the second application does not trust the third party, the service provider may disclose to the second application in advance the code information and virtual machine image file information of the first application running in the first trusted execution environment. After obtaining this information, the second application can run a verification client locally. Through the verification client, the code information is run to reproduce the baseline value of the first metric and the baseline value of the second metric. Then, based on the preset verification strategy, the first metric and the baseline value of the first metric, as well as the second metric and the baseline value of the second metric, are verified to obtain the remote proof result of the first application.

[0096] In this disclosure, a preset verification strategy can be used to specify which parts of the remote evidentiary evidence are to be verified, for example, such as Figure 3 As shown, after obtaining the remote proof (Quote), it can be parsed to obtain the metric values ​​of each field in the remote proof (Quote). Then, a certain field in the remote proof (Quote) can be verified, for example, the first metric value can be verified, or the second metric value can be verified.

[0097] When the second application trusts the remote verification service, the service provider may disclose in advance the code information and virtual machine image file information of the first application running in the first trusted execution environment to the remote verification service. After obtaining the code information and related information, the remote verification service runs the code information and related information, sets the first metric value and the second metric value as the benchmark values, and then verifies the first metric value and the benchmark value of the first metric value, as well as the second metric value and the benchmark value of the second metric value, based on a preset verification strategy, thereby obtaining the remote verification result of the first application.

[0098] In one possible implementation, remote proof evidence may include a remote proof report, a first event log of the union file system startup phase, and a second event log of the virtual machine image file startup phase. The remote proof report includes a first metric and a second metric.

[0099] like Figure 4 As shown, the challenger (i.e., the second application) sends an application to a confidential virtual machine ( Figure 4 Taking a Trusted Domain Virtual Machine (TDVM) as an example, the remote authentication module of the first application (i.e., service) sends a random number (Nonce) as a challenge. This service then uses the TDX Attest library to obtain the remote authentication evidence (Quote) and event log (Event_log). Specifically, the Event_log can be a second event log (CCEL) or a first event log (IMAEL). The service then sends the obtained Quote and Event_log to the challenger as a response.

[0100] The second application or remote proof service is used to: obtain intermediate metric values ​​during the startup phase of the virtual machine image file from the second event log, and calculate a fourth metric value based on the intermediate metric values; and verify the first metric value and the second metric value according to the fourth metric value and the first event log, and according to the preset verification strategy, to obtain the remote proof result of the first application.

[0101] In this disclosure, a second log file (CCEL) for the virtual machine image file startup phase records events during this phase. The virtual machine image file startup phase refers to the entire process of loading the virtual machine image file to start the operating system within it and deploying the first application. Since the kernel and union file system are metricd during the virtual machine image file startup phase, the second log file records various intermediate metric values ​​for this phase. Therefore, after obtaining the log file for the virtual machine image file startup phase, the second application or remote verification service can calculate these intermediate metric values ​​and then reproduce the baseline value of the first metric value based on these intermediate metric values, such as... Figure 3 As shown, the first register RTMR[2], the third register RTMR[1], and the fourth register RTMR[0] can be reproduced using CCEL. Specifically, the intermediate metrics during the virtual machine image file startup phase can be hashed in the same way as the extended registers to reproduce the values ​​in the registers, which serve as the benchmark for verification. If the reproduced value in the register matches the metric in the remote proof evidence, it indicates that the corresponding metric has passed verification.

[0102] When verifying files in a union file system, the metric and third metric of the file to be verified can be obtained from the first event log based on the path of the file to be verified. If the third metric is in CCEL, it indicates that the file has been measured. At this time, the metric of the file can be verified based on the metric baseline of the file.

[0103] In one possible implementation, the remote verification report may also include a hardware signature. For example... Figure 3 As shown, after obtaining the remote proof report, the second application or remote proof service can obtain the hardware signature (i.e., verify the Quote signature) in the remote proof report. By verifying the hardware signature in the remote proof report, it can determine whether the remote proof report meets the preset conditions, and thus determine whether the remote proof report is a remote proof report generated by a trusted application running in a trusted execution environment. Only when the remote proof report is a remote proof report generated by a trusted application running in a trusted execution environment will the first metric and the second metric be obtained for remote proof.

[0104] In one possible implementation, the remote proof evidence may also include additional information, such as the public key of the first application or a random number generated by the second application, and this disclosure does not impose any limitations on this.

[0105] Simultaneously, the second application or remote proof service can also obtain first information such as the public key of the first application or a random number generated by the second application from the remote proof report. The second application or remote proof service can compare the additional information obtained from the remote proof evidence with the first information obtained from the remote proof report, thereby determining whether the remote proof report originated from the first application based on the comparison. When the random number in the additional information matches the random number in the first information, it indicates that the remote proof report originated from the first application, and no replay attack has occurred; when the random number in the additional information does not match the random number in the first information, it indicates that the remote proof report did not originate from the first application, and a replay attack has occurred. Therefore, preventing replay attacks can be achieved through the setting of additional information.

[0106] In one possible implementation, the containers created from the container image can also be measured, thereby providing a bottom-up, end-to-end measurable remote proof mechanism. Containerized deployment of services makes confidential containers more secure, usable, and flexible. In this case, the aforementioned remote proof method may further include the following steps:

[0107] After the union file system starts up, the container runtime pulls the container image and creates at least one container;

[0108] For each container in at least one container, the container is measured to obtain a fifth metric value;

[0109] Perform a hash operation on the current metric value and the fifth metric value in the second register that matches the first trusted execution environment to obtain a second hash value;

[0110] The current metric in the second register is updated to the second hash value to remotely prove the first application based on the first metric, the second metric, and the current metric in the second register.

[0111] In this disclosure, the container runtime, for example, Figure 3 In Containerd, after pulling a container image and creating at least one container, an `extend_rtmr` request can be triggered to measure the created container using the `nri` plugin within Containerd. Figure 3 As shown, the container's metric can be extended to the second register (RTMR[3]), at which point the first application can be remotely verified based on the first metric, the second metric, and the current metric in the second register.

[0112] like Figure 3As shown, in TDX, the metric container can update RTMR through the input / output control (ioctl) via the interface of extend_rtmr provided by the underlying layer[3].

[0113] In SEV, the metric container can be metricd via a modified IMA, while the corresponding information is stored in the vTPM register PCR.

[0114] In one possible implementation, such as Figure 3 As shown, when the service in the container is a model inference service, the inference model providing the model inference service can be measured when the container loads it, thereby improving the coverage of remote proofs. Specifically, the above remote proof method may also include the following steps:

[0115] When the container loads the inference model that provides model inference services, the inference model is measured to obtain the sixth metric value;

[0116] Perform a hash operation on the current metric value and the sixth metric value in the second register to obtain the third hash value;

[0117] Update the current metric in the second register to the third hash value to remotely prove the first application based on the first metric, the second metric, and the current metric in the second register.

[0118] In embodiments of this disclosure, the model inference service can be a large model inference service. Large models include one or more of large language models, large visual models, large speech models, and multimodal models.

[0119] like Figure 3 As shown, when the service in the container is the model inference service, when the container loads the inference model, the extend_rtmr request can be triggered to measure the inference model and extend the measurement value to the second register (RTMR[3]).

[0120] The following is a detailed description of the specific implementation method for remotely proving the first application based on the first metric value, the second metric value, and the current metric value in the second register. Specifically, it can be achieved through the following steps (c1) to (c3).

[0121] Step (c1): Receive a remote authentication request sent by the second application, which runs in the second trusted execution environment.

[0122] Step (c2): Based on the remote proof request, generate remote proof evidence including a first metric, a second metric, and the current metric in the second register.

[0123] Step (c3): Send the remote proof evidence to the second application or remote proof service, wherein the second application or remote proof service is used to verify the first application based on the first metric value, the second metric value and the current metric value in the second register obtained from the remote proof evidence.

[0124] In this disclosure, the first and second metric values ​​can be verified in a manner similar to that in step (b3) above, and will not be described in detail here.

[0125] like Figure 4 As shown, the challenger (i.e., the second application) sends a random number (Nonce) as a challenge to the remote proof module of the first application (i.e., the service) running in TDVM. The service then retrieves the remote proof evidence (Quote) and event log (Event_log) by calling the TDX Attest library. Specifically, the Event_log can be the second event log (CCEL), the first event log (IMAEL), or the third event log (AAEL). The service then sends the retrieved Quote and Event_log to the challenger as a response.

[0126] The second application or remote verification service can verify the metric values ​​of the container, or the metric values ​​of the container and the model, through various implementation methods (e.g., Figure 3 (Static metric verification shown). In one implementation, the second application or remote verification service obtains the code information and virtual machine image file information of the first application running in the first trusted execution environment disclosed by the service provider, and obtains the benchmark value of container metric, or the benchmark value of container and model metric based on this information, wherein the measurement method of the benchmark value of container metric is the same as the measurement method of container, and the measurement method of the benchmark value of container and model metric is the same as the measurement method of container and model.

[0127] When measuring a container, in addition to extending the container's measurement value to a second register, the container measurement event can also be recorded simultaneously. Specifically, the above remote proof method may further include the following steps:

[0128] Record the fifth metric value in the third event log.

[0129] After measuring the container and obtaining the fifth metric value, this fifth metric value can be recorded in the third event log (denoted as AAEL). For example... Figure 3 As shown, containerd, create_pod, {<pod_name> :{<image_info> : <containers>The hash value is recorded in the third event log and extended to the second register (RTMR[3]). Among them, pod is the service, pod_name is the service name, and image_info represents the hash value of the container (i.e., the fifth metric).

[0130] When the service within the container is for model inference, in addition to extending the container's metrics to the second register, both container metric events and model metric events can be recorded simultaneously. Specifically, the aforementioned remote proof method may further include the following steps:

[0131] Record the sixth metric value in the third event log.

[0132] like Figure 3 As shown, after measuring the inference model and obtaining the sixth metric value, the sixth metric value can be recorded in the third event log (AAEL).

[0133] In another implementation, remote proof evidence may include a remote proof report, a first event log of the union file system startup phase, a second event log of the virtual machine image file startup phase, and a third event log of the container startup phase. The remote proof report includes a first metric, a second metric, and the current metric in a second register.

[0134] The second application or remote proof service is used to: obtain intermediate metric values ​​of the virtual machine image file startup phase from the second event log, and calculate a fourth metric value based on the intermediate metric values; obtain all metric values ​​of at least one container startup phase from the third event log, and calculate a seventh metric value based on all metric values ​​of at least one container startup phase; and verify the first metric value, the second metric value, and the current metric value in the second register according to the fourth metric value, the seventh metric value, and the first event log, and according to the preset verification strategy, to obtain the remote proof result of the first application.

[0135] When measuring containers, all containers created based on container images are measured. All metrics during the startup phase of at least one container created based on a container image include the metrics of each container within at least one container created based on a container image, i.e., all fifth metrics. When measuring containers and models simultaneously, all metrics during the startup phase of at least one container include the metrics of each container within at least one container created based on a container image and model metrics, i.e., all fifth metrics and all sixth metrics.

[0136] Specifically, the current metric value in the second register can be verified based on the seventh metric value and a preset verification strategy.

[0137] like Figure 3 As shown, the preset verification strategy can specify the verification of the container. At this time, at least one fifth metric value of the container startup phase can be obtained from AAEL, and the seventh metric value can be calculated based on these fifth metric values ​​as the base value of the container metric. Then, the seventh metric value and the current metric value in the second register are verified. Among them, each fifth metric value of at least one container can be hashed in the same way as the second register to reproduce the value in the second register RTMR[3] as the base value of verification.

[0138] like Figure 3 As shown, the preset verification strategy can specify the verification of containers and models. At this time, all fifth and sixth metrics of at least one container startup phase can be obtained from AAEL, and a seventh metric is calculated based on these fifth and sixth metrics as the benchmark value for container and model metrics. Then, the seventh metric is verified against the current metric in the second register. Among them, the fifth and sixth metrics of at least one container can be hashed in the same way as the extended second register to reproduce the value in the second register RTMR[3] as the benchmark value for verification.

[0139] It should be noted that the measurement results of the union file system and the container-related measurement results (i.e., the results of container measurement and model measurement) can be extended to the same register. The number of registers matching the first trusted execution environment can be four as in the above example, or it can be one, that is, the first register, the second register, the third register and the fourth register mentioned above belong to the same register. It can also be two, three or even more. This disclosure does not make a specific limit on the number of registers matching the first trusted execution environment.

[0140] In addition, the event logs involved in this disclosure can be three, namely a first event log, a second event log, and a third event log. Alternatively, the container-related measurement results can be stored in the second event log at the same time. In this case, the event logs involved in this disclosure are two.

[0141] Figure 5 This is a block diagram illustrating a remote verification device according to an exemplary embodiment. The remote verification device 300 is applied in a first trusted execution environment, and the remote verification device 300 includes:

[0142] Loading module 301 is used to load the virtual machine image file of the first application, wherein the virtual machine image file is used to deploy the first application in the first trusted execution environment, and the virtual machine image file includes a root file system, a union file system, and a kernel;

[0143] Kernel startup module 302 is used to start the kernel and measure the root file system to deploy the first application in the first trusted execution environment, wherein the kernel is equipped with an integrity measurement architecture.

[0144] The first measurement module 303 is used to measure the kernel and its lower-level components to obtain a first measurement value, and after the kernel starts, to measure the union file system using the integrity measurement architecture to obtain a second measurement value, so as to remotely verify the first application based on the first measurement value and the second measurement value.

[0145] In the above technical solution, firstly, a virtual machine image file of the first application is loaded. This virtual machine image file is used to deploy the first application in the first trusted execution environment, and it includes a root file system, a union file system, and a kernel. Then, the kernel is started, and the root file system is measured to deploy the first application in the first trusted execution environment. The kernel has an integrity measurement architecture. Next, the kernel and its lower-level components are measured to obtain a first measurement value. After the kernel starts, the union file system is measured using the integrity measurement architecture to obtain a second measurement value. The first and second measurement values ​​are then used to remotely authenticate the first application. When remotely authenticating the first application using the first and second measurement values, these values ​​are generated based on the measurement results of the kernel, its lower-level components, and the union file system above the kernel. This achieves measurement of application-level code and data, enabling verification of the security of the first trusted execution environment and the integrity of the running code and data during remote authentication.

[0146] Optionally, the first measurement module 303 includes:

[0147] The first acquisition submodule is used to acquire a preset measurement strategy using the integrity measurement architecture, wherein the measurement strategy is used to instruct the measurement of at least one file in the union file system;

[0148] The recording submodule is used to record the file's metric value, the file's path information, and a third metric value in a first event log for each file in the at least one file using the integrity metric architecture, and to record the third metric value in a second event log of the virtual machine image file startup phase, wherein the third metric value is obtained by performing a hash operation on the file's metric value;

[0149] The hash operation submodule is used to perform a hash operation on the current metric value in the first register that matches the first trusted execution environment and the third metric value using the integrity metric architecture to obtain a first hash value;

[0150] An update submodule is used to update the current metric value in the first register to the first hash value, wherein the second metric value includes the current metric value in the first register.

[0151] Optionally, the remote verification device 300 further includes:

[0152] The receiving module is used to receive remote authentication requests sent by a second application, which runs in a second trusted execution environment;

[0153] The generation module is used to generate remote proof evidence including the first metric and the second metric based on the remote proof request;

[0154] A first sending module is configured to send the remote proof evidence to the second application or the remote proof service, wherein the second application or the remote proof service is configured to verify the first application based on the first metric value and the second metric value obtained from the remote proof evidence.

[0155] Optionally, the remote proof evidence includes a remote proof report, a first event log of the union file system startup phase, and a second event log of the virtual machine image file startup phase, wherein the remote proof report includes the first metric and the second metric;

[0156] The second application or the remote proof service is used to: obtain an intermediate metric value of the virtual machine image file startup phase from the second event log, and calculate a fourth metric value based on the intermediate metric value; and verify the first metric value and the second metric value according to the fourth metric value and the first event log, and according to a preset verification strategy, to obtain the remote proof result of the first application.

[0157] Optionally, the remote verification device 300 further includes:

[0158] A module is created to pull a container image and create at least one container via the container runtime after the union file system has started.

[0159] The second measurement module is used to measure each of the at least one container to obtain a fifth measurement value.

[0160] The first hash operation module is used to perform a hash operation on the current metric value in the second register that matches the first trusted execution environment and the fifth metric value to obtain a second hash value;

[0161] An update module is used to update the current metric value in the second register to the second hash value, so as to remotely prove the first application based on the first metric value, the second metric value and the current metric value in the second register.

[0162] Optionally, when the service in the container is a model reasoning service, the remote proof device 300 further includes:

[0163] The third measurement module measures the inference model when the container loads the inference model that provides the model inference service, and obtains the sixth measurement value.

[0164] The second hash operation module is used to perform a hash operation on the current metric value in the second register and the sixth metric value to obtain a third hash value;

[0165] The second update module is used to update the current metric value in the second register to the third hash value, so as to remotely prove the first application based on the first metric value, the second metric value and the current metric value in the second register.

[0166] Optionally, the remote verification device 300 includes:

[0167] The receiving module is used to receive remote authentication requests sent by a second application, which runs in a second trusted execution environment;

[0168] The generation module is used to generate remote proof evidence based on the remote proof request, including the first metric value, the second metric value, and the current metric value in the second register;

[0169] The second sending module sends the remote proof evidence to the second application or the remote proof service, wherein the second application or the remote proof service is used to verify the first application based on the first metric value, the second metric value, and the current metric value in the second register obtained from the remote proof evidence.

[0170] Optionally, the remote verification device 300 further includes:

[0171] The first recording module is used to record the fifth metric value into the third event log;

[0172] When the service in the container is a model reasoning service, the remote proof device 300 further includes:

[0173] The second recording module is used to record the sixth metric value into the third event log;

[0174] The remote proof evidence includes a remote proof report, a first event log of the union file system startup phase, a second event log of the virtual machine image file startup phase, and a third event log of the container startup phase. The remote proof report includes the first metric, the second metric, and the current metric in the second register.

[0175] The second application or the remote proof service is configured to: obtain intermediate metric values ​​of the virtual machine image file startup phase from the second event log, and calculate a fourth metric value based on the intermediate metric values; obtain all metric values ​​of the at least one container startup phase from the third event log, and calculate a seventh metric value based on the at least one container startup phase; and verify the first metric value, the second metric value, and the current metric value in the second register according to the fourth metric value, the seventh metric value, and the first event log, and according to a preset verification strategy, to obtain the remote proof result of the first application.

[0176] Optionally, the kernel boot module 302 includes:

[0177] The second acquisition submodule is used to acquire the eighth metric value for the root file system;

[0178] The startup submodule is used to write the eighth metric value into the command line for starting the kernel, and start the kernel based on the command line;

[0179] The measurement submodule is used to measure the root file system during the kernel startup process to obtain the ninth measurement value;

[0180] A trigger submodule is used to trigger the first measurement module 303 to measure the kernel and the kernel's lower-level components if the eighth measurement value is the same as the ninth measurement value.

[0181] This disclosure also provides a computer-readable medium having a computer program stored thereon, which, when executed by a processing device, implements the steps of the remote proof method described above.

[0182] This disclosure also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the remote proof method described above.

[0183] The following is for reference. Figure 6 The diagram illustrates a structural schematic of an electronic device (e.g., a terminal device or a server) 600 suitable for implementing embodiments of the present disclosure. The terminal device in the embodiments of the present disclosure may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 6 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0184] like Figure 6 As shown, electronic device 600 may include a processing device (e.g., a central processing unit, a graphics processor, etc.) 601, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 602 or a program loaded from storage device 608 into random access memory (RAM) 603. RAM 603 also stores various programs and data required for the operation of electronic device 600. Processing device 601, ROM 602, and RAM 603 are interconnected via bus 604. Input / output (I / O) interface 605 is also connected to bus 604.

[0185] Typically, the following devices can be connected to I / O interface 605: input devices 606 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 607 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 608 including, for example, magnetic tapes, hard disks, etc.; and communication devices 609. Communication device 609 allows electronic device 600 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 6 An electronic device 600 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively.

[0186] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 609, or installed from a storage device 608, or installed from a ROM 602. When the computer program is executed by the processing device 601, it performs the functions defined in the methods of embodiments of this disclosure.

[0187] It should be noted that the computer-readable medium described in this disclosure can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this disclosure, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in connection with an instruction execution system, apparatus, or device. In this disclosure, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0188] In some implementations, clients and servers can communicate using any currently known or future-developed network protocol, such as HTTP (Hypertext Transfer Protocol), and can interconnect with digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks ("LANs"), wide area networks ("WANs"), the Internet (e.g., the Internet of Things), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future-developed networks.

[0189] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device.

[0190] The aforementioned computer-readable medium carries one or more programs. When the electronic device executes the aforementioned one or more programs, the electronic device causes the electronic device to: load a virtual machine image file of a first application, wherein the virtual machine image file is used to deploy the first application in the first trusted execution environment, and the virtual machine image file includes a root file system, a union file system, and a kernel; start the kernel and measure the root file system to deploy the first application in the first trusted execution environment, wherein the kernel is provided with an integrity measurement architecture; measure the kernel and the lower-level components of the kernel to obtain a first measurement value, and after the kernel starts, use the integrity measurement architecture to measure the union file system to obtain a second measurement value, so as to remotely authenticate the first application based on the first measurement value and the second measurement value.

[0191] Computer program code for performing the operations of this disclosure can be written in one or more programming languages ​​or a combination thereof, including but not limited to object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0192] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0193] The modules described in the embodiments of this disclosure can be implemented in software or in hardware. The name of a module does not necessarily limit the module itself; for example, a loading module can also be described as "a module that loads the virtual machine image file of the first application".

[0194] The functions described above in this document can be performed, at least in part, by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: Field Programmable Gate Arrays (FPGAs), Application-Specific Integrated Circuits (ASICs), Application Standard Products (ASSPs), System-on-Chip (SoCs), Complex Programmable Logic Devices (CPLDs), and so on.

[0195] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0196] According to one or more embodiments of this disclosure, Example 1 provides a remote proof method applied to a first trusted execution environment, the method comprising:

[0197] Load the virtual machine image file of the first application, wherein the virtual machine image file is used to deploy the first application in the first trusted execution environment, and the virtual machine image file includes a root file system, a union file system, and a kernel;

[0198] The kernel is started and the root file system is metric to deploy the first application in the first trusted execution environment, wherein an integrity measurement architecture is set on the kernel;

[0199] The kernel and its underlying components are quantified to obtain a first quantification value. After the kernel starts, the integrity quantification architecture is used to quantify the union file system to obtain a second quantification value. The first application is then remotely authenticated based on the first quantification value and the second quantification value.

[0200] According to one or more embodiments of this disclosure, Example 2 provides the method of Example 1, wherein the integrity measurement architecture is used to measure the union file system to obtain a second measurement value, including:

[0201] The integrity measurement architecture is used to obtain a preset measurement strategy, wherein the measurement strategy is used to instruct the measurement of at least one file in the union file system;

[0202] For each file in the at least one file, the integrity measurement architecture is used to record the file's measurement value, the file's path information, and a third measurement value in a first event log, and the third measurement value is recorded in a second event log during the virtual machine image file startup phase, wherein the third measurement value is obtained by performing a hash operation on the file's measurement value;

[0203] The integrity measurement architecture is used to perform a hash operation on the current measurement value in the first register that matches the first trusted execution environment and the third measurement value to obtain a first hash value;

[0204] Update the current metric value in the first register to the first hash value, wherein the second metric value includes the current metric value in the first register.

[0205] According to one or more embodiments of this disclosure, Example 3 provides the method of Example 1, wherein remotely certifying the first application based on the first metric and the second metric includes:

[0206] Receive a remote authentication request sent by a second application, which runs in a second trusted execution environment;

[0207] Based on the remote proof request, generate remote proof evidence including the first metric and the second metric;

[0208] The remote proof evidence is sent to the second application or the remote proof service, wherein the second application or the remote proof service is used to verify the first application based on the first metric value and the second metric value obtained from the remote proof evidence.

[0209] According to one or more embodiments of this disclosure, Example 4 provides the method of Example 3, wherein the remote proof evidence includes a remote proof report, a first event log of the union file system startup phase, and a second event log of the virtual machine image file startup phase, and the remote proof report includes the first metric and the second metric;

[0210] The second application or the remote proof service is used to: obtain an intermediate metric value of the virtual machine image file startup phase from the second event log, and calculate a fourth metric value based on the intermediate metric value; and verify the first metric value and the second metric value according to the fourth metric value and the first event log, and according to a preset verification strategy, to obtain the remote proof result of the first application.

[0211] According to one or more embodiments of this disclosure, Example 5 provides the method of Example 1, the method further comprising:

[0212] After the union file system is started, the container image is pulled and at least one container is created through the container runtime;

[0213] For each of the at least one container, the container is measured to obtain a fifth measurement value;

[0214] A hash operation is performed on the current metric value in the second register that matches the first trusted execution environment and the fifth metric value to obtain a second hash value;

[0215] The current metric in the second register is updated to the second hash value to remotely prove the first application based on the first metric, the second metric, and the current metric in the second register.

[0216] According to one or more embodiments of this disclosure, Example 6 provides the method of Example 5, wherein when the service in the container is a model inference service, the method further includes:

[0217] When the container loads the inference model that provides the model inference service, the inference model is measured to obtain a sixth metric value;

[0218] Perform a hash operation on the current metric value in the second register and the sixth metric value to obtain a third hash value;

[0219] The current metric in the second register is updated to the third hash value to remotely prove the first application based on the first metric, the second metric, and the current metric in the second register.

[0220] According to one or more embodiments of this disclosure, Example 7 provides a method of Example 5 or Example 6, wherein remotely certifying the first application based on the first metric, the second metric, and the current metric in the second register includes:

[0221] Receive a remote authentication request sent by a second application, which runs in a second trusted execution environment;

[0222] Based on the remote proof request, generate remote proof evidence including the first metric, the second metric, and the current metric in the second register;

[0223] The remote proof evidence is sent to the second application or the remote proof service, wherein the second application or the remote proof service is used to verify the first application based on the first metric value, the second metric value and the current metric value in the second register obtained from the remote proof evidence.

[0224] According to one or more embodiments of this disclosure, Example 8 provides the method of Example 7, the method further comprising:

[0225] Record the fifth metric value in the third event log;

[0226] When the service in the container is a model inference service, the method further includes:

[0227] Record the sixth metric value in the third event log;

[0228] The remote proof evidence includes a remote proof report, a first event log of the union file system startup phase, a second event log of the virtual machine image file startup phase, and a third event log of the container startup phase. The remote proof report includes the first metric, the second metric, and the current metric in the second register.

[0229] The second application or the remote proof service is configured to: obtain intermediate metric values ​​of the virtual machine image file startup phase from the second event log, and calculate a fourth metric value based on the intermediate metric values; obtain all metric values ​​of the at least one container startup phase from the third event log, and calculate a seventh metric value based on the at least one container startup phase; and verify the first metric value, the second metric value, and the current metric value in the second register according to the fourth metric value, the seventh metric value, and the first event log, and according to a preset verification strategy, to obtain the remote proof result of the first application.

[0230] According to one or more embodiments of this disclosure, Example 9 provides the methods of Examples 1-6, wherein starting the kernel and measuring the root file system includes:

[0231] Obtain the eighth metric value for the root file system;

[0232] Write the eighth metric value into the command line for starting the kernel, and start the kernel based on the command line;

[0233] During the kernel startup process, the root file system is measured to obtain the ninth measurement value;

[0234] If the eighth metric is the same as the ninth metric, then the step of measuring the kernel and the kernel's lower-level components is performed.

[0235] According to one or more embodiments of this disclosure, Example 10 provides a remote authentication apparatus applied in a first trusted execution environment, the apparatus comprising:

[0236] A loading module is used to load a virtual machine image file of a first application, wherein the virtual machine image file is used to deploy the first application in the first trusted execution environment, and the virtual machine image file includes a root file system, a union file system, and a kernel;

[0237] A kernel boot module is used to boot the kernel and measure the root file system to deploy the first application in the first trusted execution environment, wherein the kernel is equipped with an integrity measurement architecture.

[0238] The first measurement module is used to measure the kernel and its lower-level components to obtain a first measurement value, and after the kernel starts, to measure the union file system using the integrity measurement architecture to obtain a second measurement value, so as to remotely verify the first application based on the first measurement value and the second measurement value.

[0239] According to one or more embodiments of the present disclosure, Example 11 provides a computer-readable medium having a computer program stored thereon that, when executed by a processing device, implements the steps of the method described in any one of Examples 1-9.

[0240] According to one or more embodiments of this disclosure, Example 12 provides an electronic device, including:

[0241] A storage device on which computer programs are stored;

[0242] A processing device for executing the computer program in the storage device to implement the steps of any one of the methods in Examples 1-9.

[0243] According to one or more embodiments of the present disclosure, Example 13 provides a computer program product including a computer program that, when executed by a processor, implements the steps of the method described in any one of Examples 1-9.

[0244] The above description is merely a preferred embodiment of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features disclosed in this disclosure that have similar functions.

[0245] Furthermore, while the operations are described in a specific order, this should not be construed as requiring these operations to be performed in the specific order shown or in a sequential order. In certain environments, multitasking and parallel processing may be advantageous. Similarly, while several specific implementation details are included in the above discussion, these should not be construed as limiting the scope of this disclosure. Certain features described in the context of individual embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments.

[0246] Although the subject matter has been described using language specific to structural features and / or methodological logic, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are merely illustrative forms of implementing the claims. Regarding the apparatus in the above embodiments, the specific manner in which the various modules perform their operations has been described in detail in the embodiments relating to the method, and will not be elaborated upon here.< / containers>

Claims

1. A remote proof method, characterized in that, Applied to a first trusted execution environment, the method includes: Load the virtual machine image file of the first application, wherein the virtual machine image file is used to deploy the first application in the first trusted execution environment, and the virtual machine image file includes a root file system, a union file system, and a kernel; The kernel is started and the root file system is metric to deploy the first application in the first trusted execution environment, wherein an integrity measurement architecture is set on the kernel; The kernel and its underlying components are measured to obtain a first measurement value. After the kernel starts, the integrity measurement architecture is used to measure the union file system to obtain a second measurement value, so as to remotely prove the first application based on the first measurement value and the second measurement value. The step of measuring the union file system using the integrity measurement architecture to obtain a second measurement value includes: obtaining a preset measurement strategy using the integrity measurement architecture, wherein the measurement strategy is used to instruct the measurement of at least one file in the union file system; and obtaining the second measurement value based on the hash value of the measurement value of the at least one file.

2. The method according to claim 1, characterized in that, Obtaining the second metric value based on the hash value of the metric value of the at least one file includes: For each file in the at least one file, the integrity measurement architecture is used to record the file's measurement value, the file's path information, and a third measurement value in a first event log, and the third measurement value is recorded in a second event log during the virtual machine image file startup phase, wherein the third measurement value is obtained by performing a hash operation on the file's measurement value; The integrity measurement architecture is used to perform a hash operation on the current measurement value in the first register that matches the first trusted execution environment and the third measurement value to obtain a first hash value; Update the current metric value in the first register to the first hash value, wherein the second metric value includes the current metric value in the first register.

3. The method according to claim 1, characterized in that, The remote authentication of the first application based on the first metric and the second metric includes: Receive a remote authentication request sent by a second application, which runs in a second trusted execution environment; Based on the remote proof request, generate remote proof evidence including the first metric and the second metric; The remote proof evidence is sent to the second application or the remote proof service, wherein the second application or the remote proof service is used to verify the first application based on the first metric value and the second metric value obtained from the remote proof evidence.

4. The method according to claim 3, characterized in that, The remote proof evidence includes a remote proof report, a first event log of the union file system startup phase, and a second event log of the virtual machine image file startup phase. The remote proof report includes the first metric and the second metric. The second application or the remote proof service is used to: obtain an intermediate metric value of the virtual machine image file startup phase from the second event log, and calculate a fourth metric value based on the intermediate metric value; and verify the first metric value and the second metric value according to the fourth metric value and the first event log, and according to a preset verification strategy, to obtain the remote proof result of the first application.

5. The method according to claim 1, characterized in that, The method further includes: After the union file system is started, the container image is pulled and at least one container is created through the container runtime; For each of the at least one container, the container is measured to obtain a fifth measurement value; A hash operation is performed on the current metric value in the second register that matches the first trusted execution environment and the fifth metric value to obtain a second hash value; The current metric in the second register is updated to the second hash value to remotely prove the first application based on the first metric, the second metric, and the current metric in the second register.

6. The method according to claim 5, characterized in that, When the service in the container is a model inference service, the method further includes: When the container loads the inference model that provides the model inference service, the inference model is measured to obtain a sixth metric value; Perform a hash operation on the current metric value in the second register and the sixth metric value to obtain a third hash value; The current metric in the second register is updated to the third hash value to remotely prove the first application based on the first metric, the second metric, and the current metric in the second register.

7. The method according to claim 5 or 6, characterized in that, The remote authentication of the first application based on the first metric, the second metric, and the current metric in the second register includes: Receive a remote authentication request sent by a second application, which runs in a second trusted execution environment; Based on the remote proof request, generate remote proof evidence including the first metric, the second metric, and the current metric in the second register; The remote proof evidence is sent to the second application or the remote proof service, wherein the second application or the remote proof service is used to verify the first application based on the first metric value, the second metric value and the current metric value in the second register obtained from the remote proof evidence.

8. The method according to claim 7, characterized in that, The method further includes: Record the fifth metric value in the third event log; When the service in the container is a model inference service, the method further includes: Record the sixth metric value in the third event log; The remote proof evidence includes a remote proof report, a first event log of the union file system startup phase, a second event log of the virtual machine image file startup phase, and a third event log of the container startup phase. The remote proof report includes the first metric, the second metric, and the current metric in the second register. The second application or the remote proof service is configured to: obtain intermediate metric values ​​of the virtual machine image file startup phase from the second event log, and calculate a fourth metric value based on the intermediate metric values; obtain all metric values ​​of the at least one container startup phase from the third event log, and calculate a seventh metric value based on the at least one container startup phase; and verify the first metric value, the second metric value, and the current metric value in the second register according to the fourth metric value, the seventh metric value, and the first event log, and according to a preset verification strategy, to obtain the remote proof result of the first application.

9. The method according to any one of claims 1-6, characterized in that, The process of starting the kernel and measuring the root file system includes: Obtain the eighth metric value for the root file system; Write the eighth metric value into the command line for starting the kernel, and start the kernel based on the command line; During the kernel startup process, the root file system is measured to obtain the ninth measurement value; If the eighth metric is the same as the ninth metric, then the step of measuring the kernel and the kernel's lower-level components is performed.

10. A remote verification device, characterized in that, The apparatus, applied to a first trusted execution environment, comprises: A loading module is used to load a virtual machine image file of a first application, wherein the virtual machine image file is used to deploy the first application in the first trusted execution environment, and the virtual machine image file includes a root file system, a union file system, and a kernel; A kernel boot module is used to boot the kernel and measure the root file system to deploy the first application in the first trusted execution environment, wherein the kernel is equipped with an integrity measurement architecture. The first measurement module is used to measure the kernel and its lower-level components to obtain a first measurement value, and after the kernel starts, to measure the union file system using the integrity measurement architecture to obtain a second measurement value, so as to remotely prove the first application based on the first measurement value and the second measurement value. The first measurement module is used to obtain a preset measurement strategy using the integrity measurement architecture, wherein the measurement strategy is used to instruct the measurement of at least one file in the union file system; and to obtain the second measurement value based on the hash value of the measurement value of the at least one file.

11. A computer-readable medium having a computer program stored thereon, characterized in that, When executed by a processing device, the computer program performs the steps of the method according to any one of claims 1-9.

12. An electronic device, characterized in that, include: A storage device on which computer programs are stored; A processing device for executing the computer program in the storage device to implement the steps of the method according to any one of claims 1-9.

13. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1-9.

Images