Remote attestation methods for cloud server, electronic device, and storage medium

Abstract

The present disclosure relates to the technical field of computers and cloud computing. Disclosed are remote attestation methods for a cloud server, an electronic device, and a storage medium. A method comprises: receiving from a cloud server a loading message for a virtual component, a preset security architecture being deployed in the cloud server, and a secure world runtime environment and a normal world runtime environment being created in the preset security architecture; generating a remote attestation report on the basis of the loading message; and outputting the remote attestation report to a remote attestation verification component in the cloud server, the remote attestation verification component running in the normal world runtime environment, and the remote attestation verification component being used for performing remote attestation on a target trusted kernel system on the basis of the remote attestation report.

Description

[0001] Remote certification method of cloud server, electronic device and storage medium Technical field

[0002]

[0001] The present disclosure relates to the fields of computer technology and cloud computing technology, and more specifically, to a remote certification method, electronic device, and storage medium for a cloud server.

[0003]

[0002] The Trusted Execution Environment (TEE) framework is a secure hardware and software technology used to create a secure execution environment in a computing device. Currently, a TEE based on ARM TrustZone technology has been proposed on advanced RISC Machine (ARM) servers. It supports dynamic loading of multiple TEE operating systems (OS) to provide users with a computing solution that takes into account both security and high performance.

[0004]

[0003] Currently, there is no standard remote attestation solution for TEE based on ARM TrustZone technology, and there is also a lack of solutions supporting multiple TEE OS remote attestations on ARM servers.

[0005]

[0004] In view of the above problems, no effective solution has been proposed yet.

[0006]

[0005] The embodiments of the present disclosure provide a remote attestation method, electronic device, and storage medium for a cloud server, so as to at least solve the technical problem in the related art that there is a lack of a solution for supporting remote attestation of multiple trusted execution environment operating systems on advanced reduced instruction set computer servers.

[0007]

[0006] According to one aspect of an embodiment of the present disclosure, a remote attestation method for a cloud server is provided, comprising: receiving a loading message from a virtualization component in the cloud server, wherein a preset security architecture is deployed in the cloud server, a secure world operating environment and a non-secure world operating environment are created on the preset security architecture, a virtualization component runs in the secure world operating environment, the virtualization component is used to provide physical isolation for multiple user trusted kernel systems, and the loading message is used to determine to load a target trusted kernel system from the multiple user trusted kernel systems; generating a remote attestation report based on the loading message, wherein the remote attestation report is used to provide verification content of the target trusted kernel system; and outputting the remote attestation report to a remote attestation verification component in the cloud server, wherein a remote attestation verification component runs in the non-secure world operating environment, and the remote attestation verification component is used to remotely attest the target trusted kernel system based on the remote attestation report.

[0008]

[0007] According to another aspect of an embodiment of the present disclosure, a remote attestation method for a cloud server is provided, comprising: receiving a loading instruction from a trusted kernel system deployment component in the cloud server, wherein a preset security architecture is deployed in the cloud server, a secure world operating environment and a non-secure world operating environment are created on the preset security architecture, a trusted kernel system deployment component is running in the non-secure world operating environment, and the trusted kernel system deployment component is used to deploy multiple user trusted kernel systems in the secure world operating environment; sending a loading message to a security component in the cloud server based on the loading instruction, so that the security component outputs a remote attestation report to a remote attestation verification component, wherein the loading message is used to determine to load a target trusted kernel system from the multiple user trusted kernel systems, the secure world operating environment is running a security component, the security component is used to support remote attestation of the multiple user trusted kernel systems, the non-secure world operating environment is running a remote attestation verification component, the remote attestation verification component is used to remotely attest the target trusted kernel system based on the remote attestation report, and the remote attestation report is used to provide verification content of the target trusted kernel system, so that the remote attestation verification component remotely attests the target trusted kernel system based on the remote attestation report.

[0009]

[0008] According to another aspect of an embodiment of the present disclosure, a cloud server is provided. A preset security architecture is deployed in the cloud server. A secure world operating environment and a non-secure world operating environment are created on the preset security architecture. A security component and a virtualization component run in the secure world operating environment, and a trusted kernel system deployment component and a remote attestation verification component run in the non-secure world operating environment. The security component is configured to receive a load message from the virtualization component, generate a remote attestation report based on the load message, and output the remote attestation report to the remote attestation verification component, wherein the load message is used to determine whether to load a target trusted kernel system from multiple user trusted kernel systems, and the remote attestation report is used to provide verification content of the target trusted kernel system. The trusted kernel system deployment component is configured to send a load instruction to the virtualization component, wherein the load instruction is used to instruct the virtualization component to send a load message. The remote attestation verification component is configured to receive the remote attestation report output by the security component and remotely attest the target trusted kernel system based on the remote attestation report. The virtualization component is configured to receive the load instruction from the remote attestation verification component and send a load message to the security component based on the load instruction.

[0010]

[0009] According to another aspect of an embodiment of the present disclosure, an electronic device is also provided, comprising: a memory storing an executable program; and a processor for running the program, wherein when the program is running, any one of the above-mentioned remote attestation methods of the cloud server is executed.

[0011]

[0010] According to another aspect of the embodiment of the present disclosure, a computer-readable storage medium is also provided, which includes a stored executable program, wherein when the executable program is running, the device where the computer-readable storage medium is located is controlled to execute any one of the above-mentioned remote certification methods of the cloud server.

[0012]

[0011] According to another aspect of the embodiment of the present disclosure, a computer program product is also provided, including a computer program, which implements any one of the above-mentioned remote certification methods of the cloud server when executed by a processor.

[0013]

[0012] In an embodiment of the present disclosure, by receiving a loading message from a virtualization component in a cloud server, that is, by receiving a loading message from an S-EL2 component in an ARM server, wherein a preset security architecture is deployed in the cloud server, a secure world operating environment and a non-secure world operating environment are created on the preset security architecture, and an S-EL2 component for providing physical isolation for multiple user trusted kernel systems is run in the secure world operating environment. The loading message is used to determine to load a target trusted kernel system from multiple user trusted kernel systems, that is, to determine a target user TEE OS from multiple user TEE OSes. Then, based on the loaded message, a remote attestation report is generated to provide verification content of the target trusted kernel system, and the remote attestation report is output to the remote attestation verification component running in the non-secure world operating environment in the cloud server, so that the remote attestation verification component can remotely attest the target trusted kernel system based on the remote attestation report. In this way, the purpose of providing security services for remote attestation of each TEE OS through an independent security module is achieved, thereby providing a standard remote attestation solution for TEE based on ARM TrustZone technology and effectively ensuring the security of the security module's access to the trusted root key. This solves the technical problem in the related art of the lack of a solution that supports remote attestation of multiple trusted execution environment operating systems on advanced reduced instruction set computer servers.

[0014]

[0013] It is easy to note that the above general description and the following detailed description are only for the purpose of exemplifying and explaining the present disclosure and do not constitute a limitation of the present disclosure.

[0015]

[0014] The drawings described herein are intended to provide a further understanding of the present disclosure and constitute a part of the present disclosure. The illustrative embodiments of the present disclosure and their descriptions are intended to explain the present disclosure and do not constitute an improper limitation of the present disclosure. In the drawings:

[0016]

[0015] FIG1 is a hardware structure block diagram of a computer terminal (or mobile device) for implementing a remote attestation method of a cloud server according to Embodiment 1 of the present disclosure;

[0017]

[0016] FIG2 is a flow chart of a remote certification method of a cloud server according to Embodiment 1 of the present disclosure;

[0018] FIG3 is a schematic diagram of CPU resource allocation of an ARM server according to Embodiment 1 of the present disclosure;

[0019] FIG4 is a flow chart of outputting a remote attestation report according to Embodiment 1 of the present disclosure;

[0020]

[0019] FIG5 is a flow chart of a remote certification method of a cloud server according to Embodiment 2 of the present disclosure;

[0021]

[0020] FIG6 is a flow chart of a remote attestation method of a cloud server according to Embodiment 3 of the present disclosure;

[0022]

[0021] FIG. 7 is a schematic diagram of the structure of a remote attestation device for a cloud server according to Embodiment 5 of the present disclosure;

[0022] FIG. 8 is a schematic diagram of the structure of another remote attestation device for a cloud server according to Embodiment 5 of the present disclosure;

[0023]

[0023] FIG9 is a schematic structural diagram of a remote certification device of another cloud server according to Embodiment 5 of the present disclosure;

[0024]

[0024] FIG10 is a block diagram of a computer terminal according to an embodiment of the present disclosure.

[0025] To help those skilled in the art better understand the present disclosure, the technical solutions in the embodiments of the present disclosure will be described clearly and completely below with reference to the accompanying drawings. It should be understood that the described embodiments are merely a portion of the embodiments of the present disclosure, and are not intended to be exhaustive. All other embodiments derived by those skilled in the art based on the embodiments of the present disclosure without creative effort shall fall within the scope of protection of the present disclosure.

[0026]

[0026] It should be noted that the terms "first," "second," and the like in the specification and claims of the present disclosure and the accompanying drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or precedence. It should be understood that the terms used in this manner are interchangeable where appropriate, so that the embodiments of the present disclosure described herein can be implemented in an order other than that illustrated or described herein. In addition, the terms "including," "comprising," and "having," and any variations thereof, are intended to cover non-exclusive inclusions. For example, a process, method, system, product, or apparatus comprising a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units that are not explicitly listed or that are inherent to such process, method, product, or apparatus.

[0027]

[0027] First, some nouns or terms that appear in the process of describing the embodiments of the present disclosure are subject to the following explanations.

[0028]

[0028] Trusted Execution Environment (TEE) framework: It is a secure hardware and software technology used to create a secure execution environment, or secure world, in a computing device to protect sensitive data and applications from malware and attacks.

