CN117473530A

CN117473530A - Lightweight trusted measurement system and method based on trusted execution environment

Info

Publication number: CN117473530A
Application number: CN202311484847.7A
Authority: CN
Inventors: 华志超; 程一同; 夏虞斌; 陈海波
Original assignee: Shanghai Jiaotong University
Current assignee: Shanghai Jiaotong University
Priority date: 2023-11-08
Filing date: 2023-11-08
Publication date: 2024-01-30
Anticipated expiration: 2043-11-08

Abstract

The invention provides a lightweight trusted measurement system and method based on a trusted execution environment, comprising the following steps: the measurement service driving module: receiving a measurement request sent by an application layer, and sending the measurement request to a secure world through an SMC Call; and setting a scheduler to periodically yield CPU resources from the common world to the secure world; an address translation module: designing an EL2 level in the safety world, performing preliminary analysis on the request, translating related addresses, and mapping related memory pages to a measurement execution module; the measurement execution module: designing an EL1 level execution running in the secure world managed by SPMC; trusted communication protocol: based on an asymmetric encryption algorithm, the true and effective measurement result is ensured, so that communication among all components in the measurement system is credible, and the source security of the message can be determined by all the components. The invention can ensure the safety and usability of the system, and can ensure the safety of the private data and prevent the data from being stolen or abused.

Description

Lightweight trusted measurement system and method based on trusted execution environment

Technical Field

The invention relates to the technical field of computers, in particular to a lightweight trusted measurement system and method based on a trusted execution environment.

Background

The integrity of the computer system means that the internal state of the computer system is always in a state of not being tampered with by a malicious program, and the code expected by a user is run. The integrity measurement system is software running in the computer system, can judge whether the operating system is illegally tampered or not by accessing, extracting and analyzing the running state of the computer system, returns a verifiable checking result to a user, and can defend malicious attacks to a certain extent. As cloud computing evolves, designing and implementing integrity metrics systems for cloud platforms comes with additional challenges. On one hand, the cloud platform needs to run different types of virtual machines provided by different users in parallel, so that the system architecture is more complex, a wider attack surface is provided, and meanwhile, the measurement system is required to provide a customized measurement mode according to the requirements of different users; on the other hand, the user has higher requirements on the real-time performance of the cloud platform, the introduction of the integrity measurement system cannot influence the real-time performance of the cloud platform, and higher requirements are put on the performance of the measurement system.

TrustZone was proposed for the first time at Armv6 as a set of security extensions. The aim is to provide a stand-alone environment for executing important and private software. Trust zone divides hardware resources into two worlds, one being a security-sensitive secure world and the other being a common world running conventional software, wherein management and isolation between the various security-sensitive software running in the secure world is achieved by trusted system kernels. Software in the general world is safely switched to the secure world after being checked by the secure firmware through the SMC Call. The secure virtualization extension in Armv8.4-A was proposed to enable monitor mode, the Exception Level 2 (EL 2) privilege Level in the Arm architecture, to be used in the secure world. Virtualization in the secure world is similar to that in the normal world. Secure Partition Manager running in EL2 privilege level in the secure world restricts the virtual machines running in EL1 in the secure world, called Secure Partit ion (SP), through two-phase page tables in Memory Management Unit (MMU) and IO Memory Management Unit (IOMMU), the system resources (including secure resources and non-secure resources) that can be accessed, and the handling of interrupts is controlled through configuration Generic Interrupt Controller (GIC). After the secure virtualization extension is started, a plurality of security sensitive software can be run in parallel in the secure world, and resources of each other cannot be accessed.

Arm proposed Firmware Framework for Arm A-profile (FF-A) to manage software in different worlds and at different privilege levels by providing Sub>A set of binary interface standards (FF-A ABI) 1. Isolating software images provided by different manufacturers by using virtualization technology; 2. a standard interface is described for communicating between different software. This includes communication between the secure world and the general world; 3. the interaction of software and privileged firmware in the secure world is normalized.

Trusted Platform Module is a security chip standard, proposed by Trusted Computing Group, capable of providing secure storage, platform integrity reporting, platform verification functionality. The TPM usually exists in the form of a coprocessor, and the main hardware platform does not need to be modified, but only passively accepts service requests of the system, and cannot actively influence the system. When the system measures, the measured system needs to calculate to obtain a measurement result, and then the measurement result is sent to the TPM to be signed by the TPM. The user can learn the measurement result authorized by the TPM through a remote authentication protocol. The disadvantage is that an attacker can attack the bus between the CPU and the TPM. Because the secure world and the common world are parallel and isolated, the relationship is similar to the relationship between the TPM and the CPU, and the invention uses the thinking of the TPM to realize the remote verification protocol.