[0029]

[0029] Rich Execution Environment (REE): This generally refers to a common operating system environment, which can be understood as a non-secure execution environment, i.e., a non-secure world, such as the environment in which traditional operating systems (such as Windows and Linux) run. In contrast, a TEE is a secure execution environment used to protect sensitive data and perform sensitive operations.

[0030] A Trusted Execution Environment Operating System (TEE OS) is a secure and trusted execution environment operating system primarily used to protect sensitive data and perform sensitive operations. A TEE OS typically runs in a secure processor or security module, separate from the standard operating system, providing additional security.

[0031] Advanced RISC Machine TrustZone (ARM TrustZone): A hardware-level security technology used to create secure and non-secure execution environments on ARM architecture processors. TrustZone technology partitions the processor's physical resources into a secure world and a non-secure world (i.e., the normal world), each with its own processor state and memory space. This partitioning allows sensitive data and critical operations to be performed in the secure world while protecting the system from malware and attacks.

[0032]

[0032] Non-Secure World: This refers to an execution environment within a processor that runs non-secure software, such as standard operating systems and applications. In this execution environment, access to processor resources and permission control are relatively low, and some critical security functions cannot be directly accessed or processed.

[0033]

[0033] Secure World: This is another execution environment within the processor, used to run secure software, such as software for sensitive operations like secure boot, key management, and security monitoring. In this execution environment, processor resource access and permission control are relatively high, allowing the execution of critical security functions and access to resources and hardware features not accessible in the non-secure world.

[0034] A Quoting Trusted Application (QTA) is a special trusted application within the TEE whose primary function is to generate remote attestation reports. This application uses the security mechanisms and key generation algorithms provided by the TEE to generate attestation reports containing the TEE environment status and security information, used to demonstrate the security and credibility of the TEE environment.

[0035]

[0035] User Trusted Application (TA): A trusted application developed by an end user or a third-party developer that runs in a TEE to protect the user's sensitive data and perform sensitive operations.

[0036]

[0036] Basic Input / Output System (BIOS): is a software located on the computer motherboard, responsible for initializing hardware devices, performing self-tests and system initialization when the computer starts, and performing some basic system management functions before the operating system starts.

[0037]

[0037] S-ELO, S-EL1 and S-EL2 are concepts in the ARM TrustZone technology, used to represent different secure execution levels.

[0038]

[0038] S-ELO (Secure Exception Level 0): is the user space level of the secure world. At this level, application code that does not require a privileged level can be run.

[0039]

[0039] S-EL1 (Secure Exception Level 1): This is the operating system level of the secure world. At this level, operating system kernel code and privileged application code can run.

[0040]

[0040] S-EL2 (Secure Exception Level 2): ​​This is the virtualization level of the secure world. At this level, virtualization software such as a hypervisor or a virtual machine monitor (VMM) can be run.

[0041]

[0041] The Root of Trust Key (ROT): This is a very important and highly secure key used to establish a chain of trust for other keys in the system and ensure the security and credibility of the system. The ROT is typically used to sign certificates or signatures corresponding to other keys, which can be used to verify the legitimacy and credibility of other keys. The private key of the ROT is typically stored in a highly secure environment to ensure it cannot be leaked or tampered with.

[0042]

[0042] Exception level (EL): The exception level of the ARM processor architecture, also known as the privilege level. In the disclosed embodiments, this is also referred to as the exception hierarchy. There are four levels, EL0 to EL3, including Non-Secure ELx for the non-secure world and Secure ELx for the secure world. Different privilege levels correspond to different privilege levels, used to execute different instructions and access different resources.

[0043]

[0043] EL0: also known as user mode, is used to execute ordinary user applications and can only access the memory and resources of the user space.

[0044]

[0044] ELI: Also known as the supervisor state, it is used to execute the operating system kernel and some privileged level applications, and can access all memories and resources.

[0045]

[0045] EL2: also known as virtualization extension level, is used to support virtualization technology and can create and manage virtual machines.

[0046]

[0046] EL3: Also known as the security extension level, used to perform security-related operations, such as secure boot and security authentication.

[0047] Different privilege levels can be switched through exceptions and interrupts to achieve interaction and management between different privilege levels. This division of privilege levels can improve the security and stability of the system and achieve isolation and management of applications and systems at different levels.

[0048]

[0048] Authentication Key (AK): refers to a key used to access and manage resources on the cloud service provider platform.

[0049] Currently, related art proposes a computing suite based on the TrustZone platform of an ARM server. This computing suite uses a trusted application (QTA) built into the TEE OS to generate remote attestation reports. However, this computing suite only supports one TEE OS per server, and the QTA and the user (TA) run within the same TEE OS. Therefore, ensuring that the QTA's trusted root key for accessing the chip is not leaked and cannot be compromised by the user (TA) is crucial to ensuring the remote attestation process is secure and reliable.

[0050] However, TEE based on ARM TrustZone technology supports multiple TEE OSs, and each TEE OS is dynamically loaded from REE. If QTA is used to generate remote attestation reports, the following defects will occur.

[0050]

[0051] Flaw 1: If QTA is built into the dynamically loaded TEE OS, the high security level achieved by secure booting with the server BIOS cannot be achieved.

[0051]

[0052] Defect 2: There is only a logical isolation mechanism provided by TEE OS between QTA and user TA, but no highly secure physical isolation mechanism. In addition, QTA and TA can communicate with each other, which poses a risk of data leakage.

[0052]

[0053] Defect 3: If multiple QTAs of multiple TEE OSs can access the root of trust key, then if one of the QTAs is compromised, the security of all TEE OSs on the server will be compromised.

[0053]

[0054] According to an embodiment of the present disclosure, a remote attestation method for a cloud server is provided. It should be noted that the steps shown in the flowcharts of the accompanying drawings can be executed in a computer system, such as a set of computer-executable instructions. Moreover, although a logical order is shown in the flowcharts, in some cases, the steps shown or described can be executed in an order different from that shown.

[0054]

[0055] The method embodiment provided in the first embodiment of the present disclosure can be executed in a mobile terminal, a computer terminal, or a similar computing device. Figure 1 is a hardware block diagram of a computer terminal (or mobile device) for implementing a remote attestation method for a cloud server according to the first embodiment of the present disclosure. As shown in Figure 1 , the computer terminal 10 (or mobile device) may include one or more processors 102 (illustrated as 102a, 102b, ..., 102n) (processor 102 may include, but is not limited to, a microprocessor (MCU) or a processing device such as a programmable logic device (FPGA), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, the device may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of a BUS), a network interface, a power supply, and / or a camera. Those skilled in the art will appreciate that the structure shown in Figure 1 is merely illustrative and does not limit the structure of the electronic device described above. For example, the computer terminal 10 may also include more or fewer components than shown in FIG. 1 , or have a configuration different from that shown in FIG. 1 .

[0055]

[0056] It should be noted that the one or more processors 102 and / or other data processing circuits described above may generally be referred to herein as "data processing circuitry." This data processing circuitry may be embodied in whole or in part as software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuitry may be a single, independent processing module, or may be fully or partially integrated into any of the other components of the computer terminal 10 (or mobile device). As discussed in the embodiments of the present disclosure, this data processing circuitry functions as a processor control (e.g., selection of a variable resistor terminal path connected to an interface).

[0056]

[0057] Memory 104 can be used to store software programs and modules for application software, such as the program instructions / data storage device corresponding to the remote attestation method for a cloud server in the embodiments of the present disclosure. Processor 102 executes the software programs and modules stored in memory 104 to perform various functional applications and data processing, thereby implementing the aforementioned remote attestation method for a cloud server. Memory 104 may include high-speed random access memory (RAM) and non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, memory 104 may further include memory remotely located from processor 102. Such remote memory can be connected to computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0057]

[0058] The transmission device 106 is used to receive or send data via a network. A specific example of the aforementioned network may include a wireless network provided by the communications provider of the computer terminal 10. In one example, the transmission device 106 includes a network interface controller (NIC), which can be connected to other network devices via a base station to enable communication with the Internet. In another example, the transmission device 106 may be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0059] The display may be, for example, a touch screen liquid crystal display (LCD), which enables a user to interact with a user interface of the computer terminal 10 (or mobile device).

[0058]

[0060] In the above operating environment, the present disclosure provides a remote attestation method for a cloud server as shown in FIG2 . FIG2 is a flow chart of a remote attestation method for a cloud server according to Embodiment 1 of the present disclosure. As shown in FIG2 , the method may include the following steps:

[0059]

[0061] Step S21: receiving a loading message from a virtualization component in a cloud server. A preset security architecture is deployed in the cloud server. A secure world operating environment and a non-secure world operating environment are created on the preset security architecture. The secure world operating environment runs a virtualization component, which is used to provide physical isolation for multiple user trusted kernel systems. The loading message is used to determine whether to load a target trusted kernel system from among the multiple user trusted kernel systems.

[0060]

[0062] Step S22: generating a remote attestation report based on the loading message, wherein the remote attestation report is used to provide verification content of the target trusted kernel system;

[0061]

[0063] In step S23, the remote attestation report is output to a remote attestation verification component in the cloud server, wherein the remote attestation verification component runs in the non-secure world operating environment and is used to remotely attest the target trusted kernel system based on the remote attestation report.

[0062]

[0064] In the embodiment of the present disclosure, the cloud server can be understood as an ARM server. A preset security architecture is deployed in the cloud server. The preset security architecture can be understood as an ARM TrustZone architecture.

[0063]

[0065] It is understandable that the ARM TrustZone architecture can divide the central processing unit (CPU) resources of the ARM server into a non-secure world and a secure world, that is, create a secure world operating environment and a non-secure world operating environment on the ARM TrustZone architecture.

[0064]

[0066] The Secure World runtime environment runs a virtualization component, which can be understood as an S-EL2 component. This component is used to run virtualization software, such as a hypervisor or VMM. The virtualization component is also used to provide physical isolation for multiple user trusted kernel systems. This can be understood as providing physical isolation for multiple user TEE OSes, providing independent trusted execution environments for multiple different users or entities, ensuring that they are physically isolated from each other to protect the security and privacy of multiple users or entities.

[0065]

[0067] The loading message is used to determine the target trusted kernel system to be loaded from multiple user trusted kernel systems. The target trusted kernel system can be understood as a certain user's TEE OS, for example, it can be recorded as TEE OS 1.

[0066]

[0068] Remote attestation reports are used to verify the identity, status, or trustworthiness of a user or entity. They can be used to verify the entity's identity, security status, or the legitimacy of an operation. For example, when a user or entity needs to prove their legitimacy and trustworthiness to another user or entity, they can do so based on a remote attestation report. In the disclosed embodiments, remote attestation reports are used to provide verification content for the target trusted kernel system, specifically, the target trusted kernel system's identity, security status, or trustworthiness.

[0067]

[0069] For example, the remote attestation report may include security status and information about the entity, and the information may be encrypted or digitally signed.

[0068]

[0070] The remote attestation verification component, which can be understood as a remote attestation verification library, runs in the non-secure world. It is used to remotely attest the target trusted kernel system based on the remote attestation report. This verifies the identity, status, or trustworthiness of the target trusted kernel system and establishes trust in the target trusted kernel system. Remote attestation of the target trusted kernel system based on the remote attestation report enables the receiver to confirm the legitimacy and security status of the sender, ensuring that it can be trusted and interact securely with it.

[0069]

[0071] In the disclosed embodiments, the execution entity can be an independent security module (or security component), namely, a security module within a TEE based on ARM TrustZone technology. For example, the security module securely boots with the BIOS during the ARM server power-on process. The security module can be deployed in either S-EL0 or S-EL1 of the ARM TrustZone architecture, without limitation.

[0072] In embodiments of the present disclosure, a remote attestation process supporting multiple user TEE operating systems is provided. A virtualization component (i.e., an S-EL2 component) in a cloud server (i.e., an ARM server) can send a load message to a security module, used to determine whether to load a target trusted kernel system from among multiple user trusted kernel systems. This load message is used to determine the target user TEE OS from among multiple user TEE OSes. The independent security module provided in embodiments of the present disclosure receives the load message from the S-EL2 component in the ARM server. Based on the load message, it generates a remote attestation report providing verification details of the target user TEE OS. The remote attestation report is then output to a remote attestation verification component running in a non-secure world operating environment in the ARM server, enabling the remote attestation verification component to remotely attest the target user TEE OS based on the remote attestation report. The ARM server is deployed with a pre-defined security architecture (i.e., an ARM TrustZone architecture). The ARM TrustZone architecture includes a secure world operating environment and a non-secure world operating environment. The secure world operating environment runs the S-EL2 component, which provides physical isolation for multiple user TEE OSes.

[0070]

[0073] As can be seen, this disclosure utilizes a security module located in an independent partition, with the S-EL2 component providing physical isolation between the security module and multiple TEE operating systems. This ensures the security module's access to the root of trust key is secure. Furthermore, the remote attestation process for multiple TEE operating systems in this disclosure is implemented through communication with the security module, meaning only the security module can access the root of trust key. Therefore, even if one TEE operating system is compromised, the security of other TEE operating systems on the server is not affected, resulting in extremely high security.

[0071]

[0074] The remote attestation method of the cloud server provided in the embodiments of the present disclosure can be applied to, but is not limited to, application scenarios involving remote attestation in the fields of e-commerce services, educational services, legal services, medical services, conference services, social network services, financial product services, logistics services, and navigation services, for example: remote attestation of a user or entity in e-commerce services, remote attestation of a user or entity in educational services, remote attestation of a user or entity in medical services, etc., which are not limited here.

[0072]

[0075] According to an embodiment of the present disclosure, a loading message is received from a virtualization component in a cloud server, that is, a loading message is received from an S-EL2 component in an ARM server. A preset security architecture is deployed in the cloud server, a secure world operating environment and a non-secure world operating environment are created on the preset security architecture, and an S-EL2 component for providing physical isolation for multiple user trusted kernel systems runs in the secure world operating environment. The loading message is used to determine the target trusted kernel system to be loaded from the multiple user trusted kernel systems, that is, to determine the target user TEE OS from the multiple user TEE OSes. Then, based on the loaded message, a remote attestation report is generated to provide verification content of the target trusted kernel system, and the remote attestation report is output to the remote attestation verification component running in the non-secure world operating environment in the cloud server, so that the remote attestation verification component can remotely attest the target trusted kernel system based on the remote attestation report. In this way, the purpose of providing security services for remote attestation of each TEE OS through an independent security module is achieved, thereby providing a standard remote attestation solution for TEE based on ARM TrustZone technology and effectively ensuring the security of the security module's access to the trusted root key. This solves the technical problem in the related art of the lack of a solution that supports remote attestation of multiple trusted execution environment operating systems on advanced reduced instruction set computer servers.

[0073]

[0076] In an optional embodiment, in step S22, generating a remote attestation report based on the loading message includes the following method steps: step S221, obtaining a trusted root key stored in a processor of a cloud server based on the loading message, and obtaining measurement information of a trusted application running in a target trusted kernel system; step S222, generating a remote attestation report using the trusted root key and the measurement information.

[0074]

[0077] In the disclosed embodiments, the root of trust key can be understood as the root of trust key stored in the CPU of the ARM server. The trusted application can be understood as a trusted application program, namely, a TA. The trusted application running in the target trusted kernel system is the user TA running in the target user TEE OS.

[0075]

[0078] The measurement information can be understood as certain specific data or indicators of the user TA, which may include the user's behavior pattern, activity records, identity verification information, etc., which are not limited here.

[0076]

[0079] In the disclosed embodiments, when generating a remote attestation report based on a load message, the security module can obtain the root of trust key stored in the cloud server's processor and measurement information of the trusted application running in the target trusted kernel system based on the load message. Specifically, based on the load message sent by the S-EL2 component in the ARM server, the security module obtains the root of trust key stored in the ARM server's CPU and measurement information of the user TA running in the target user's TEE OS. After obtaining the root of trust key and measurement information, the security module can generate a remote attestation report based on the root of trust key and measurement information.

[0077]

[0080] In an optional embodiment, in step S221, obtaining the trusted root key stored in the processor of the cloud server based on the loading message includes the following method steps: Step S2211, sending a trusted root key read message to the trusted firmware in the cloud server based on the loading message, so that the trusted firmware reads the trusted root key from the processor of the cloud server based on the trusted root key read message, wherein the trusted firmware runs in the secure world operating environment, and the trusted firmware is used to provide a trusted root key reading function.

[0078]

[0081] In the disclosed embodiments, the trusted firmware may be understood as ARM trusted firmware, namely, EL3 firmware. The trusted firmware runs in the secure world operating environment and is used to provide a trusted root key reading function, namely, to read the trusted root key message stored in the CPU of the ARM server.

[0079]

[0082] In the disclosed embodiment, when the security module obtains the trusted root key stored in the processor of the cloud server based on the load message, it can send a trusted root key read message to the trusted firmware in the cloud server based on the load message, so that the trusted firmware reads the trusted root key from the processor of the cloud server based on the trusted root key read message. In other words, the security module sends the trusted root key read message to the EL3 firmware in the ARM server based on the load message sent by the S-EL2 component in the ARM server, so that the EL3 firmware reads the trusted root key from the CPU of the ARM server based on the trusted root key read message.

[0080]

[0083] In an optional embodiment, in step S222, generating a remote attestation report using the trusted root key and the measurement information includes the following method steps:

[0081]

[0084] Step S2221, deriving the authentication key of the target trusted kernel system according to preset rules;

[0082]

[0085] Step S2222: encrypt the authentication public key in the authentication key using the trusted root private key in the trusted root key to generate an authentication certificate;

[0083]

[0086] Step S2223: Generate a remote attestation report based on the authentication certificate and the verification content signed by the authentication private key in the authentication key.

[0084]

[0087] In the embodiment of the present disclosure, the authentication key may be understood as an AK key, and the authentication certificate may be understood as an AK certificate.

[0085]

[0088] In the disclosed embodiment, when the security module generates a remote attestation report using the trusted root key and measurement information, it can derive the authentication key of the target trusted kernel system according to preset rules, that is, derive the AK key of the target user's TEE OS according to specific rules.

[0086]

[0089] After deriving the AK key of the target user's TEE OS, the authentication public key in the authentication key is encrypted using the trusted root private key in the trusted root key to generate an authentication certificate. That is, the authentication public key in the derived AK key of the target user's TEE OS is encrypted using the trusted root private key in the trusted root key to generate an AK certificate.

[0087]

[0090] Finally, based on the authentication certificate and the verification content signed by the authentication private key in the authentication key, a remote attestation report is generated, that is, based on the AK certificate and the verification content signed by the authentication private key in the AK key, a remote attestation report is generated.

[0088]

[0091] In an optional embodiment, the secure world operating environment is divided into multiple exception levels, including a first exception level and a second exception level. The first exception level is an application exception level, and the second exception level is an operating system exception level. The security component in the cloud server runs at the first exception level or the second exception level. The security component is used to support remote attestation of multiple user trusted kernel systems. The multiple user trusted kernel systems run at the second exception level.

[0092] In the disclosed embodiments, the ARM TrustZone architecture divides the CPU resources of an ARM server into a non-secure world and a secure world. The secure world operating environment is further divided into multiple exception levels (S-ELs). The multiple exception levels include a first exception level, S-ELO, and a second exception level, S-EL1. S-ELO is the application exception level, and S-EL2 is the operating system exception level.