The original integrity measurement system is generally based on Trusted Platform Module, proposed by Trusted Comput ing Group, an international standard for security coprocessors, providing a series of trusted cryptographic interfaces to the CPU by means of hard-coded keys, which can be used as a trusted root to provide remote attestation of the measurement results. LKIM proposed by American researchers provides a relatively perfect integrity measurement solution for Linux kernel based on TPM, and the measurement of an operating system and an application program is realized by modifying the operating system kernel. However, this solution cannot be applied to a cloud platform scenario with virtualization technology, because multiple operating system images provided by users are run in parallel in the cloud platform, invasive modification cannot be performed, and the number of chips of the TPM on the hardware platform is limited and cannot be provided to each virtual machine. In order to solve the problem that the number of TPM chips in a cloud platform scene is insufficient, a scholars at North Carolina state university put forward HIMA, virtualize the TPM by using a software means, hijack key events in a virtual machine through a virtual machine monitor to provide incremental measurement for the virtual machine, and design a virtual machine migration scheme aiming at the cloud platform scene. However, with the expansion of the virtual machine monitor itself Trusted Comput ing Base (TCB), solution by software would make security of the metrology system difficult to guarantee, and this solution still strongly binds to a specific virtual machine. Hewlett-packard researchers have proposed OSck, which addresses the problem of multi-threaded preemption in metrology systems and enables users to customize metrology schemes. But only for a single system, the method can not be applied to a cloud platform. The security reinforcement method of the virtual machine monitor based on the security chip, which is provided by researchers of the national engineering research center of basic software of the national academy of sciences software, is based on the dynamic integrity measurement architecture of the virtual machine monitor based on the dynamic trust root, and Zhang Jingdi, respectively uses different methods to realize the measurement of the virtual machine monitor in a cloud platform, but lacks the measurement capability of other system components.

These above tasks are to design an integrity metric system at the level of the system architecture. Still other efforts have focused on how to select some states of the system or how to perform metrology operations to make metrology results more accurate and efficient. The scholars of the university of George put forward KOP technology, which can accurately identify the type of the dynamically allocated object, thereby ensuring the dynamic integrity of the system during operation. However, the method has the defects of poor performance, incapability of ensuring real-time performance and difficulty in practical application in a cloud platform. The scholars of the new Orleans university put forward a ModChecker, and can transparently measure the scheme of the kernel module of the system aiming at the problem that the cloud platform is difficult to modify the virtual machine image. TF-BIV is provided by the national key laboratory of China information security, and partial dynamic properties of the system are identified while linear scanning of heap memory is provided according to performance requirements in a cloud platform. These efforts are limited by how some dynamic integrity properties in the system are chosen, orthogonal to the current solution of the present invention, and can be added to the system at any time according to the needs of the user.

While there have been efforts to implement metrology systems using TEE, these efforts are only specific to a particular hardware platform and are difficult to migrate into the Arm architecture based cloud platform scenario. And as the TEE software stack is further complicated, some trusted mechanisms are also needed to isolate the software in the TEE and to measure the integrity of the security software, so as to ensure the overall security of the system.

In addition, some other work (TZ-RKP, PAL) provides other degrees of integrity protection beyond metrics, the present invention lends itself to some details to complete the solution of the present invention.

In general, existing works cannot fully utilize the secure virtualization technology of the Arm architecture in the cloud platform scenario, and have one or more of the following disadvantages: the virtual machine of the user needs to be modified invasively or is a single machine scene only aiming at a specific operating system; the TCB of the system is large, so that the safety is difficult to ensure; the performance cost is large in the running process, and the real-time performance of the cloud platform is difficult to ensure.

In view of the above, the following problems need to be solved in the prior art: 1) How to guarantee the security of the system using the security virtualization feature? 2) How do it guarantee that the integrity of the measurement object can be accurately reflected and that the measurement object is compatible with a plurality of different measurement objects in the cloud platform? 3) The method and the system ensure that the measurement system can provide a measurement result with higher safety, and simultaneously optimize performance according to the specificity of the cloud platform scene and the hardware platform currently used by the method and the system so as to achieve low time delay and higher availability, and simultaneously allow a user to configure whether to start the optimization according to own safety requirements.

Abbreviations and key term definitions:

TEE: the trusted execution environment (Trusted Execut ion Environment) is a region of the computer system that is separate from the system host Operating System (OS). It ensures that data is stored, processed and protected in a secure environment.

FF-A: trusted hardware framework-A (Firmware Framework A), proposed by Arm, is Sub>A software architecture that manages software at different privilege levels in different worlds by providing Sub>A set of binary interface standards (FF-Sub>A ABI).

Disclosure of Invention

Aiming at the defects in the prior art, the invention provides a lightweight trusted measurement system and a lightweight trusted measurement method based on a trusted execution environment.

According to the lightweight trusted measurement system and method based on the trusted execution environment, the scheme is as follows:

in a first aspect, there is provided a lightweight trusted measurement system based on a trusted execution environment, the method comprising:

the measurement service driving module: receiving a measurement request sent by an application layer, and sending the measurement request to a secure world through an SMC Call; and setting a scheduler to periodically yield CPU resources from the common world to the secure world;

an address translation module: designing an EL2 level in the safety world, performing preliminary analysis on the request, translating related addresses, and mapping related memory pages to a measurement execution module;

The measurement execution module: designing an EL1 level execution running in the secure world managed by SPMC;

trusted communication protocol: based on an asymmetric encryption algorithm, the true and effective measurement result is ensured, so that communication among all components in the measurement system is credible, and the source security of the message can be determined by all the components.

Preferably, the metric service driving module includes:

writing a system kernel module by Linux as an example of a measurement service driver, and dynamically adding the system kernel module into a virtual machine to serve as an initiating point of a measurement request;

a string device is created at initialization of the kernel module while ioctl is used to expose the relevant interface to user state, which programs use the functionality provided by the metrology service driver by opening the corresponding string device and using ioctl phase relationship call. After receiving the request from the user mode, the measurement service driver writes the measurement request into a complete memory page, and sends the request to the secure world by a method of sharing the memory.

Preferably, the metric service driving module includes: the scheduler creates a corresponding number of threads according to the total number of virtual CPUs of all SPs in the safety world, and the scheduling of the threads is completed by a Linux self scheduler; when Sub>A thread is scheduled, the thread calls ABI related to scheduling in FF-A, and gives up own CPU resources to corresponding virtual machine CPU in the secure world.

Preferably, the address translation module includes: a queue is maintained in the address translation module, storing hash values of requests that have completed translation and mapping, and the order of last execution is ranked according to the requests. When a new measurement request is received and the hash value corresponding to the request cannot be found in the queue, the subsequent operations such as translation and mapping are performed, and a handle is allocated to the measurement request to indicate to which part of the virtual address space the memory associated with the request is mapped by the measurement execution module. Otherwise, no repeated translation and mapping operation is performed, the corresponding handle is found according to the hash value of the measurement request, and subsequent operation is directly performed.

Preferably, the address translation module needs to combine other modules to obtain an address translation related register;

the system uses an extra general register to temporarily store the required register and then transmits the register to the safety world; in EL3, the firmware is modified to identify the Magic Code in ABI, and the relevant registers are passed to the secure world only if the current interface is relevant to the metrology service.

Preferably, in the metric execution module, three metric modes with different dimensions are provided, and whether the current system is in a safe state is judged:

1) Calculating a hash value of the static data corresponding to the data in the virtual address;

2) Calculating authority bits of the appointed virtual address in the two-stage page table;

3) The shared status of the physical addresses is checked and monitored.

Preferably, a field is required in the metric request, and a hash value of the request is stored; maintaining a queue In an address translation module by adopting a First In and First Out strategy, storing hash values of requests which have completed translation and mapping, and arranging according to the last execution sequence of the requests;

when a new measurement request is received and the hash value corresponding to the request cannot be found in the queue, the subsequent operations such as translation, mapping and the like are carried out, and a handle is allocated to the measurement request and used for indicating to which part of the virtual address space the memory related to the measurement execution module is mapped; otherwise, no repeated translation and mapping operation is performed, the corresponding handle is found according to the hash value of the measurement request, and subsequent operation is directly performed.

In a second aspect, there is provided a lightweight trusted measurement method based on a trusted execution environment, the method comprising:

the method comprises a cloud platform starting process, a virtual machine starting process, a request transfer process, an address translation process, a measurement executing process and a measurement result verification process;

The cloud platform starting process comprises the following steps:

step 1), generating a public and private key of EK by a hardware platform manufacturer;

step 2), the manufacturer of the hardware platform places the public key of EK in the security verifier; typically, the security verifier provides services to the outside for the hardware platform manufacturer;

step 3) the manufacturer of the hardware platform places the private key of the EK in the software image of the secure world in a secure and private manner;

step 4) software in the secure world is started in a trusted manner; the software itself needs to be ensured not to be tampered, and the privacy information therein is not revealed; if the starting fails, jumping to the step 6); otherwise, entering the next step;

step 5) the starting is successful, and the virtual machine of the user can be deployed in the starting;

step 6) failure in creation, abnormality or attack in the process;

the virtual machine starting process comprises the following steps:

step 1), a user uploads an image of a virtual machine to a platform, starts the virtual machine, and initializes a measurement service drive;

step 2), after the virtual machine is started, requesting to generate AK from the secure world for subsequent measurement;

step 3), the secure world receives the AK generation request, generates the public and private key of AK, and binds the key with the VMID of the virtual machine; finally, signing the result of the request by using an EK private key, and returning the result to the virtual machine verifier;

Step 4), the virtual machine verifier requests the security verifier to verify the signature correctness of the AK generated result, the verification is not passed, and the step 7) is skipped, otherwise, the next step is entered;

step 5), the virtual machine verifier stores the public key of AK to verify the correctness of the measurement result;

step 6), the virtual machine starting stage is finished, and the subsequent measurement request can be correspondingly carried out;

step 7) failed start-up;

the request transfer process includes:

step 1) a user desiring to initiate a metric obtains a specific request from a virtual machine verifier through a remote function call;

step 2) the user initiates a request to a measurement driver in the virtual machine;

step 3), the virtual machine driver directly sends the request to the secure world through a smc call;

step 4) the secure world receives the measurement request and performs measurement operation;

the address translation process includes:

step 1), SPMC initially analyzes the acquired measurement request;

step 2) mapping the measurement request into the address space of the SPMC and the measurement execution module respectively;

step 3), SPMC further analyzes the request to obtain address translation information;

step 4) mapping the memory to be measured into an address space of a measurement execution module;

step 5) after the address is remapped, the address range in the request needs to be converted again, and the conversion of the measurement request is carried out;