[0089]

[0093] The security module provided by the embodiment of the present disclosure, that is, the security component in the ARM server, can run on S-ELO or S-ELL. The security component is used to support remote attestation of multiple user TEE OSs. Multiple user TEE OSs run on S-ELL.

[0090]

[0094] In an optional embodiment, the multiple exception levels further include: a third exception level, wherein the third exception level is a virtualization exception level, and the virtualization component runs at the third exception level.

[0091]

[0095] In the embodiment of the present disclosure, the multiple exception levels further include a third exception level, namely, a virtualization exception level S-EL2, in which a virtualization component S-EL2 runs.

[0092]

[0096] In an optional embodiment, the multiple exception levels further include: a fourth exception level, wherein the fourth exception level is an underlying trusted firmware exception level, and the trusted firmware in the cloud server runs at the fourth exception level.

[0093]

[0097] In the embodiment of the present disclosure, the multiple exception levels further include a fourth exception level, namely, the bottom trusted firmware exception level S-EL3. The trusted firmware in the ARM server runs at the fourth exception level S-EL3.

[0094]

[0098] FIG3 is a schematic diagram illustrating the division of CPU resources of an ARM server according to Example 1 of the present disclosure. As shown in FIG3 , the ARM TrustZone architecture divides the CPU resources of the ARM server into a non-secure world and a secure world. Within each world, four exception levels are further divided according to the ARM EL, including the ELO, ELI, EL2, and EL3 levels in the non-secure world operating environment, and the S-ELO, S-EL1, S-EL2, and S-EL3 (i.e., EL3) levels in the secure world operating environment.

[0095]

[0099] The EL0 layer supports the deployment of user TAX tools, TEE OS tools, and remote attestation verification libraries. The ELI layer supports REE drivers. The security module supports remote attestation of multiple TEE OSes and can be deployed at the S-EL0 or S-EL1 layer. Figure 3 uses the security module deployed at the S-EL0 layer as an example. The S-EL1 layer supports the deployment of multiple user TEE OSes, such as User TEE OS 1 and User TEE OS 2. The S-EL2 layer is the virtualization component layer for running virtualization software and supports dynamic loading of TEE OSes to provide physical isolation boundaries. EL3 and S-EL3 are the ARM trusted firmware layers, supporting the security module to read the root of trust. The root of trust key is stored in the ARM server's CPU.

[0096]

[0100] As can be seen, this disclosure designs an independent security module that can support the remote attestation process for multiple user TEE OSes. This security module can be deployed at either the S-EL0 or S-EL1 level, relying on underlying firmware and hardware including the virtualization components at the S-EL2 level, the ARM trusted firmware at the EL3 level, and the ARM server CPU hardware.

[0097]

[0101] The virtualization component at the S-EL2 layer provides dynamic TEE OS loading, providing dynamically loaded TEE OS messages to the security module and establishing a physical isolation boundary between multiple TEE OSes and security modules. The ARM trusted firmware at the EL3 layer provides the security module with the ability to read the root of trust key. The ARM server's CPU hardware stores the root of trust key and provides this information to the security module.

[0098]

[0102] FIG4 is a flowchart of outputting a remote attestation report according to Embodiment 1 of the present disclosure. As shown in FIG4 , FIG4 takes the case where the security module is deployed at the S-EL0 level and the user TEE OS 1 is dynamically loaded as an example. Outputting a remote attestation report includes the following steps:

[0099]

[0103] The first step is to deploy the TEE OS tool at the EL0 level in the non-secure world and send a dynamic TEE OS loading instruction to the S-EL2 component in the secure world. This instruction may include the TEE OS image file.

[0100]

[0104] In the second step, the S-EL2 component sends a dynamic loading TEE OS message to the security module deployed at the S-EL0 level.

[0105] In the third step, the security module sends a read root of trust message to the EL3 firmware to obtain the root of trust key stored in the CPU of the ARM server.

[0101]

[0106] In the fourth step, the security module derives the AK of TEE OS 1 according to specific rules and signs it with the trusted root private key to generate an AK certificate.

[0102]

[0107] The fifth step is to deploy the user TA to the user TEE OS 1 at the S-EL1 level in the secure world through the deployment user TA X tool at the EL0 level in the non-secure world.

[0103]

[0108] In the sixth step, user TEE OS 1 sends user TA's measurement information to the security module.

[0104]

[0109] In the seventh step, the security module outputs a remote attestation report, which includes the AK certificate and the report content signed with the AK private key, and sends it to the remote attestation verification library at the EL0 level in the non-secure world.

[0105]

[0110] In addition, the remote attestation verification library is configured with the public key certificate of the trusted root key, which can verify the remote attestation report. The verification steps include the following:

[0106]

[0111] The first step is to verify the AK certificate of user TEE OS 1 using the public key in the trusted root key certificate.

[0107]

[0112] The second step is to use the AK public key in the AK certificate to verify the signature of the remote attestation report content.

[0108]

[0113] The third step is to obtain the measurement information of TEE OS and TA (such as hash value, etc.), and compare it with the expected value to confirm whether it meets the expectations.

[0109]

[0114] It is easy to understand that the beneficial effects of the remote attestation method of the cloud server provided by the present disclosure include the following points.

[0110]

[0115] Beneficial effect (1): An independent security module is provided, and the server is securely started along with the BIOS during power-on, with a high security level.

[0111]

[0116] Beneficial effect (2): The S-EL2 virtualization component provides highly secure physical isolation between the security module and multiple TEE OSes, eliminating the risk of data leakage.

[0112]

[0117] Beneficial effect (3): Only the security module can access the trust root key. Even if a TEE OS is compromised, it will not affect the security of other TEE OS on the server.

[0113]

[0118] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this disclosure are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or refuse.

[0114]

[0119] It should also be noted that, for simplicity of description, the aforementioned method embodiments are described as a series of actions. However, those skilled in the art should understand that the present disclosure is not limited by the order of the actions described, as certain steps may be performed in a different order or simultaneously, according to the present disclosure. Furthermore, those skilled in the art should also understand that the embodiments described in this specification are preferred embodiments, and the actions and modules involved are not necessarily required by the present disclosure.

[0115]

[0120] Through the above description of the embodiments, those skilled in the art will clearly understand that the methods according to the above embodiments can be implemented using software and a necessary general-purpose hardware platform, or of course, hardware. Based on this understanding, the technical solution of the present disclosure, or the portion that contributes to the relevant art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, a magnetic disk, or an optical disk) and includes a number of instructions for enabling a terminal device (such as a mobile phone, a computer, a server, or a network device) to execute the methods described in the various embodiments of the present disclosure. Example 2

[0116]

[0121] In the operating environment of Example 1, the present disclosure provides a remote attestation method for a cloud server as shown in FIG5 . FIG5 is a flowchart of a remote attestation method for a cloud server according to Example 2 of the present disclosure. As shown in FIG5 , the method includes:

[0117]

[0122] Step S51: Sending a loading instruction to a virtualization component in a cloud server. A preset security architecture is deployed in the cloud server. A secure world operating environment and a non-secure world operating environment are created in the preset security architecture. The secure world operating environment runs a virtualization component, which is used to provide physical isolation for multiple user trusted kernel systems. The loading instruction is used to instruct the virtualization component to send a loading message, which is used to determine whether to load a target trusted kernel system from among the multiple user trusted kernel systems.

[0118]

[0123] Step S52: Receive a remote attestation report output by a security component in the cloud server. The security component runs in the secure world operating environment and is configured to support remote attestation of multiple user trusted kernel systems. The remote attestation report is generated based on the load message and is configured to provide verification content for the target trusted kernel system.

[0119]

[0124] Step S53: remotely attest the target trusted kernel system based on the remote attestation report.

[0120]

[0125] In the embodiment of the present disclosure, the load instruction is used to instruct the virtualization component to send a load message, that is, to instruct the S-EL2 component in the secure world to send a load message to the security component (ie, the security module).

[0121]

[0126] Security components, also known as security modules, can be deployed at either the S-ELO or S-EL1 level in the secure world, with no restrictions here. Security components are used to support remote attestation of multiple user TEE OSes.

[0122]

[0127] The rest of the explanations refer to the contents in Example 1 and will not be elaborated here.

[0123]

[0128] In the disclosed embodiments, the execution entity can be the EL0 level in the non-secure world. The EL0 level can send a load instruction to the virtualized component in the cloud server. Specifically, the EL0-level deployment TEE OS tool sends a load instruction to the S-EL2 component in the ARM server, causing the S-EL2 component to send a load message to the secure component. The EL0 level also receives a remote attestation report from the secure component in the cloud server. Specifically, the EL0-level deployment user TA tool receives the remote attestation report from the secure component in the ARM server. Based on the remote attestation report, the target trusted kernel system is remotely attested. Specifically, the EL0-level remote attestation verification library remotely attests the target user TEE OS based on the remote attestation report.

[0124]

[0129] As can be seen, this disclosure designs a security module located in an independent partition within the secure world. The S-EL2 component provides physical isolation between this security module and multiple TEE operating systems, thereby ensuring the security of the security module's access to the root of trust key. Furthermore, the remote attestation process for multiple TEE operating systems in this disclosure is implemented through communication with the security module, meaning that only the security module can access the root of trust key. Therefore, even if one TEE operating system is compromised, the security of other TEE operating systems on the server is not affected, resulting in extremely high security.

[0125]

[0130] The remote attestation method of the cloud server provided in the embodiments of the present disclosure can be applied to, but is not limited to, application scenarios involving remote attestation in the fields of e-commerce services, educational services, legal services, medical services, conference services, social network services, financial product services, logistics services, and navigation services, for example: remote attestation of a user or entity in e-commerce services, remote attestation of a user or entity in educational services, remote attestation of a user or entity in medical services, etc., which are not limited here.

[0126]

[0131] According to the disclosed embodiments, a load instruction is sent to the virtualized component in the cloud server. Specifically, the EL0-level TEE OS deployment tool sends the load instruction to the S-EL2 component on the ARM server, causing the S-EL2 component to send a load message to the security component. A remote attestation report is then received from the security component in the cloud server. Specifically, the EL0-level user TA tool receives the remote attestation report from the security component on the ARM server. Finally, the target trusted kernel system is remotely attested based on the remote attestation report. Specifically, the EL0-level remote attestation verification library remotely attests the target user TEE OS based on the remote attestation report. This achieves the goal of providing security services for remote attestation of each TEE OS through an independent security module, thereby providing a standard remote attestation solution for TEEs based on ARM TrustZone technology and effectively ensuring the security of the security module's access to the trusted root key. This addresses the technical problem of the lack of a solution supporting remote attestation of multiple trusted execution environment operating systems on advanced RISC servers.

[0127]

[0132] In an optional embodiment, the information carried in the loading instruction includes: an image file, where the image file is used to determine the target trusted kernel system.

[0128]

[0133] In the embodiment of the present disclosure, the loading instruction sent by the ELO layer to the S-EL2 component of the ARM server may include an image file, that is, an image file of the TEE OS, which is used to determine the target user TEE OS.

[0129]

[0134] In an optional embodiment, the remote attestation method of the cloud server further includes the following method steps:

[0130]

[0135] Step S54: deploy the trusted application to the target trusted kernel system.

[0131]

[0136] In the disclosed embodiment, after remote attestation of the target user's TEE OS, the TA can also be deployed to the target user's TEE OS through the EL0-level deployment user TA tool in the non-secure world, that is, the user TA is deployed on a real and trusted hardware TEE platform.

[0132]

[0137] In an optional embodiment, in step S53, remote attestation is performed on the target trusted kernel system based on the remote attestation report, including the following method steps:

[0133]

[0138] Step S531, decrypt the authentication certificate using the pre-stored trusted root public key to obtain the authentication public key;

[0134]

[0139] Step S532: decrypt the verification content signed by the authentication private key according to the authentication public key to obtain a first summary of the verification content;

[0135]

[0140] Step S533, generating a second summary based on the verification content;

[0136]

[0141] Step S534: remotely attest the target trusted kernel system using the comparison result between the first digest and the second digest.

[0137]

[0142] In the disclosed embodiment, when remotely attesting a target trusted kernel system based on a remote attestation report, the EL0-level remote attestation verification library can use a pre-stored trusted root public key to decrypt the authentication certificate to obtain the authentication public key. Specifically, the library decrypts the AK certificate using the pre-stored trusted root public key, verifies the target user's TEE OS's AK certificate, and obtains the AK public key. The verification content signed by the authentication private key is then decrypted based on the authentication public key to obtain a first digest of the verification content. Specifically, the library uses the AK public key in the AK certificate to verify the signature of the remote attestation report content and obtains measurement information of the TEE OS and the user, such as a hash value. A second digest is then generated based on the verification content, namely, an expected value of the measurement information. Finally, the target trusted kernel system is remotely attested using the comparison result between the first and second digests. Specifically, the obtained TEE OS and user measurement information is compared with the expected value to confirm whether it meets expectations.

[0138]

[0143] It should be noted that the preferred implementation of this embodiment can refer to the relevant description in Example 1, which will not be repeated here.

[0139]

[0144] In the operating environment of Example 1, the present disclosure provides a remote attestation method for a cloud server as shown in FIG6 . FIG6 is a flow chart of a remote attestation method for a cloud server according to Example 3 of the present disclosure. As shown in FIG6 , the method includes:

[0140]

[0145] Step S61: receiving a loading instruction from a trusted kernel system deployment component in a cloud server, wherein a preset security architecture is deployed in the cloud server, a secure world operating environment and a non-secure world operating environment are created on the preset security architecture, and the trusted kernel system deployment component runs in the non-secure world operating environment. The trusted kernel system deployment component is used to deploy multiple user trusted kernel systems in the secure world operating environment.

[0141]

[0146] In step S62, a loading message is sent to the security component in the cloud server based on the loading instruction, so that the security component outputs a remote attestation report to the remote attestation verification component, wherein the loading message is used to determine the loading of the target trusted kernel system from multiple user trusted kernel systems, a security component is running in the secure world operating environment, the security component is used to support remote attestation of multiple user trusted kernel systems, a remote attestation verification component is running in the non-secure world operating environment, the remote attestation verification component is used to remotely attest the target trusted kernel system based on the remote attestation report, and the remote attestation report is used to provide verification content of the target trusted kernel system, so that the remote attestation verification component remotely attests the target trusted kernel system based on the remote attestation report.

[0142]

[0147] In the disclosed embodiments, the trusted kernel system deployment component can be understood as a TEE OS deployment tool at the ELO level in the non-secure world. The trusted kernel system deployment component runs in the non-secure world operating environment. The trusted kernel system deployment component is used to deploy multiple user trusted kernel systems in the secure world operating environment.

[0143]

[0148] The rest of the explanations refer to the contents in Example 1 and will not be elaborated here.

[0144]

[0149] In the disclosed embodiment, the execution entity may be a virtualization component at the S-EL2 layer in the secure world. The virtualization component at the S-EL2 layer may receive a load instruction from a trusted kernel system deployment component in the cloud server. Specifically, the virtualization component at the S-EL2 layer may receive a load instruction issued by a deployment TEE OS tool at the EL0 layer in the non-secure world. Based on the load instruction, the virtualization component at the S-EL2 layer may send a load message to the secure component in the cloud server, causing the secure component to output a remote attestation report to the remote attestation verification component. Specifically, based on the load instruction, the virtualization component at the S-EL2 layer may send a load message to the secure component (i.e., security module) in the secure world, causing the secure component to output a remote attestation report to the remote attestation verification library at the EL0 layer.

[0145]

[0150] As can be seen, this disclosure designs a security module located in an independent partition within the secure world. The S-EL2 component provides physical isolation between this security module and multiple TEE operating systems, thereby ensuring the security of the security module's access to the root of trust key. Furthermore, the remote attestation process for multiple TEE operating systems in this disclosure is implemented through communication with the security module, meaning that only the security module can access the root of trust key. Therefore, even if one TEE operating system is compromised, the security of other TEE operating systems on the server is not affected, resulting in extremely high security.

[0146]

[0151] The remote attestation method of the cloud server provided in the embodiments of the present disclosure can be applied to, but is not limited to, application scenarios involving remote attestation in the fields of e-commerce services, educational services, legal services, medical services, conference services, social network services, financial product services, logistics services, and navigation services, for example: remote attestation of a user or entity in e-commerce services, remote attestation of a user or entity in educational services, remote attestation of a user or entity in medical services, etc., which are not limited here.

[0147]

[0152] According to the disclosed embodiments, the S-EL2 layer virtualization component receives a load instruction from the trusted kernel system deployment component in the cloud server. Specifically, the S-EL2 layer virtualization component can receive the load instruction issued by the EL0 layer deployment TEE OS tool in the non-secure world. Based on the load instruction, the S-EL2 layer virtualization component sends a load message to the security component in the cloud server, causing the security component to output a remote attestation report to the remote attestation verification component. Specifically, based on the load instruction, the S-EL2 layer virtualization component sends a load message to the security component (i.e., security module) in the secure world, causing the security component to output a remote attestation report to the EL0 layer remote attestation verification library. This achieves the goal of providing security services for remote attestation of each TEE OS through an independent security module, thereby providing a standard remote attestation solution for TEEs based on ARM TrustZone technology and effectively ensuring the security of the security module's access to the root of trust key. This further addresses the technical problem of the lack of a solution supporting remote attestation of multiple trusted execution environment operating systems on advanced reduced instruction set computer servers in the related art.

[0148]

[0153] It should be noted that the preferred implementation of this embodiment can refer to the relevant description in Example 1, which will not be repeated here.

[0149]

[0154] In the operating environment of Example 1, the present disclosure provides a cloud server in which a preset security architecture is deployed. A secure world operating environment and a non-secure world operating environment are created on the preset security architecture. The secure world operating environment runs security components and virtualization components, and the non-secure world operating environment runs a trusted kernel system deployment component and a remote attestation verification component.

[0150]

[0155] a security component configured to receive a load message from the virtualization component, generate a remote attestation report based on the load message, and output the remote attestation report to the remote attestation verification component, wherein the load message is used to determine whether to load a target trusted kernel system from multiple user trusted kernel systems, and the remote attestation report is used to provide verification content for the target trusted kernel system;

[0151]

[0156] A trusted kernel system deployment component is used to send a loading instruction to the virtualization component, wherein the loading instruction is used to instruct the virtualization component to send a loading message;

[0152]

[0157] A remote attestation verification component, configured to receive a remote attestation report output by the security component and remotely attest the target trusted kernel system based on the remote attestation report;

[0153]

[0158] The virtualization component is configured to receive a loading instruction from the remote attestation verification component and send a loading message to the security component based on the loading instruction.

[0154]

[0159] As shown in Figure 3, an embodiment of the present disclosure provides a cloud server (i.e., an ARM server). The pre-defined security architecture (i.e., the ARM TrustZone architecture) in the cloud server divides the cloud server into a secure world operating environment and a non-secure world operating environment. The secure world operating environment runs security components (i.e., security modules) and virtualization components (i.e., S-EL2 components), while the non-secure world operating environment runs a trusted kernel system deployment component (i.e., an ELO-level TEE OS deployment tool) and a remote attestation verification component (i.e., an EL0-level remote attestation verification library).