Step 6) transmitting the request to Sub>A measurement execution module according to FF-A specification;

the measurement execution process comprises the following steps:

step 1), a measurement execution module analyzes a received measurement request;

step 2), the measurement execution module maps the memory to be measured into a first-stage page table of the measurement execution module;

step 3) executing a measurement operation and carrying out a hash operation on the measured memory;

step 4) signing the measurement result by using the corresponding AK private key, thereby generating a verifiable measurement result;

step 5) returning the measurement result;

the verification process of the measurement result comprises the following steps:

step 1), a user transmits a measurement result to a virtual machine verifier through remote function call;

step 2), the virtual machine verifier verifies the correctness of the signature of the measurement result through the AK public key; verification fails, and the step 6) is skipped; otherwise, entering the next step;

step 3), the virtual machine verifier compares whether the content in the measurement result is correct or not; verification fails, and the step 6) is skipped; otherwise, entering the next step;

step 4) returning the verification result to the user;

step 5) the measurement is successful, and the integrity of the measurement target is not destroyed;

step 6) the measurement fails, and the integrity of the measurement target may be destroyed.

In a third aspect, a computer readable storage medium is provided, storing a computer program which, when executed by a processor, implements the steps of the lightweight trusted measurement method based on a trusted execution environment.

In a fourth aspect, an electronic device is provided, comprising a memory, a processor and a computer program stored on the memory and executable on the processor, which when executed by the processor implements the steps of the lightweight trusted execution environment based method of measuring trustworthiness.

Compared with the prior art, the invention has the following beneficial effects:

1. by utilizing the safety virtualization characteristic, the safety of the system is ensured, the existing open source software and open source software frameworks are needed to be borrowed, and most safety sensitive code logic is configured in an isolated environment, so that the TCB only adds a limited small part of codes on the basis of a necessary part. TCB means that the probability of a trusted code problem is lower, there is higher security, and it is more likely to formally verify its security.

2. The integrity of the measurement object can be accurately reflected, and the measurement object is compatible with various measurement objects in the cloud platform, and the types of the measurement objects can be different due to the specificity of the cloud platform, so that the measurement object needs to be customized to a certain extent according to the user requirements; at the same time, it also allows users with special security requirements to extend other types of metrics.

3. The invention has high safety and is embodied in two aspects: the system is designed to be safe enough, the TCB is small enough to defend the attack of external attackers, and the internal loopholes are as few as possible; the resulting measurement is difficult to forge and can be verified for trustworthiness.

4. The invention can flexibly select the measurement, and the user can flexibly select and execute the measurement with different dimensionalities and different degrees according to the security requirement of the user.

5. The invention can ensure low time delay and high real-time performance, and optimize the measurement result according to the characteristics of the existing hardware platform as much as possible while ensuring that the measurement system can provide a measurement result with higher safety so as to achieve low time delay and higher real-time performance.

Other advantages of the present invention will be set forth in the description of specific technical features and solutions, by which those skilled in the art should understand the advantages that the technical features and solutions bring.

Drawings

Other features, objects and advantages of the present invention will become more apparent upon reading of the detailed description of non-limiting embodiments, given with reference to the accompanying drawings in which:

FIG. 1 is a schematic diagram of a system according to the present invention;

FIG. 2 is a schematic diagram of a cloud platform startup process;

FIG. 3 is a schematic diagram of a virtual machine startup process;

FIG. 4 is a schematic diagram of a request transfer process;

FIG. 5 is a schematic diagram of an address translation process;

FIG. 6 is a schematic diagram of a metric execution process;

FIG. 7 is a schematic diagram of a verification process of the measurement result.

Detailed Description

The present invention will be described in detail with reference to specific examples. The following examples will assist those skilled in the art in further understanding the present invention, but are not intended to limit the invention in any way. It should be noted that variations and modifications could be made by those skilled in the art without departing from the inventive concept. These are all within the scope of the present invention.

The embodiment of the invention provides a lightweight trusted measurement system based on a trusted execution environment, and referring to FIG. 1, the system effectively reduces the size of a trusted code segment by utilizing a multi-level collaboration framework, and provides possibility for deep performance optimization; the extensible customized measurement is used, so that multiple types of virtual machine images in the cloud platform and most of system components can be measured; the configurable targeted optimization is provided, and the execution performance is optimized according to the specificity of the cloud platform scene and the Arm hardware characteristics so as to achieve low time delay and higher availability. Experimental results show that the system can execute low-delay measurement on multiple types of virtual machines by using smaller trusted code segments by effectively utilizing the characteristics of new hardware, and ensure the safety of measurement results.

An embodiment of the apparatus of the present invention is shown in fig. 1. Software in the general world is usually customized by a cloud platform service provider according to own business requirements, an example is given here by the invention, and the EL2 in the general world runs hypervisors provided by a cloud platform and is used for managing virtual machines of users; a plurality of virtual machines are run below the virtual machines, and various user-defined applications and services are run above the virtual machines; if the user wants to enable the measurement service to ensure the integrity of the own virtual machine, a measurement service driver needs to be added in the own virtual machine, so as to accept measurement requests sent by user states or other modules in the kernel, and initiate measurement requests to the measurement system, for example, the measurement service driver is a kernel module under Linux.