[0155]

[0160] The security component is configured to receive a load message from the virtualization component, generate a remote attestation report based on the load message, and output the remote attestation report to the remote attestation verification component. The trusted kernel system deployment component is configured to send a load instruction to the virtualization component. The remote attestation verification component is configured to receive the remote attestation report output by the security component and remotely attest the target trusted kernel system based on the remote attestation report. The virtualization component is configured to receive a load instruction from the remote attestation verification component and, based on the load instruction, send a load message to the security component.

[0156]

[0161] The rest of the explanations refer to the contents in Example 1 and will not be elaborated here.

[0157]

[0162] As can be seen, this disclosure designs a security module located in an independent partition within the secure world. The S-EL2 component provides physical isolation between this security module and multiple TEE operating systems, thereby ensuring the security of the security module's access to the root of trust key. Furthermore, the remote attestation process for multiple TEE operating systems in this disclosure is implemented through communication with the security module, meaning that only the security module can access the root of trust key. Therefore, even if one TEE operating system is compromised, the security of other TEE operating systems on the server is not affected, resulting in extremely high security.

[0158]

[0163] It should be noted that the preferred implementation of this embodiment can refer to the relevant description in Example 1, which will not be repeated here.

[0159]

[0164] According to an embodiment of the present disclosure, an embodiment of a device for implementing the aforementioned remote attestation method for a cloud server is also provided. FIG7 is a schematic structural diagram of a remote attestation device for a cloud server according to Embodiment 5 of the present disclosure. As shown in FIG7 , the device includes:

[0160]

[0165] A first receiving module 701 is configured to receive a loading message from a virtualization component in a cloud server. A preset security architecture is deployed in the cloud server. A secure world operating environment and a non-secure world operating environment are created in the preset security architecture. The secure world operating environment runs a virtualization component, which is configured to provide physical isolation for multiple user trusted kernel systems. The loading message is configured to determine a target trusted kernel system to load from among the multiple user trusted kernel systems.

[0161]

[0166] A generating module 702 is configured to generate a remote attestation report based on the loading message, wherein the remote attestation report is configured to provide verification content of a target trusted kernel system;

[0162]

[0167] The output module 703 is used to output the remote attestation report to the remote attestation verification component in the cloud server, wherein the remote attestation verification component runs in the non-secure world operating environment and is used to remotely attest the target trusted kernel system based on the remote attestation report.

[0168] Optionally, the generation module 702 is further configured to: obtain a trusted root key stored in a processor of the cloud server based on the loading message, and obtain measurement information of a trusted application running in the target trusted kernel system; and generate a remote attestation report using the trusted root key and the measurement information.

[0163]

[0169] Optionally, the generation module 702 is further configured to send a trusted root key read message to the trusted firmware in the cloud server based on the load message, so that the trusted firmware reads the trusted root key from the processor of the cloud server based on the trusted root key read message, wherein the trusted firmware runs in the secure world operating environment, and the trusted firmware is configured to provide a trusted root key read function.

[0164]

[0170] Optionally, the generation module 702 is further configured to: derive an authentication key for a target trusted kernel system according to preset rules; encrypt an authentication public key in the authentication key using a trusted root private key in the trusted root key to generate an authentication certificate; and generate a remote attestation report based on the authentication certificate and verification content signed using the authentication private key in the authentication key.

[0165]

[0171] Optionally, the secure world operating environment is divided into multiple exception levels, including a first exception level and a second exception level, wherein the first exception level is an application exception level, and the second exception level is an operating system exception level. The security component in the cloud server runs at the first exception level or the second exception level, and the security component is used to support remote attestation of multiple user trusted kernel systems. The multiple user trusted kernel systems run at the second exception level.

[0166]

[0172] Optionally, the multiple exception levels further include: a third exception level, wherein the third exception level is a virtualization exception level, and the virtualization component runs at the third exception level.

[0167]

[0173] Optionally, the multiple exception levels further include: a fourth exception level, wherein the fourth exception level is an underlying trusted firmware exception level, and the trusted firmware in the cloud server runs at the fourth exception level.

[0168]

[0174] According to an embodiment of the present disclosure, a loading message is received from a virtualization component in a cloud server, that is, a loading message is received from an S-EL2 component in an ARM server. A preset security architecture is deployed in the cloud server, a secure world operating environment and a non-secure world operating environment are created on the preset security architecture, and an S-EL2 component for providing physical isolation for multiple user trusted kernel systems runs in the secure world operating environment. The loading message is used to determine the target trusted kernel system to be loaded from the multiple user trusted kernel systems, that is, to determine the target user TEE OS from the multiple user TEE OSes. Then, based on the loaded message, a remote attestation report is generated to provide verification content of the target trusted kernel system, and the remote attestation report is output to the remote attestation verification component running in the non-secure world operating environment in the cloud server, so that the remote attestation verification component can remotely attest the target trusted kernel system based on the remote attestation report. In this way, the purpose of providing security services for remote attestation of each TEE OS through an independent security module is achieved, thereby providing a standard remote attestation solution for TEE based on ARM TrustZone technology and effectively ensuring the security of the security module's access to the trusted root key. This solves the technical problem in the related art of the lack of a solution that supports remote attestation of multiple trusted execution environment operating systems on advanced reduced instruction set computer servers.

[0169]

[0175] It should be noted that the first receiving module 701, generating module 702, and output module 703 correspond to steps S21 to S23 in Example 1. The examples and application scenarios implemented by these three modules and the corresponding steps are the same, but are not limited to the contents disclosed in Example 1. It should be noted that the above modules or units may be hardware components or software components stored in a memory (e.g., memory 104) and processed by one or more processors (e.g., processors 102a, 102b, ..., 102n). The above modules may also be part of an apparatus and run in the computer terminal 10 provided in Example 1.

[0170]

[0176] According to an embodiment of the present disclosure, another embodiment of a device for implementing the aforementioned remote attestation method for a cloud server is also provided. FIG8 is a schematic structural diagram of another remote attestation device for a cloud server according to Embodiment 5 of the present disclosure. As shown in FIG8 , the device includes:

[0171]

[0177] A first sending module 801 is configured to send a loading instruction to a virtualization component in a cloud server. A preset security architecture is deployed in the cloud server. A secure world operating environment and a non-secure world operating environment are created in the preset security architecture. The secure world operating environment runs a virtualization component. The virtualization component is configured to provide physical isolation for multiple user trusted kernel systems. The loading instruction is configured to instruct the virtualization component to send a loading message. The loading message is configured to determine whether to load a target trusted kernel system from among the multiple user trusted kernel systems.

[0172]

[0178] A second receiving module 802 is configured to receive a remote attestation report output by a security component in a cloud server, wherein the security component runs in a secure world operating environment and is configured to support remote attestation of multiple user trusted kernel systems. The remote attestation report is generated based on the load message and is configured to provide verification content for a target trusted kernel system.

[0173]

[0179] The attestation module 803 is configured to remotely attest the target trusted kernel system based on the remote attestation report.

[0174]

[0180] Optionally, the information carried in the loading instruction includes: an image file, where the image file is used to determine the target trusted kernel system.

[0175]

[0181] Optionally, the device further includes: a deployment module, configured to deploy the trusted application to a target trusted kernel system.

[0176]

[0182] Optionally, the attestation module 803 is further configured to: decrypt the authentication certificate using a pre-stored trusted root public key to obtain an authentication public key; decrypt the verification content signed by the authentication private key based on the authentication public key verification to obtain a first summary of the verification content; generate a second summary based on the verification content; and remotely attest the target trusted kernel system using a comparison result between the first summary and the second summary.

[0177]

[0183] According to the disclosed embodiments, a load instruction is sent to the virtualized component in the cloud server. Specifically, the ELO-level deployment TEE OS tool sends the load instruction to the S-EL2 component of the ARM server, causing the S-EL2 component to send a load message to the security component. A remote attestation report is then received from the security component in the cloud server. Specifically, the EL0-level deployment user TA tool receives the remote attestation report from the security component in the ARM server. Finally, based on the remote attestation report, the target trusted kernel system is remotely attested. Specifically, the EL0-level remote attestation verification library remotely attests the target user TEE OS based on the remote attestation report. This achieves the goal of providing security services for remote attestation of each TEE OS through an independent security module, thereby providing a standard remote attestation solution for TEEs based on ARM TrustZone technology and effectively ensuring the security of the security module's access to the trusted root key. This addresses the technical problem of the lack of a solution supporting remote attestation of multiple trusted execution environment operating systems on advanced RISC servers.

[0178]

[0184] It should be noted that the first sending module 801, the second receiving module 802, and the certification module 803 correspond to steps S51 to S53 in Example 2. The examples and application scenarios implemented by these three modules and the corresponding steps are the same, but are not limited to the contents disclosed in Example 1. It should be noted that the above modules or units may be hardware components or software components stored in a memory (e.g., memory 104) and processed by one or more processors (e.g., processors 102a, 102b, 102n). The above modules may also be part of an apparatus and run in the computer terminal 10 provided in Example 1.

[0179]

[0185] According to an embodiment of the present disclosure, another embodiment of a device for implementing the aforementioned remote attestation method for a cloud server is also provided. FIG9 is a schematic structural diagram of another remote attestation device for a cloud server according to Embodiment 5 of the present disclosure. As shown in FIG9 , the device includes:

[0180]

[0186] A third receiving module 901 is configured to receive a loading instruction from a trusted kernel system deployment component in a cloud server. A preset security architecture is deployed in the cloud server. A secure world operating environment and a non-secure world operating environment are created on the preset security architecture. The trusted kernel system deployment component runs in the non-secure world operating environment. The trusted kernel system deployment component is configured to deploy multiple user trusted kernel systems in the secure world operating environment.