In the secure world, SPMD takes over the role of EL3 firmware, takes care of performing highest authority configuration and management, and checking communication requests between the two worlds; SPMC is responsible for managing the multiple SPs running under it; the address translation module operates in EL2 as SPMC, is responsible for translating the virtual address of the measurement object into a physical address, and maps to the address space of the SP executing measurement calculation; the metrology execution module is designed to run at one SP of EL1, which performs almost all the computational operations and associated cryptographic operations in the metrology process.

The specific implementation of each module in the invention is as follows:

the measurement service driving module:

since SMC Call requires software to be invoked at least at the EL1 privilege level, a measurement request cannot be directly initiated at EL0, the application layer. While modifications to the operating system need to be reduced as much as possible in order to meet compatibility requirements. Modern operating systems mostly support dynamic extension of the functionality of the kernel by adding a system kernel module, which provides the possibility to execute privileged code without modifying the operating system kernel. The invention writes a system kernel module for Linux as an example of a measurement service driver, and dynamically adds the system kernel module into a virtual machine to be used as an initiating point of a measurement request.

The metric service driver takes on two main roles. The method is mainly characterized by receiving a measurement request sent by an application layer and sending the measurement request to the safety world through an SMC Call; secondly, in order to enable other types of SPs in the secure world to normally operate, a simple scheduler is also realized, and CPU resources can be periodically yielded from the common world to the secure world.

To enable a metric service driver running in kernel mode to receive messages from the application layer, the present invention creates a string device at kernel module initialization, while using Input Output ConTroL (ioctl) to expose the relevant interface to user mode. The user mode program can use the functionality provided by the measurement service driver by opening the corresponding string device and using ioctl facies relationship system calls. After receiving the request from the user mode, the metric service driver writes the metric request into a complete memory page and sends the request to the secure world by sharing the memory.

The scheduler part creates a corresponding number of threads according to the total number of virtual CPUs of all SPs in the safety world, and the scheduling of the threads is completed by a Linux scheduler. When Sub>A thread is dispatched, it will call the ABI associated with the dispatch in FF-A to yield its own CPU resources to the corresponding virtual machine CPU in the secure world.

An address translation module:

the address translation module is designed to run in the EL2 hierarchy in the secure world as SPMC, and is responsible for performing preliminary resolution of the request, translating the relevant address, and mapping the relevant memory page to the metric execution module. In order to reduce the overhead required for address translation, a queue is maintained in the address translation module, storing hash values of requests that have completed translation and mapping, and arranged in the order in which the requests were last executed. When a new measurement request is received and the hash value corresponding to the request cannot be found in the queue, the subsequent operations such as translation and mapping are performed, and a handle is allocated to the measurement request to indicate to which part of the virtual address space the memory associated with the request is mapped by the measurement execution module. Otherwise, no repeated translation and mapping operation is performed, the corresponding handle is found according to the hash value of the measurement request, and subsequent operation is directly performed.

It is also necessary to incorporate other modules to obtain address translation related registers. When measuring the virtual machine running in the EL1 privilege level in the common world, two stages of page tables are required to be accessed, namely a first stage page table, the virtual address of the virtual machine is converted into an indirect physical address, and the virtual machine is configured by itself; and the second stage page table converts the indirect physical address into a physical address and is configured by the Hypervisor. However, in current systems, both SPMC and hypervisors run at EL2, both require configuration of the second stage page table, and the page table registers used are the same name. At the Hypervisor perspective, there is a set of registers for configuring the second stage page tables of the virtual machine, but at the SPMC perspective, this set of registers is used to configure the second stage page tables of the SP's non-secure memory. In the current implementation of TF-Sub>A firmware running in EL3, the values of this set of registers will also be switched at world switching, resulting in SPMC not having normal access to the two-phase page table of the virtual machine. The present invention therefore uses additional general purpose registers to register the required registers and then pass them on to the secure world. However, not all interactions between the two worlds require the temporary storage of the set of registers, as this may introduce additional information transfer, increasing the risk of potential information leakage. Thus in EL3, the invention modifies the firmware to recognize the Magic Code in ABI and passes the relevant registers to the secure world only if the current interface is relevant to the metrology service.

The measurement execution module:

the metric execution module is designed to run in the EL1 hierarchy in the secure world managed by SPMC. In order to ensure the completeness of the measurement result, so that after the user obtains the measurement result, there is a sufficient reason to judge whether the current system is in a safe state, we provide three measurement modes with different dimensions:

and calculating the hash value of the static data corresponding to the data in the virtual address. In early measurement systems and in the current common secure boot techniques, hash values were obtained by hashing the software image and reported to the user, so that the user can determine whether the target machine is running the system that the user wants to run. However, the security state of the operating system during running cannot be reflected by only measuring the image before the operating system is started. By taking this approach into account, the measurement of static data at runtime is supported. At the same time, in order to adapt as many operating systems as possible, the virtual address where static data is actually loaded needs to be specified in bytes by the owner of the virtual machine by itself generating a metric request. This approach places certain demands on the user's own operating system level, as they are required to have the ability to know which virtual addresses data is security sensitive, and to have a level of programming to generate such a metric request. For ease of use, we provide some tools to assist users in use, and the metric requests may also be generated by operating system developers, commonly used by multiple users. The address translation module translates all virtual addresses in the measurement request, which need to calculate hash values, into physical addresses, maps the physical addresses into an address space of the measurement execution module, and then the measurement execution module calculates the virtual addresses. The measurement system transmits the hash value after signing, and a user can judge the safety state of the system according to whether the hash value accords with the expectation.

The permission bits in the two-stage page table are calculated that specify the virtual address. Some data is dynamically modified at runtime, and it is difficult to simply reflect whether it is secure by a hash value. We observe that the permission bits of some data on the page table always have specific properties. For example, a code segment in an operating system typically always has executable rights, and not writeable rights. The specific pages that need to be checked for what type of permissions are also determined by the user, again in bytes granularity, and passed to the metrology system via the metrology service driver. If this dimension of the metrology mode is enabled, the address translation module will map the physical address of the associated page table into the address space of the metrology execution module as well, and the metrology execution module will perform the associated check.

The shared status of the physical addresses is checked and monitored. With both metrics, the integrity of the system can already be guaranteed to some extent. But on the basis of the FF-Sub>A specification, the shared state of the physical address among Sub>A plurality of SPs can be further protected. The SP may require the metrics system to return some shared state of physical addresses in the result or require the metrics system to ensure that some physical addresses are always in some shared state. For example, if a certain SP wants to implement a certain degree of private storage, a certain memory is not shared by an attacker to other SPs, and the measurement system can be delegated to monitor the sharing state of the certain memory. When memory sharing operations are performed between SPs, the metrology system ensures that these operations do not violate pre-established sharing rules. Since the physical address has no guarantee of availability and no scheduling capability, the corresponding SP cannot be informed of the illegal operation in time, and the related information can only be attached to the measurement report when the SP requests the measurement next time. Secondly, the attacker may falsify the behavior of the SP to cancel the protection of the memory, and the measurement system will save the relevant behavior and inform the user along with the measurement report. This measure is implemented by SPMC, since SPMC is responsible for memory sharing and isolation of SPs. Furthermore, since the secure world does not have a privileged relationship to hypervisors, this integrity protection is not applicable to virtual machines in the general world. However, if the Hypervisor in the general world complies with the FF-A standard, this protection scheme can be easily migrated to the Hypervisor.

A field is required in the metric request and a hash value of the request is stored. By adopting the First In and First Out strategy, a queue is maintained In the address translation module, hash values of requests for which translation and mapping have been completed are stored, and are arranged according to the last execution order of the requests. When a new measurement request is received and the hash value corresponding to the request cannot be found in the queue, the subsequent operations such as translation and mapping are performed, and a handle is allocated to the measurement request to indicate to which part of the virtual address space the memory associated with the request is mapped by the measurement execution module. Otherwise, no repeated translation and mapping operation is performed, the corresponding handle is found according to the hash value of the measurement request, and subsequent operation is directly performed.

Performing a linear scan of the memory of the measurement object and computing the hash is also a time consuming operation, and our solution is to use some hash algorithms with high computation speed but low security, mixed with the more secure algorithms. More specifically, a time threshold may be configured when a user periodically requests the metrology system to perform a metrology. This time threshold requires that the metrology system must perform a metrology operation using a strong security hash algorithm within a specified time frame, between which the performed metrology request will employ a low security hash algorithm. If the second measurement is performed under the condition of measurement failure, the algorithm with stronger safety is always selected. Currently, the low security hash algorithm makes the memory to be measured exclusive-or with a certain step size, and accelerates by Arm Scalable Vector Extension (SVE); high security hash algorithm we use the SHA-256 algorithm provided by MbedTLS. Such optimization tends to make the current metric report unable to safely reflect the integrity of the metric object itself, increasing the probability of false negatives, so we also provide a configuration option that allows the user to turn off the optimization.

Trusted communication protocol:

once the data has exited the secure world, it may be attacked, stolen, and tampered with. Therefore, a trusted communication protocol based on an asymmetric encryption algorithm is designed, so that the measurement result can be ensured to be truly effective, the communication among all components in the measurement system is trusted, and all the components can determine that the source of a message is safe. For simplicity, the communication protocol in the measurement flow of the virtual machine in the common world is described herein, and the protocol can be applied to measurement of other components without losing generality, but the implementation details are slightly changed. The premise of using this trusted communication protocol is the security of the asymmetric encryption algorithm, which requires that the software in the secure world be able to correctly generate random numbers and that the software in the secure world be able to trusted obtain a timestamp. The following are the various entities involved in the communication in this communication protocol:

the safety world: for simplicity, all components in the secure world are abstracted as one community. Because the relation of the safety world relative to the common world is parallel, more like a coprocessor, the safety world plays a role similar to a TPM chip;

Security verifier: the method can be a cloud platform service provider or a trusted third party entrusted by the cloud platform service provider, and needs to provide identity authentication for a hardware platform;

virtual machine verifier: an owner of a certain virtual machine in the common world, or a trusted third party delegated by the owner, needs to provide proof for a certain measurement result of the virtual machine;

challenger: the initiator of the metric request wants to know the integrity of a virtual machine before using a service running on that virtual machine.