[0181]

[0187] The second sending module 902 is configured to send a loading message to the security component in the cloud server based on the loading instruction, so that the security component outputs a remote attestation report to the remote attestation verification component, wherein the loading message is used to determine the loading of a target trusted kernel system from multiple user trusted kernel systems. A security component is running in the secure world operating environment, and the security component is used to support remote attestation of multiple user trusted kernel systems. A remote attestation verification component is running in the non-secure world operating environment, and the remote attestation verification component is used to remotely attest the target trusted kernel system based on the remote attestation report. The remote attestation report is used to provide verification content of the target trusted kernel system, so that the remote attestation verification component remotely attests the target trusted kernel system based on the remote attestation report.

[0182]

[0188] According to the disclosed embodiments, the S-EL2 layer virtualization component receives a load instruction from the trusted kernel system deployment component in the cloud server. Specifically, the S-EL2 layer virtualization component can receive the load instruction issued by the ELO layer deployment TEE OS tool in the non-secure world. Based on the load instruction, the S-EL2 layer virtualization component sends a load message to the security component in the cloud server, causing the security component to output a remote attestation report to the remote attestation verification component. Specifically, based on the load instruction, the S-EL2 layer virtualization component sends a load message to the security component (i.e., security module) in the secure world, causing the security component to output a remote attestation report to the EL0 layer remote attestation verification library. This achieves the goal of providing security services for remote attestation of each TEE OS through an independent security module, thereby providing a standard remote attestation solution for TEEs based on ARM TrustZone technology and effectively ensuring the security of the security module's access to the root of trust key. This further addresses the technical problem of the lack of a solution supporting remote attestation of multiple trusted execution environment operating systems on advanced reduced instruction set computer servers in the related art.

[0183]

[0189] It should be noted that the third receiving module 901 and the second sending module 902 correspond to steps S61 and S62 in Example 3. The examples and application scenarios implemented by the two modules and the corresponding steps are the same, but are not limited to the contents disclosed in Example 1. It should be noted that the above modules or units can be stored in a memory.

[0184] A hardware component or software component in (e.g., memory 104) and processed by one or more processors (e.g., processors 102a, 102b, ..., 102n), the above module can also be run as part of the device in the computer terminal 10 provided in Example 1.

[0185]

[0190] It should be noted that the preferred implementation scheme involved in the above embodiments of the present disclosure is the same as the solution provided in Example 1, as well as the application scenario and implementation process, but is not limited to the solution provided in Example 1. Example 6

[0186]

[0191] The embodiments of the present disclosure may provide a computer terminal, which may be any computer terminal device in a computer terminal group. Optionally, in this embodiment, the computer terminal may be replaced by a terminal device such as a mobile terminal.

[0187]

[0192] Optionally, in this embodiment, the computer terminal may be located in at least one network device among multiple network devices of the computer network.

[0188]

[0193] In this embodiment, the computer terminal may execute the program code of the following steps in the remote attestation method of the cloud server: receiving a loading message from a virtualization component in the cloud server, wherein a preset security architecture is deployed in the cloud server, a secure world operating environment and a non-secure world operating environment are created on the preset security architecture, the secure world operating environment runs a virtualization component, the virtualization component is used to provide physical isolation for multiple user trusted kernel systems, the loading message is used to determine to load a target trusted kernel system from the multiple user trusted kernel systems; generating a remote attestation report based on the loading message, wherein the remote attestation report is used to provide verification content of the target trusted kernel system; and outputting the remote attestation report to a remote attestation verification component in the cloud server, wherein a remote attestation verification component is run in the non-secure world operating environment, and the remote attestation verification component is used to remotely attest the target trusted kernel system based on the remote attestation report.

[0189]

[0194] Optionally, FIG10 is a block diagram of a computer terminal according to an embodiment of the present disclosure. As shown in FIG10 , the computer terminal A may include one or more processors 1002 (only one is shown), a memory 1004, a storage controller, and a peripheral interface. The peripheral interface is connected to a radio frequency module, an audio module, and a display.

[0190]

[0195] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the remote attestation method and apparatus for a cloud server in the embodiments of the present disclosure. The processor executes the stored software programs and modules to perform various functional applications and data processing, thereby implementing the aforementioned remote attestation method for a cloud server. The memory can include high-speed random access memory (RAM) and non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory can further include memory located remotely from the processor, and such remote memory can be connected to the computer terminal A via a network. Examples of such networks include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0191]

[0196] The processor can call the information and application stored in the memory through the transmission device to perform the following steps: obtain the trust root key stored in the processor of the cloud server based on the loading message, and obtain the measurement information of the trusted application running in the target trusted kernel system; and generate a remote attestation report using the trust root key and the measurement information.

[0192]

[0197] Optionally, the processor may further execute program code of the following steps: sending a trusted root key read message to the trusted firmware in the cloud server based on the load message, so that the trusted firmware reads the trusted root key from the processor of the cloud server based on the trusted root key read message, wherein the trusted firmware runs in the secure world operating environment, and the trusted firmware is used to provide a trusted root key reading function.

[0193]

[0198] Optionally, the processor may further execute program code for the following steps: deriving an authentication key of a target trusted kernel system according to preset rules; encrypting an authentication public key in the authentication key using a trusted root private key in a trusted root key to generate an authentication certificate; and generating a remote attestation report based on the authentication certificate and verification content signed using the authentication private key in the authentication key.

[0194]

[0199] Optionally, the secure world operating environment is divided into multiple exception levels, including a first exception level and a second exception level, wherein the first exception level is an application exception level, and the second exception level is an operating system exception level. The security component in the cloud server runs at the first exception level or the second exception level, and the security component is used to support remote attestation of multiple user trusted kernel systems. The multiple user trusted kernel systems run at the second exception level.

[0195]

[0200] Optionally, the multiple exception levels further include: a third exception level, wherein the third exception level is a virtualization exception level, and the virtualization component runs at the third exception level.

[0196]

[0201] Optionally, the multiple exception levels further include: a fourth exception level, wherein the fourth exception level is an underlying trusted firmware exception level, and the trusted firmware in the cloud server runs at the fourth exception level.

[0197]

[0202] According to an embodiment of the present disclosure, a loading message is received from a virtualization component in a cloud server, that is, a loading message is received from an S-EL2 component in an ARM server. A preset security architecture is deployed in the cloud server, a secure world operating environment and a non-secure world operating environment are created on the preset security architecture, and an S-EL2 component for providing physical isolation for multiple user trusted kernel systems runs in the secure world operating environment. The loading message is used to determine the target trusted kernel system to be loaded from the multiple user trusted kernel systems, that is, to determine the target user TEE OS from the multiple user TEE OSes. Then, based on the loaded message, a remote attestation report is generated to provide verification content of the target trusted kernel system, and the remote attestation report is output to the remote attestation verification component running in the non-secure world operating environment in the cloud server, so that the remote attestation verification component can remotely attest the target trusted kernel system based on the remote attestation report. In this way, the purpose of providing security services for remote attestation of each TEE OS through an independent security module is achieved, thereby providing a standard remote attestation solution for TEE based on ARM TrustZone technology and effectively ensuring the security of the security module's access to the trusted root key. This solves the technical problem in the related art of the lack of a solution that supports remote attestation of multiple trusted execution environment operating systems on advanced reduced instruction set computer servers.

[0198]

[0203] Those skilled in the art will appreciate that the structure shown in FIG10 is merely illustrative. Computer terminal A may also be a smartphone (e.g., an Android phone, an iOS phone, etc.), a tablet computer, a PDA, a mobile internet device (MID), a PAD, or other terminal device. FIG10 does not limit the structure of these electronic devices. For example, computer terminal A may include more or fewer components (e.g., a network interface, a display device, etc.) than shown in FIG10 , or may have a configuration different from that shown in FIG10 .

[0199]

[0204] Those skilled in the art will appreciate that all or part of the steps in the various methods of the above embodiments can be completed by instructing the hardware of the terminal device through a program. The program can be stored in a computer-readable storage medium. The storage medium may include a flash drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk. Example 7

[0200]

[0205] The embodiments of the present disclosure further provide a computer-readable storage medium. Optionally, in this embodiment, the computer-readable storage medium may be used to store program code executed by the remote attestation method of the cloud server provided in the first embodiment.

[0201]

[0206] Optionally, in this embodiment, the computer-readable storage medium may be located in any computer terminal in a computer terminal group in a computer network, or in any mobile terminal in a mobile terminal group.

[0202]

[0207] Optionally, in this embodiment, the computer-readable storage medium is configured to store program code for executing the following steps: receiving a loading message from a virtualization component in a cloud server, wherein a preset security architecture is deployed in the cloud server, a secure world operating environment and a non-secure world operating environment are created on the preset security architecture, the secure world operating environment runs a virtualization component, the virtualization component is used to provide physical isolation for multiple user trusted kernel systems, and the loading message is used to determine to load a target trusted kernel system from the multiple user trusted kernel systems; generating a remote attestation report based on the loading message, wherein the remote attestation report is used to provide verification content of the target trusted kernel system; and outputting the remote attestation report to a remote attestation verification component in the cloud server, wherein a remote attestation verification component is run in the non-secure world operating environment, and the remote attestation verification component is used to remotely attest the target trusted kernel system based on the remote attestation report.

[0203]

[0208] Optionally, in this embodiment, the computer-readable storage medium is configured to store program code for executing the following steps: obtaining a trust root key stored in a processor of the cloud server based on a loading message, and obtaining measurement information of a trusted application running in a target trusted kernel system; and generating a remote attestation report using the trust root key and the measurement information.

[0204]