In order to make the situation more concise, it is provided here that the communication between any entity and the security verifier and virtual machine verifier is trusted, as this can be guaranteed by distributing the public key in advance. Furthermore, migration of virtual machines is not considered, as trusted migration can be implemented in an orthogonal fashion. The basis of our communication protocol is an asymmetric encryption algorithm, in which a total of two pairs of public and private keys are involved, respectively: an Endorsement Key (EK), the private Key of which is stored in the secure world and used for proving the identity and integrity of the hardware platform itself; the Attestation Key (AK), the private Key of which is also stored in the secure world, will use a different AK for each virtual machine. Details of specific interactions between entities will be set forth in subsequent flow embodiments.

Next, the present invention will be described in more detail.

The specific implementation flow of the technical scheme comprises a cloud platform starting process, a virtual machine starting process, a request transfer process, an address translation process, a measurement execution process and a measurement result verification process.

As shown in fig. 2, the cloud platform starting process includes:

step 1) the manufacturer of the hardware platform generates the public and private key of the EK in a private mode.

Step 2), the manufacturer of the hardware platform places the public key of EK in the security verifier; typically, the security verifier provides external services for the hardware platform manufacturer.

Step 3) the hardware platform manufacturer places the private key of the EK in a secure and private manner in a software image of the secure world.

Step 4) software in the secure world is started in a trusted manner; it is necessary to ensure that the software itself is not tampered with and that the private information therein is not compromised. If the starting fails, jumping to a step 6; otherwise, the next step is carried out.

Step 5) is successfully started, and the virtual machine of the user can be deployed in the step.

Step 6) the creation fails, and the process is abnormal or possibly attacked.

Referring to fig. 3, the virtual machine starting process includes:

step 1) the user uploads the own virtual machine image to the platform to start the virtual machine, wherein the measurement service drive is initialized.

Step 2) after the virtual machine is started, requesting to generate AK from the secure world for subsequent measurement.

Step 3), the secure world receives the AK generation request, generates the public and private key of AK, and binds the key with the VMID of the virtual machine; finally, the result of this request is signed using the EK private key and returned to the virtual machine verifier.

Step 4), the virtual machine verifier requests the security verifier to verify the signature correctness of the AK generating result. If the verification is not passed, the step 7 is skipped, otherwise the next step is entered.

Step 5), the virtual machine verifier stores the public key of AK to verify the correctness of the measurement result.

Step 6), the virtual machine starting stage is finished, and the subsequent measurement request can be correspondingly carried out.

Step 7) failed start-up.

Referring to fig. 4, the request transfer process includes:

step 1) a user desiring to initiate a metric obtains a specific request from a virtual machine verifier via a remote function call.

Step 2) the user initiates a request to a metrics driver in the virtual machine.

Step 3) the virtual machine driver sends the request directly to the secure world through the smc call.

Step 4) the secure world receives the metrology request and performs a metrology operation.

Referring to fig. 5, the address translation process includes:

step 1) SPMC initially analyzes the acquired measurement request.

Step 2) mapping the metric request into the address space of the SPMC and the metric execution module, respectively.

Step 3) SPMC further analyzes the request to obtain address translation information.

Step 4) mapping the memory needing to be measured into an address space of a measurement execution module.

Step 5) after the address is remapped, the address range in the request needs to be converted again, and the conversion of the measurement request is carried out.

Step 6) passing the request to the metric execution module according to the FF-Sub>A specification.

Referring to fig. 6, the metric execution process includes:

step 1) the measurement execution module analyzes the received measurement request.

Step 2) the metric execution module maps the memory to be measured into the first-stage page table.

Step 3) executing measurement operation, mainly hash operation on the measured memory.

And 4) signing the measurement result by using the corresponding AK private key, thereby generating a verifiable measurement result.

Step 5) returning the measurement result.

Referring to fig. 7, the verification process of the measurement result includes:

step 1) the user transmits the measurement result to the virtual machine verifier through remote function call.

Step 2), the virtual machine verifier verifies the correctness of the signature of the measurement result through the AK public key. The verification fails, and the step 6 is skipped; otherwise, go to the next step.

Step 3), the virtual machine verifier compares whether the content in the measurement result is correct or not. The verification fails, and the step 6 is skipped; otherwise, go to the next step.

Step 4) returning the verification result to the user.

Step 5) the measurement is successful, and the integrity of the measurement target is not destroyed.

The invention has the core innovation points that: 1: and the safety virtualization hardware characteristic is utilized to further ensure the safety of the system.

Slave innovation point 1.1: with the multi-level synergistic architecture, only the core security modules are modified as little as possible to reduce the overall TCB size.

Cluster innovation point 1.2: and the SPMC is used for performing an address translation process, so that the repeated utilization rate of codes is improved, and the overall safety is ensured.

Core innovation point 2: the integrity of the measurement object is accurately reflected, and the measurement object is compatible with a plurality of different measurement objects in the cloud platform.

Slave innovation point 2.1: and a plurality of different types of measurement contents and measurement modes are supported, and the safety of users in the cloud platform is ensured.

Slave innovation point 2.2: dynamic change of measurement requests is supported, and safety under long-time dimension is guaranteed.

Slave innovation point 2.3: a trusted communication protocol is designed to prevent man-in-the-middle attacks.

Core innovation point 3: the time delay is reduced aiming at hardware specificity and scene specificity, and the usability is improved.

Slave innovation point 3.1: by the collaborative design of multiple hierarchies, the length of the metric request transfer path is reduced.

Slave innovation point 3.2: the different hash algorithms are supported to be configurably mixed for computation.

Slave innovation point 3.3: the use of queues avoids duplicate address mapping operations.

The embodiment of the invention provides a lightweight trusted measurement system and a lightweight trusted measurement method based on a trusted execution environment, which ensure the safety of the system by utilizing the safety virtualization characteristic, and allocate most safety-sensitive code logic in an isolated environment by using the existing open source software and open source software framework, so that a TCB only adds a limited small part of codes on the basis of a necessary part. Through the design of flexibility, the integrity of the measurement object is accurately reflected, the measurement object is compatible with various different measurement objects in the cloud platform, and the safety of data circulation is ensured. The invention optimizes the performance aiming at the specificity of the cloud platform scene and the hardware platform currently used by the invention while ensuring that the measurement system can provide a measurement result with higher safety.

Those skilled in the art will appreciate that the invention provides a system and its individual devices, modules, units, etc. that can be implemented entirely by logic programming of method steps, in addition to being implemented as pure computer readable program code, in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers, etc. Therefore, the system and various devices, modules and units thereof provided by the invention can be regarded as a hardware component, and the devices, modules and units for realizing various functions included in the system can also be regarded as structures in the hardware component; means, modules, and units for implementing the various functions may also be considered as either software modules for implementing the methods or structures within hardware components.

The foregoing describes specific embodiments of the present invention. It is to be understood that the invention is not limited to the particular embodiments described above, and that various changes or modifications may be made by those skilled in the art within the scope of the appended claims without affecting the spirit of the invention. The embodiments of the present application and features in the embodiments may be combined with each other arbitrarily without conflict.

Claims

1. A trusted execution environment-based lightweight trusted metrics system, comprising:

2. The trusted execution environment-based lightweight trusted metrics system of claim 1, characterized in that the metrics service driver module comprises:

3. The trusted execution environment-based lightweight trusted metrics system of claim 1, characterized in that the metrics service driver module comprises: the scheduler creates a corresponding number of threads according to the total number of virtual CPUs of all SPs in the safety world, and the scheduling of the threads is completed by a Linux self scheduler; when Sub>A thread is scheduled, the thread calls ABI related to scheduling in FF-A, and gives up own CPU resources to corresponding virtual machine CPU in the secure world.

4. The trusted execution environment-based lightweight trusted metrics system of claim 1, characterized in that the address translation module comprises: maintaining a queue in the address translation module, storing hash values of the requests which have completed translation and mapping, and arranging the order of last execution according to the requests; when a new measurement request is received and the hash value corresponding to the request cannot be found in the queue, performing subsequent operations such as translation, mapping and the like, and allocating a handle to the measurement request for indicating to which part of the virtual address space the memory related to the measurement execution module is mapped; otherwise, no repeated translation and mapping operation is performed, the corresponding handle is found according to the hash value of the measurement request, and subsequent operation is directly performed.

5. The trusted execution environment-based lightweight trusted metrics system of claim 1, wherein the address translation module needs to combine with other modules to obtain address translation related registers;

using additional general registers to temporarily store the required registers, and then transferring the registers to the secure world; in EL3, the firmware is modified to identify the Magic Code in ABI, and the relevant registers are passed to the secure world only if the current interface is relevant to the metrology service.

6. The system of claim 1, wherein the metric execution module provides three different dimensional metrics to determine whether the current system is in a secure state:

3) The shared status of the physical addresses is checked and monitored.

7. The trusted execution environment-based lightweight trusted metrics system of claim 1, characterized in that a field is needed in the metrics request to store the hash value of the request; maintaining a queue in an address translation module by adopting a First in and First Out strategy, storing hash values of requests which have completed translation and mapping, and arranging according to the last execution sequence of the requests;

8. A method of lightweight trusted execution environment based measurement of trustworthiness, characterized in that the lightweight trusted execution environment based measurement system of any one of claims 1-7 comprises: the method comprises a cloud platform starting process, a virtual machine starting process, a request transfer process, an address translation process, a measurement executing process and a measurement result verification process;

the cloud platform starting process comprises the following steps:

step 6) failure in creation, abnormality or attack in the process;

the virtual machine starting process comprises the following steps:

step 7) failed start-up;

the request transfer process includes:

the address translation process includes:

step 1), SPMC initially analyzes the acquired measurement request;

the measurement execution process comprises the following steps:

step 5) returning the measurement result;

step 4) returning the verification result to the user;

step 6) the measurement fails, and the integrity of the measurement target is possibly damaged.

9. A computer readable storage medium storing a computer program, which when executed by a processor implements the steps of the trusted execution environment based lightweight trusted metrics method of claim 8.

10. An electronic device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, characterized in that the computer program when executed by the processor implements the steps of the trusted execution environment based lightweight trusted metrics method of claim 8.