[0209] Optionally, in this embodiment, the computer-readable storage medium is configured to store program code for executing the following steps: sending a trusted root key read message to the trusted firmware in the cloud server based on the load message, so that the trusted firmware reads the trusted root key from the processor of the cloud server based on the trusted root key read message, wherein the trusted firmware runs in the secure world operating environment, and the trusted firmware is used to provide a trusted root key reading function.

[0205]

[0210] Optionally, in this embodiment, the computer-readable storage medium is configured to store program code for executing the following steps: deriving an authentication key of a target trusted kernel system according to preset rules; encrypting an authentication public key in the authentication key using a trusted root private key in a trusted root key to generate an authentication certificate; and generating a remote attestation report based on the authentication certificate and verification content signed using the authentication private key in the authentication key.

[0206]

[0211] Optionally, the secure world operating environment is divided into multiple exception levels, including a first exception level and a second exception level, wherein the first exception level is an application exception level, and the second exception level is an operating system exception level. The security component in the cloud server runs at the first exception level or the second exception level, and the security component is used to support remote attestation of multiple user trusted kernel systems. The multiple user trusted kernel systems run at the second exception level.

[0207]

[0212] Optionally, the multiple exception levels further include: a third exception level, wherein the third exception level is a virtualization exception level, and the virtualization component runs at the third exception level.

[0208]

[0213] Optionally, the multiple exception levels further include: a fourth exception level, wherein the fourth exception level is an underlying trusted firmware exception level, and the trusted firmware in the cloud server runs at the fourth exception level.

[0209]

[0214] An embodiment of the present disclosure further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, it implements any one of the above-mentioned remote attestation methods for the cloud server.

[0210]

[0215] The serial numbers of the above embodiments of the present disclosure are for description only and do not represent the advantages or disadvantages of the embodiments.

[0216] In the above embodiments of the present disclosure, the descriptions of the various embodiments are given with emphasis. For parts not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0211]

[0217] In the several embodiments provided in this disclosure, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is merely a logical functional division. In actual implementation, other divisions may be employed. For example, multiple units or components may be combined or integrated into another system, or some features may be omitted or not implemented. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through interfaces, or indirect coupling or communication connection between units or modules, and may be electrical or otherwise.

[0212]

[0218] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0213]

[0219] In addition, the functional units in the various embodiments of the present disclosure may be integrated into a single processing unit, each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0214]

[0220] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present disclosure, or the portion that contributes to the relevant art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes instructions for causing a computer device (such as a personal computer, server, or network device) to execute all or part of the steps of the method described in various embodiments of the present disclosure. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), a mobile hard drive, a magnetic disk, or an optical disk.

[0215]

[0221] The above description is only a preferred embodiment of the present disclosure. It should be noted that a person skilled in the art can make several improvements and modifications without departing from the principles of the present disclosure. Such improvements and modifications should also be considered within the scope of protection of the present disclosure.

Claims

Claims 1. A remote attestation method for a cloud server, comprising: Receiving a loading message from a virtualization component in a cloud server, wherein a preset security architecture is deployed in the cloud server, a secure world operating environment and a non-secure world operating environment are created on the preset security architecture, the virtualization component is running in the secure world operating environment, the virtualization component is used to provide physical isolation for multiple user trusted kernel systems, and the loading message is used to determine to load a target trusted kernel system from the multiple user trusted kernel systems; generating a remote attestation report based on the loading message, wherein the remote attestation report is used to provide verification content of the target trusted kernel system; outputting the remote attestation report to a remote attestation verification component in the cloud server, wherein the remote attestation verification component is running in the non-secure world operating environment, and the remote attestation verification component is used to remotely attest the target trusted kernel system based on the remote attestation report.

2. The remote attestation method of a cloud server according to claim 1, wherein: Generating the remote attestation report based on the loading message includes: obtaining a trusted root key stored in the processor of the cloud server based on the loading message, and obtaining measurement information of the trusted application running in the target trusted kernel system; and generating the remote attestation report using the trusted root key and the measurement information.

3. The remote attestation method of a cloud server according to claim 2, wherein: Obtaining the trusted root key stored in the processor of the cloud server based on the load message includes: sending a trusted root key read message to trusted firmware in the cloud server based on the load message, so that the trusted firmware reads the trusted root key from the processor of the cloud server based on the trusted root key read message, wherein the trusted firmware runs in the secure world operating environment and is configured to provide a trusted root key read function.

4. The remote attestation method of a cloud server according to claim 2, wherein: Generating the remote attestation report using the trusted root key and the measurement information includes: deriving the authentication key of the target trusted kernel system according to preset rules; encrypting the authentication public key in the authentication key using the trusted root private key in the trusted root key to generate an authentication certificate; and generating the remote attestation report based on the authentication certificate and the verification content signed using the authentication private key in the authentication key.

5. The remote attestation method of a cloud server according to claim 1, wherein: The secure world operating environment is divided into multiple exception levels, and the multiple exception levels include: a first exception level and a second exception level, wherein the first exception level is an application exception level, and the second exception level is an operating system exception level. The security component in the cloud server runs at the first exception level or the second exception level, and the security component is used to support remote attestation of the multiple user trusted kernel systems, and the multiple user trusted kernel systems run at the second exception level.

6. The remote attestation method of a cloud server according to claim 5, wherein: The multiple exception levels further include: a third exception level, wherein the third exception level is a virtualization exception level, and the virtualization component runs at the third exception level.

7. The remote attestation method of a cloud server according to claim 5, wherein: The multiple exception levels also include: a fourth exception level, wherein the fourth exception level is an underlying trusted firmware exception level, and the trusted firmware in the cloud server runs at the fourth exception level.

8. A remote attestation method for a cloud server, comprising: Send a loading instruction to the virtualization component in the cloud server, wherein the cloud server is deployed with a preset security architecture, a secure world operating environment and a non-secure world operating environment are created on the preset security architecture, the virtualization component is run in the secure world operating environment, and the virtualization component is used to provide multiple user trusted kernel systems. The system comprises: a virtualization component and a security component, wherein the security component is configured to provide physical isolation, the loading instruction is configured to instruct the virtualization component to send a loading message, the loading message is configured to determine that a target trusted kernel system is loaded from the multiple user trusted kernel systems; a remote attestation report is output by a security component in the cloud server, wherein the security component is running in the secure world operating environment, the security component is configured to support remote attestation of the multiple user trusted kernel systems, the remote attestation report is generated based on the loading message, the remote attestation report is configured to provide verification content of the target trusted kernel system; and remote attestation is performed on the target trusted kernel system based on the remote attestation report.

9. The remote attestation method of the cloud server according to claim 8, wherein: The information carried in the loading instruction includes: an image file, and the image file is used to determine the target trusted kernel system.

10. The remote attestation method for a cloud server according to claim 8, further comprising: Deploy the trusted application to the target trusted kernel system.

11. The remote attestation method of a cloud server according to claim 8, wherein: Remotely certifying the target trusted kernel system based on the remote attestation report includes: decrypting the authentication certificate using a pre-stored trusted root public key to obtain an authentication public key; decrypting the verification content signed by the authentication private key based on the authentication public key verification to obtain a first summary of the verification content; generating a second summary based on the verification content; and remotely certifying the target trusted kernel system using a comparison result between the first summary and the second summary.

12. A remote attestation method for a cloud server, comprising: The method includes receiving a load instruction from a trusted kernel system deployment component in a cloud server, wherein a preset security architecture is deployed in the cloud server, a secure world operating environment and a non-secure world operating environment are created on the preset security architecture, the trusted kernel system deployment component is running in the non-secure world operating environment, and the trusted kernel system deployment component is configured to deploy multiple user trusted kernel systems in the secure world operating environment; and sending a load message to a security component in the cloud server based on the load instruction, so that the security component outputs a remote attestation report to a remote attestation verification component, wherein the load message is configured to determine that a target trusted kernel system is to be loaded from the multiple user trusted kernel systems, the security component is running in the secure world operating environment, the security component is configured to support remote attestation of the multiple user trusted kernel systems, the remote attestation verification component is running in the non-secure world operating environment, the remote attestation verification component is configured to remotely attest the target trusted kernel system based on the remote attestation report, and the remote attestation report is configured to provide verification content of the target trusted kernel system, so that the remote attestation verification component remotely attests the target trusted kernel system based on the remote attestation report.

13. A cloud server, wherein a preset security architecture is deployed in the cloud server, a secure world operating environment and a non-secure world operating environment are created on the preset security architecture, a security component and a virtualization component are run in the secure world operating environment, and a trusted kernel system deployment component and a remote attestation verification component are run in the non-secure world operating environment; the security component is configured to receive a load message from the virtualization component, generate a remote attestation report based on the load message, and output the remote attestation report to the remote attestation verification component, wherein: The loading message is used to determine the loading of a target trusted kernel system from a plurality of user trusted kernel systems, and the remote attestation report is used to provide verification content of the target trusted kernel system; The trusted kernel system deployment component is used to send a load instruction to the virtualization component, wherein the load instruction is used to instruct the virtualization component to send the load message; the remote attestation verification component is used to receive the remote attestation report output by the security component, and remotely attest the target trusted kernel system based on the remote attestation report; the virtualization component is used to receive the load instruction from the remote attestation verification component, and send the load message to the security component based on the load instruction.

14. An electronic device, comprising: a memory storing an executable program; A processor is used to run the program, wherein the program executes the remote attestation method of the cloud server according to any one of claims 1 to 12 when running.

15. A computer-readable storage medium comprising a stored executable program, wherein: When the executable program is running, the device where the computer-readable storage medium is located is controlled to execute the remote certification method of the cloud server according to any one of claims 1 to 12.

16. A computer program product comprising a computer program, wherein: When the computer program is executed by a processor, the computer program implements the remote certification method of the cloud server according to any one of claims 1 to 12.

Images