CN117473530B - Lightweight trusted measurement system and method based on trusted execution environment - Google Patents

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 present invention relates to the field of computer technology, and in particular to a lightweight trusted measurement system and method based on a trusted execution environment.

Background Art

The integrity of a computer system means that the internal state of the computer system is always in a state that has not been tampered with by malicious programs and runs the code expected by the user. The integrity measurement system is software running inside the computer system. It can access, extract and analyze the state of the computer system during operation to determine whether the operating system has been illegally tampered with at this time, and return verifiable inspection results to the user. At the same time, it can defend against malicious attacks to a certain extent. With the development of cloud computing, the design and implementation of integrity measurement systems for cloud platforms are accompanied by additional challenges. On the one hand, cloud platforms need to run different types of virtual machines provided by different users in parallel, which makes the system architecture more complex and has a wider attack surface. At the same time, it also requires the measurement system to provide customized measurement methods according to the needs of different users; on the other hand, users have higher requirements for the real-time performance of cloud platforms. The introduction of integrity measurement systems cannot affect the real-time performance of the cloud platform itself, which puts higher requirements on the performance of measurement systems.

TrustZone, as a set of security extensions, was first proposed in Armv6. The purpose is to provide an independent environment to execute important and private software. TrustZone divides hardware resources into two worlds, one is the security-sensitive secure world, and the other is the normal world that runs regular software. The management and isolation between various security-sensitive software running in the secure world are implemented through the trusted system kernel. The software in the normal world switches to the secure world safely through SMC Call after being checked by the security firmware. The secure virtualization extension was proposed in Armv8.4-A, allowing monitor mode, that is, the Exception Level 2 (EL2) 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. The Secure PartitionManager running at the EL2 privilege level in the secure world limits the virtual machines running at EL1 in the secure world, called Secure Partition (SP), through the two-stage page tables in the Memory Management Unit (MMU) and IO Memory Management Unit (IOMMU). The system resources (including secure resources and non-secure resources) that can be accessed are controlled by configuring the Generic Interrupt Controller (GIC). After the secure virtualization extension is enabled, multiple security-sensitive software can run in parallel in the secure world without accessing each other's resources.

Arm proposed the Firmware Framework for Arm A-profile (FF-A) to manage software in different worlds and privilege levels. It is implemented by providing a set of binary interface standards (FF-A ABI): 1. Using virtualization technology to isolate software images provided by different manufacturers; 2. Describing a standard interface for communication between different software. This includes communication between the secure world and the normal world; 3. Standardizing the interaction between software in the secure world and privileged firmware.

Trusted Platform Module is a security chip standard launched by the Trusted Computing Group, which can provide secure storage, platform integrity reporting, and platform verification functions. TPM often exists in the form of a coprocessor, and does not require modifications to the main hardware platform, but can only passively accept system service requests without actively affecting the system. When the system is measured, the measured system needs to perform calculations to obtain the measurement results, and then send them to the TPM for signature. Users can obtain the measurement results authorized by the TPM through the remote verification protocol. The disadvantage is that attackers can attack the bus between the CPU and the TPM. Since the secure world and the ordinary world are parallel and isolated, this relationship is similar to the relationship between the TPM and the CPU. The present invention draws on the idea of TPM to implement the remote verification protocol.

The initial integrity measurement system is generally based on the Trusted Platform Module proposed by the Trusted Comput ing Group, which is an international standard for secure coprocessors. It provides a series of trusted cryptographic interfaces for the CPU through hard-coded keys, and can be used as a trusted root to provide remote proof of measurement results. LKIM proposed by American researchers provides a relatively complete integrity measurement solution for the Linux kernel based on TPM, and realizes the measurement of operating systems and applications by modifying the operating system kernel. However, this solution cannot be applied to cloud platform scenarios with virtualization technology, because multiple operating system images provided by users will run in parallel in the cloud platform, and intrusive modifications cannot be made. In addition, the number of TPM chips on the hardware platform is limited and cannot be provided to each virtual machine. In order to solve the problem of insufficient number of TPM chips in cloud platform scenarios, scholars from North Carolina State University proposed HIMA, which virtualized TPM using software means, hijacked key events in virtual machines through virtual machine monitors to provide incremental measurements of virtual machines, and designed virtual machine migration solutions for cloud platform scenarios. However, as the Trusted Computing Base (TCB) of the virtual machine monitor itself expands, it will be difficult to ensure the security of the measurement system through software solutions, and this solution is still strongly bound to a specific virtual machine. HP researchers proposed OSck, which deals with the problem of multi-thread preemption in the measurement system and allows users to customize the measurement solution. However, it is only applicable to stand-alone systems and cannot be applied to cloud platforms. The dynamic integrity measurement architecture of virtual machine monitors based on dynamic trust roots proposed by researchers from the National Engineering Research Center for Basic Software, Institute of Software, Chinese Academy of Sciences, and the virtual machine monitor security reinforcement method based on security chips proposed by Zhang Jing use different methods to achieve the measurement of virtual machine monitors in cloud platforms, but lack the ability to measure other system components.

The above works are designed integrity measurement systems at the level of system architecture. Some other works focus on how to select some states of the system or how to perform measurement operations to make the measurement results more accurate and efficient. Scholars from Georgia Institute of Technology proposed KOP technology, which can accurately identify the types of dynamically allocated objects, thereby ensuring the dynamic integrity of the system during operation. But the disadvantage is that the performance is poor, real-time performance cannot be guaranteed, and it is difficult to be applied in cloud platforms. Scholars from the University of New Orleans proposed ModChecker, which is a solution that can transparently measure system kernel modules to address the problem that it is difficult to modify virtual machine images on cloud platforms. The State Key Laboratory of Information Security of China proposed TF-BIV, which proposes to identify some dynamic properties of the system while linearly scanning the heap memory to meet the performance requirements in the cloud platform. These works are limited to how to select some dynamic integrity attributes in the system, which is orthogonal to the current solution of the present invention and can be added to the system at any time according to user needs.

Although there are some works that use TEE to implement measurement systems, these works are only for specific hardware platforms and are difficult to migrate to cloud platform scenarios based on the Arm architecture. And as the TEE software stack becomes more and more complex, it is also necessary to use some trusted mechanisms to isolate the software in the TEE and measure the integrity of these security software to ensure the overall security of the system.

In addition, some other works (TZ-RKP, PAL) provide other levels of integrity protection beyond metric, and the present invention draws on some details therein to improve the solution of the present invention.

In general, existing work cannot fully utilize the secure virtualization technology of the Arm architecture in the cloud platform scenario, and has one or more of the following disadvantages: it is necessary to invasively modify the user's virtual machine, or it is only applicable to stand-alone scenarios with specific operating systems; the system's own TCB is large, making it difficult to ensure security; the runtime performance overhead is large, making it difficult to ensure real-time performance after being applied to the cloud platform.

In summary, the following problems need to be solved in the current existing technology: 1) How to use the security virtualization feature to ensure the security of the system? 2) How to ensure that the integrity of the measurement object can be accurately reflected and compatible with various different measurement objects in the cloud platform? 3) While ensuring that the measurement system can provide highly secure measurement results, how to optimize the performance based on the particularity of the cloud platform scenario and the hardware platform currently used in the present invention to achieve low latency and high availability, while allowing users to configure whether to enable these optimizations according to their own security requirements.

Definitions of Abbreviations and Key Terms:

TEE: Trusted Execution Environment is an area in a computer system that is separated from the system's main 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 a software architecture that manages software in different worlds and privilege levels by providing a set of binary interface standards (FF-A ABI).

Summary of the invention

In view of the defects in the prior art, the present invention provides a lightweight trusted measurement system and method based on a trusted execution environment.

According to a lightweight trusted measurement system and method based on a trusted execution environment provided by the present invention, the scheme is as follows:

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

Metrics service driver module: accepts metrics requests from the application layer and sends them to the secure world through SMC Call; and sets up a scheduler to periodically transfer CPU resources from the normal world to the secure world;

Address translation module: Designed at the EL2 level in the secure world, it is responsible for preliminary parsing of requests, translating relevant addresses, and mapping relevant memory pages to the measurement execution module;

Measurement execution module: designed to run at EL1 level in the secure world managed by SPMC;

Trusted communication protocol: Based on asymmetric encryption algorithms, it ensures that the measurement results are authentic and valid, makes the communication between components in the measurement system trustworthy, and enables each component to determine the security of the source of the message.

Preferably, the measurement service driving module includes:

An example of writing a system kernel module in Linux as a measurement service driver is given, which is dynamically added to the virtual machine as the initiation point of the measurement request.

When the kernel module is initialized, a string device is created and ioctl is used to expose the relevant interface to the user state. The user state program opens the corresponding string device and uses the ioctl related system calls to use the functions provided by the measurement service driver. After receiving the request from the user state, the measurement service driver writes the measurement request to a complete memory page and sends the request to the secure world through the shared memory method.

Preferably, the measurement service driver module includes: the scheduler creates a corresponding number of threads according to the total number of virtual CPUs of all SPs in the secure world, and the scheduling of these threads is completed by the scheduler of Linux itself; when a thread is scheduled, the thread calls the ABI related to scheduling in FF-A and transfers its own CPU resources to the corresponding virtual machine CPU in the secure world.

Preferably, the address translation module includes: maintaining a queue in the address translation module, storing the hash values of the requests that have been translated and mapped, and arranging the order of the last execution according to this request. When a new measurement request is received and the hash value corresponding to this request cannot be found in the queue, subsequent operations such as translation and mapping are performed, and a handle is allocated for this measurement request to indicate to the measurement execution module which part of its own virtual address space the memory related to this request is mapped to. Otherwise, no repeated translation and mapping operations are performed, and the corresponding handle is found according to the hash value of the measurement request, and subsequent operations are performed directly.

Preferably, the address translation module needs to be combined with other modules to obtain registers related to address translation;

This system uses additional general registers to temporarily store the required registers and then pass them to the secure world; in EL3, the firmware is modified to recognize the Magic Code in the ABI, and the relevant registers are passed to the secure world only when the current interface is related to the measurement service.

Preferably, the measurement execution module provides three different dimensional measurement methods to determine whether the current system is in a safe state:

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

2) Calculate the permission bits of the specified virtual address in the second-stage page table;

3) Check and monitor the sharing status of physical addresses.

Preferably, the measurement request needs to have a field to store the hash value of the request; by adopting the FirstIn, FirstOut strategy, a queue is maintained in the address translation module to store the hash values of the requests that have completed translation and mapping, and the requests are arranged in the order of the last execution of the requests;

When a new measurement request is received and the hash value corresponding to this request cannot be found in the queue, subsequent operations such as translation and mapping are performed, and a handle is allocated for this measurement request to indicate to the measurement execution module which part of its own virtual address space the memory related to this request is mapped to; otherwise, no repeated translation and mapping operations are performed, and the corresponding handle is found according to the hash value of the measurement request, and subsequent operations are performed directly.

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

Cloud platform startup process, virtual machine startup process, request transmission process, address translation process, measurement execution process, and measurement result verification process;

The cloud platform startup process includes:

Step 1) The hardware platform manufacturer generates the public and private keys of the EK;

Step 2) The hardware platform manufacturer places the public key of the EK in the security verifier; usually the security verifier is a service provided by the hardware platform manufacturer to the outside world;

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

Step 4) The 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 the privacy information therein is not leaked; if the startup fails, jump to step 6); otherwise, proceed to the next step;

Step 5) The startup is successful and the user's virtual machine can be deployed therein;

Step 6) Creation failed, there was an exception or attack during the process;

The virtual machine startup process includes:

Step 1) The user uploads his own virtual machine image to the platform, starts the virtual machine itself, and initializes the measurement service driver;

Step 2) After the virtual machine is started, it requests the secure world to generate an AK for subsequent measurement;

Step 3) The secure world receives the AK generation request, generates the public and private keys of the AK, and binds the key pair to 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 correctness of the signature of the AK generation result. If the verification fails, jump to step 7), otherwise proceed to the next step;

Step 5) The virtual machine verifier stores the public key of AK to verify the correctness of the subsequent measurement results;

Step 6) The virtual machine startup phase ends and can respond to subsequent measurement requests;

Step 7) Startup failure;

The request delivery process includes:

Step 1) The user who wants to initiate the measurement obtains a specific request from the virtual machine verifier through a remote function call;

Step 2) The user initiates a request to the metric driver in the virtual machine;

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

Step 4) The secure world receives the measurement request and will perform the measurement operation;

The address translation process includes:

Step 1) SPMC preliminarily parses the obtained measurement request;

Step 2) Mapping the measurement request to the address space of the SPMC and the measurement execution module respectively;

Step 3) SPMC further parses the request and obtains address translation information;

Step 4) Mapping the memory to be measured into the address space of the measurement execution module;

Step 5) After the address is remapped, the address range in the request needs to be reconverted, and the conversion of the measurement request is performed here;

Step 6) passing the request to the measurement execution module according to the FF-A specification;

The measurement execution process includes:

Step 1) The measurement execution module parses the received measurement request;

Step 2) The measurement execution module maps the memory to be measured into its own first-level page table;

Step 3) Perform a measurement operation and a hash operation on the measured memory;

Step 4) Use the corresponding AK private key to sign the measurement result, thereby generating a verifiable measurement result;

Step 5) Return the measurement result;

The verification process of the measurement results includes:

Step 1) The user passes the measurement result to the virtual machine verifier through a remote function call;

Step 2) The virtual machine verifier verifies the correctness of the signature of the measurement result through the AK public key; if the verification fails, jump to step 6); otherwise, proceed to the next step;

Step 3) The virtual machine verifier compares the measurement results to see if the content is correct; if the verification fails, jump to step 6); otherwise, proceed to the next step;

Step 4) Return the verification result to the user;

Step 5) The measurement is successful and the integrity of the measurement target is not compromised;

Step 6) If the measurement fails, the integrity of the measurement target may be compromised.

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

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

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

1. To ensure the security of the system by using the security virtualization feature, it is necessary to borrow the existing open source software and open source software framework, configure most security-sensitive code logic in an isolated environment, and let TCB only add a limited small part of the code on the basis of the necessary part. TCB means that the probability of problems in trusted code is lower, it has higher security, and it is more likely to formally verify its security.

2. Ensure that the integrity of the measurement object can be accurately reflected and that it is compatible with a variety of different measurement objects in the cloud platform. Due to the particularity of the cloud platform, the types of measurement objects may be different and need to be customized to a certain extent according to user needs. At the same time, for users with special security requirements, they are also allowed to expand other types of measurement methods.

3. The present invention has high security, which is reflected in two aspects: the system itself is designed to be secure enough, the TCB is small enough to defend against attacks from external attackers, and the internal vulnerabilities are as few as possible; the measurement results generated are difficult to forge and their credibility can be verified.

4. The present invention can perform flexible measurement selection, and users can flexibly choose to execute measurements of different dimensions and degrees according to their own security requirements.

5. The present invention can ensure low latency and high real-time performance. While ensuring that the measurement system can provide measurement results with high security, it is optimized as much as possible according to the characteristics of the existing hardware platform to achieve low latency and high real-time performance.

Other beneficial effects of the present invention will be explained in the specific implementation manner through the introduction of specific technical features and technical solutions. Through the introduction of these technical features and technical solutions, those skilled in the art should be able to understand the beneficial technical effects brought about by the technical features and technical solutions.

BRIEF DESCRIPTION OF THE DRAWINGS

Other features, objects and advantages of the present invention will become more apparent from the detailed description of non-limiting embodiments made with reference to the following drawings:

Fig. 1 is a schematic diagram of the system of the present invention;

Figure 2 is a schematic diagram of the cloud platform startup process;

FIG3 is a schematic diagram of a virtual machine startup process;

FIG4 is a schematic diagram of a request transmission process;

FIG5 is a schematic diagram of the address translation process;

FIG6 is a schematic diagram of the measurement execution process;

FIG7 is a schematic diagram of the verification process of the measurement results.

DETAILED DESCRIPTION

The present invention is described in detail below in conjunction with specific embodiments. The following embodiments will help those skilled in the art to further understand the present invention, but are not intended to limit the present invention in any form. It should be noted that, for those of ordinary skill in the art, several changes and improvements can also be made without departing from the concept of the present invention. These all belong to the protection scope of the present invention.

The embodiment of the present invention provides a lightweight trusted measurement system based on a trusted execution environment. As shown in FIG1 , the system effectively reduces the size of the trusted code segment by utilizing a multi-level collaborative architecture, providing the possibility for deep performance optimization; uses extensible and customized measurements, and can measure various types of virtual machine images and most system components in the cloud platform; provides configurable targeted optimization, and optimizes execution performance according to the particularity of the cloud platform scenario and the characteristics of Arm hardware to achieve low latency and high availability. Experimental results show that the system can effectively utilize new hardware features to perform low-latency measurements on various types of virtual machines with smaller trusted code segments and ensure the security of the measurement results.

The specific device embodiment of the present invention is shown in Figure 1. Software in the ordinary world is usually customized by cloud platform service providers according to their own business needs. The present invention gives an example here. In the ordinary world, EL2 runs a Hypervisor provided by the cloud platform to manage the user's virtual machine; several virtual machines are running under it, and various user-defined applications and services are running on it; if the user wants to enable the measurement service to ensure the integrity of his virtual machine, he needs to add a measurement service driver in his virtual machine to accept measurement requests sent by user state or other modules in the kernel, and initiate measurement requests to the measurement system. For example, under Linux, it is a kernel module.

In the secure world, SPMD plays the role of EL3 firmware, responsible for executing the configuration and management of the highest permissions, and verifying the communication requests between the two worlds; SPMC is responsible for managing multiple SPs running under it; the address translation module runs in EL2 like SPMC, responsible for translating the virtual address of the measurement object into a physical address and mapping it to the address space of the SP that performs the measurement calculation; the measurement execution module is designed as an SP running in EL1, which performs almost all calculation operations and related cryptographic operations in the measurement process.

The specific implementation of each module in the present invention:

Metrics service driver module:

Since SMC Call requires the software to run at least at the EL1 privilege level to call, it is impossible to directly initiate a measurement request at EL0, i.e., the application layer. In order to meet compatibility requirements, it is necessary to minimize the modification of the operating system. Most modern operating systems support dynamic expansion of kernel functions by adding system kernel modules, which provides the possibility of executing privileged code without modifying the operating system kernel. The present invention writes a system kernel module for Linux as an example of a measurement service driver, and dynamically adds it to a virtual machine as the starting point for a measurement request.

The measurement service driver mainly plays two roles. The most important one is to accept measurement requests from the application layer and send them to the secure world through SMC Call. Secondly, in order to enable other types of SPs in the secure world to run normally, a simple scheduler is also implemented to periodically transfer CPU resources from the normal world to the secure world.

In order to enable the measurement service driver running in the kernel state to receive messages from the application layer, the present invention creates a string device when the kernel module is initialized, and uses Input Output ConTroL (ioctl) to expose the relevant interface to the user state. The user state program can use the functions provided by the measurement service driver by opening the corresponding string device and using the ioctl related system call. After receiving the request from the user state, the measurement service driver will write the measurement request to a complete memory page and send the request to the secure world through the shared memory method.

The scheduler will create a corresponding number of threads according to the total number of virtual CPUs of all SPs in the secure world. The scheduling of these threads is done by the Linux scheduler itself. When a thread is scheduled, it will call the scheduling-related ABI in FF-A to transfer its own CPU resources to the corresponding virtual machine CPU in the secure world.

Address translation module:

The address translation module is designed to run at the EL2 level in the secure world like SPMC. It is responsible for preliminary parsing of requests, translating relevant addresses, and mapping relevant memory pages to the measurement execution module. In order to reduce the overhead required for address translation, a queue is maintained in the address translation module to store the hash values of requests that have been translated and mapped, and arranged in the order of the last execution of this request. When a new measurement request is received and the hash value corresponding to this request cannot be found in the queue, subsequent operations such as translation and mapping are performed, and a handle is allocated for this measurement request to indicate to the measurement execution module which part of its own virtual address space the memory related to this request is mapped. Otherwise, no repeated translation and mapping operations are performed, and the corresponding handle is found according to the hash value of the measurement request, and subsequent operations are performed directly.

It is also necessary to combine other modules to obtain registers related to address translation. When measuring a virtual machine running at the EL1 privilege level in the normal world, it is necessary to access two stages of page tables, namely the first stage page table, which converts the virtual address of the virtual machine into an indirect physical address and is configured by the virtual machine itself; the second stage page table, which converts the indirect physical address into a physical address and is configured by the Hypervisor. However, in the current system, both SPMC and Hypervisor run at EL2, and both need to configure the second stage page table, and the names of the page table registers used are the same. From the perspective of the Hypervisor, there is a set of registers used to configure the second stage page table of the virtual machine, but from the perspective of the SPMC, this set of registers is used to configure the second stage page table of the SP's non-secure memory. In the current implementation of the TF-A firmware running in EL3, the values of this set of registers will also be switched when the world is switched, resulting in the SPMC being unable to access the second stage page table of the virtual machine normally. Therefore, the present invention uses additional general registers to temporarily store the required registers and then pass them to the secure world. However, not all interactions between the two worlds require the temporary storage of this set of registers, because this may bring additional information transmission and increase the potential risk of information leakage. Therefore, in EL3, the present invention modifies the firmware so that it can recognize the Magic Code in the ABI, and only when the current interface is related to the measurement service will the relevant registers be passed to the secure world.

Metrics execution module:

The measurement execution module is designed to run at the EL1 level in the secure world managed by SPMC. In order to ensure the completeness of the measurement results, so that users have sufficient reasons to determine whether the current system is in a secure state after obtaining the measurement results, we provide three different dimensions of measurement:

Calculate the hash value of the data in the virtual address corresponding to the static data. In the early measurement system and the currently commonly used secure boot technology, it is necessary to calculate the hash value of the software image and report it to the user, so that the user can determine whether the system he wants to run is running on the target machine. However, only measuring the image before the operating system is started cannot reflect the security status of the operating system at runtime. We borrow this idea and support the measurement of static data at runtime. At the same time, in order to adapt to as many operating systems as possible, the virtual address where the static data is actually loaded needs to be specified by the owner of the virtual machine by generating a measurement request with bytes as the granularity. This method places certain requirements on the user's own operating system level, because they need to be able to know which data on the virtual address is security-sensitive and have a certain level of programming to generate such a measurement request. For ease of use, we provide some tools to assist users in using it, and the measurement request can also be generated by the operating system developer and used by multiple users. The address translation module will translate all virtual addresses in the measurement request that need to calculate the hash value into physical addresses, and map them to the address space of the measurement execution module, and then the measurement execution module will calculate them. The measurement system passes the hash value after signing, and users can judge the security status of the system based on whether the hash value meets expectations.

Calculate the permission bits of the specified virtual address in the two-stage page table. Some data will be modified dynamically at runtime, and it is difficult to simply reflect whether it is safe through a hash value. We have observed that the permission bits of some data on the page table always have specific properties. For example, the code segment in the operating system generally always has executable permissions but not writable permissions. Which pages require what type of permission check is also determined by the user, also at the byte granularity, and passed to the measurement system via the measurement service driver. If this dimension of measurement is enabled, the address translation module will also map the physical address of the relevant page table to the address space of the measurement execution module, and the measurement execution module will perform the relevant checks.

Check and monitor the sharing status of physical addresses. With the above two measurement methods, the integrity of the system can be guaranteed to a certain extent. However, based on the FF-A specification, the sharing status of physical addresses between multiple SPs can be further protected. SPs can require the measurement system to return the sharing status of certain physical addresses in the results, or require the measurement system to ensure that certain physical addresses are always in a certain sharing state. For example, if an SP wants to achieve a certain degree of private storage so that a certain block of memory will not be shared with other SPs by attackers, it can entrust the measurement system to monitor the sharing status of this memory. When SPs perform memory sharing operations, the measurement system will ensure that these operations do not violate the pre-established sharing rules. Since physical addresses do not have any availability guarantees and do not have scheduling capabilities, the illegal operations cannot be notified to the corresponding SP in time. The only thing to do is to attach relevant information in the measurement report when the SP requests measurement next time. Secondly, the attacker may forge the behavior of the SP to cancel the protection of the memory. The measurement system will save the relevant behavior and inform the user together with the measurement report. This measurement method is implemented by SPMC because SPMC is responsible for the memory sharing and isolation of SPs. In addition, since the secure world does not have privileged relationships with the hypervisor, this integrity protection does not apply to virtual machines in the normal world. However, if the hypervisor in the normal world complies with the FF-A standard, this protection method can be easily migrated to the hypervisor.

There needs to be a field in the measurement request to store the hash value of this request. By adopting the First In, First Out strategy, a queue is maintained in the address translation module to store the hash values of the requests that have been translated and mapped, and they are arranged in the order of the last execution of this request. When a new measurement request is received and the hash value corresponding to this request cannot be found in the queue, subsequent operations such as translation and mapping are performed, and a handle is allocated for this measurement request to indicate to the measurement execution module which part of its virtual address space the memory related to this request is mapped to. Otherwise, no repeated translation and mapping operations are performed, and the corresponding handle is found according to the hash value of the measurement request, and subsequent operations are performed directly.

Performing a linear scan of the memory of the measurement object and calculating the hash is also a time-consuming operation. Our solution is to use some fast but less secure hash algorithms mixed with more secure algorithms. More specifically, when users periodically request the measurement system to perform measurements, a time threshold can be configured. This time threshold requires the measurement system to perform a measurement operation using a strong security hash algorithm within a specified time range. Measurement requests executed during this period will use a low-security hash algorithm. If a measurement fails, the second measurement will always use a more secure algorithm. Currently, for the low-security hash algorithm, we select the memory to be measured XORed with a certain step size and accelerated by Arm Scalable Vector Extension (SVE); for the high-security hash algorithm, we use the SHA-256 algorithm provided by MbedTLS. This optimization will inevitably make the current measurement report unable to safely reflect the integrity of the measurement object itself, resulting in an increased probability of false negatives, so we also provide a configuration option to allow users to turn off this optimization.

Trusted communication protocol:

Once data flows out of the secure world, it may be attacked, maliciously stolen, and tampered with. Therefore, we designed a trusted communication protocol based on an asymmetric encryption algorithm to ensure that the measurement results are authentic and valid, so that the communication between the components in the measurement system is credible, and each component can determine that the source of the message is secure. For the sake of simplicity, this article introduces the communication protocol for the virtual machine measurement process in the ordinary world. Without loss of generality, this protocol can also be applied when measuring other components, but there are slight changes in the implementation details. 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 can correctly generate random numbers and that the software in the secure world can reliably obtain a timestamp. The following are the entities involved in the communication in this communication protocol:

Secure world: For simplicity, all components in the secure world are abstracted as a community. Since the secure world is parallel to the ordinary world, it is more like a coprocessor and plays a role similar to that of a TPM chip.

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

Virtual machine verifier: The owner of a virtual machine in the ordinary world, or a trusted third party entrusted by the owner, needs to provide proof for a certain measurement result of the virtual machine;

Challenger: The initiator of the measurement request wants to know the integrity of the virtual machine before using a service running on the virtual machine.

To make the situation more concise, it is stipulated here that the communication between any entity and the security verifier and the virtual machine verifier is trusted, because this can be guaranteed by distributing public keys in advance. In addition, the migration of virtual machines is not considered, because trusted migration can be implemented in an orthogonal form. The basis of our communication protocol is an asymmetric encryption algorithm, which involves a total of two pairs of public and private keys, namely: Endorsement Key (EK), whose private key is stored in the secure world and is used to prove the identity and integrity of the hardware platform itself; Attestation Key (AK), whose private key is also stored in the secure world, and a different AK will be used for each virtual machine. The details of the specific interactions between the entities will be explained in the subsequent process embodiments.

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

The specific implementation process of the technical solution in the present invention includes a cloud platform startup process, a virtual machine startup process, a request transmission process, an address translation process, a measurement execution process, and a measurement result verification process.

As shown in FIG. 2 , the cloud platform startup process includes:

Step 1) The hardware platform manufacturer privately generates the public and private keys of the EK.

Step 2) The hardware platform manufacturer places the public key of the EK in the security verifier; usually the security verifier is a service provided by the hardware platform manufacturer to the outside world.

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

Step 4) The 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 the private information therein is not leaked. If the startup fails, jump to step 6; otherwise, proceed to the next step.

Step 5) The startup is successful and the user's virtual machine can be deployed therein.

Step 6) Creation failed. There was an exception during the process or it may be attacked.

As shown in FIG. 3 , the virtual machine startup process includes:

Step 1) The user uploads his own virtual machine image to the platform and starts the virtual machine itself, during which the measurement service driver is initialized.

Step 2) After the virtual machine is started, it requests the secure world to generate an AK for subsequent measurement.

Step 3) The secure world receives the AK generation request, generates the public and private keys of the AK, and binds this pair of keys to 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 correctness of the signature of the AK generation result. If the verification fails, jump to step 7, otherwise proceed to the next step.

Step 5) The virtual machine verifier stores the public key of AK to verify the correctness of the subsequent measurement results.

Step 6) The virtual machine startup phase ends and can respond to subsequent measurement requests.

Step 7) Startup failed.

As shown in FIG4 , the request delivery process includes:

Step 1) A user who wants to initiate a measurement obtains a specific request from the virtual machine verifier through a remote function call.

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

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

Step 4) The secure world receives the measurement request and will perform the measurement operation.

As shown in FIG5 , the address translation process includes:

Step 1) SPMC initially parses the obtained measurement request.

Step 2) Map the measurement request to the address space of SPMC and measurement execution module respectively.

Step 3) SPMC further parses the request and obtains address translation information.

Step 4) Map the memory to be measured into the address space of the measurement execution module.

Step 5) After the address is remapped, the address range in the request needs to be reconverted, and the conversion of the measurement request is performed here.

Step 6) Pass the request to the measurement execution module according to the FF-A specification.

As shown in FIG6 , the measurement execution process includes:

Step 1) The measurement execution module parses the received measurement request.

Step 2) The measurement execution module maps the memory to be measured into its own first-level page table.

Step 3) performs measurement operations, mainly hash operations on the measured memory.

Step 4) Use the corresponding AK private key to sign the measurement result, thereby generating a verifiable measurement result.

Step 5) Return the measurement result.

As shown in FIG. 7 , the verification process of the measurement result includes:

Step 1) The user passes the measurement result to the virtual machine verifier through a remote function call.

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

Step 3) The virtual machine verifier compares the measurement results to see if they are correct. If the verification fails, jump to step 6; otherwise, proceed to the next step.

Step 4) Return the verification result to the user.

Step 5) The measurement is successful and the integrity of the measurement target is not compromised.

Step 6) If the measurement fails, the integrity of the measurement target may be compromised.

The core innovation of the present invention is: 1: Utilizing the characteristics of secure virtualization hardware to further ensure system security.

Subordinate Innovation 1.1: Use a multi-level collaborative architecture and make as few modifications as possible to the core security modules to reduce the size of the overall TCB.

Innovation point 1.2: Perform address translation through SPMC to improve code reusability and ensure overall security.

Core innovation 2: Accurately reflects the integrity of the measurement object and is compatible with a variety of different measurement objects in the cloud platform.

Subordinate innovation point 2.1: Support different types of measurement content and measurement methods to ensure the security of users in the cloud platform.

Subordinate innovation 2.2: Support dynamic changes in measurement requests to ensure security over long periods of time.

Subordinate Innovation 2.3: A trusted communication protocol is designed to prevent man-in-the-middle attacks.

Core innovation point 3: Reduce latency and improve availability based on hardware and scenario specificity.

Subordinate Innovation 3.1: Reduce the length of the measurement request transmission path through multi-level collaborative design.

Subordinate Innovation Point 3.2: Support configurable mixing of different hash algorithms for calculation.

Subordinate Innovation 3.3: Use queues to avoid repeated address mapping operations.

The embodiment of the present invention provides a lightweight trusted measurement system and method based on a trusted execution environment, which uses the characteristics of secure virtualization to ensure the security of the system, and uses existing open source software and open source software frameworks to configure most security-sensitive code logic in an isolated environment, so that TCB only adds a limited small part of the code on the basis of the necessary part. Through flexible design, the integrity of the measurement object is accurately reflected, and it is compatible with a variety of different measurement objects in the cloud platform, and the security of data flow is guaranteed. While ensuring that the measurement system can provide measurement results with higher security, performance optimization is performed based on the particularity of the cloud platform scenario and the hardware platform currently used by the present invention.

Those skilled in the art know that, in addition to realizing the system and its various devices, modules, and units provided by the present invention in a purely computer-readable program code, it is entirely possible to realize the same functions in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers by logically programming the method steps. Therefore, the system and its various devices, modules, and units provided by the present invention can be considered as a hardware component, and the devices, modules, and units included therein for realizing various functions can also be regarded as structures within the hardware component; the devices, modules, and units for realizing various functions can also be regarded as both software modules for realizing the method and structures within the hardware component.

The above describes the specific embodiments of the present invention. It should be understood that the present invention is not limited to the above specific embodiments, and those skilled in the art can make various changes or modifications within the scope of the claims, which does not affect the essence of the present invention. In the absence of conflict, the embodiments of the present application and the features in the embodiments can be combined with each other arbitrarily.

Claims (6)

1. A lightweight trusted measurement system based on a trusted execution environment, comprising: Metrics service driver module: accepts metrics requests from the application layer and sends them to the secure world through SMC Call; and sets up a scheduler to periodically transfer CPU resources from the normal world to the secure world; Address translation module: Designed at the EL2 level in the secure world, it is responsible for preliminary parsing of requests, translating relevant addresses, and mapping relevant memory pages to the measurement execution module; Measurement execution module: designed to run at EL1 level in the secure world managed by SPMC; Trusted communication protocol: Based on asymmetric encryption algorithms, it ensures that the measurement results are authentic and valid, making the communication between components in the measurement system trustworthy, and each component can determine the security of the source of the message; The measurement service driver module includes: An example of writing a system kernel module in Linux as a measurement service driver is given, which is dynamically added to the virtual machine as the initiation point of the measurement request. When the kernel module is initialized, a string device is created and ioctl is used to expose the relevant interface to the user state. The user state program opens the corresponding string device and uses the ioctl related system calls to use the functions provided by the measurement service driver. After receiving the request from the user state, the measurement service driver writes the measurement request to a complete memory page and sends the request to the secure world through the shared memory method. The metric service driver module includes: the scheduler creates a corresponding number of threads according to the total number of virtual CPUs of all SPs in the secure world, and the scheduling of these threads is completed by the scheduler of Linux itself; when a thread is scheduled, the thread calls the ABI related to scheduling in FF-A to transfer its own CPU resources to the corresponding virtual machine CPU in the secure world; The address translation module needs to be combined with other modules to obtain registers related to address translation; Use additional general registers to temporarily store the required registers and then pass them to the secure world; in EL3, modify the firmware to recognize the Magic Code in the ABI, and only pass the relevant registers to the secure world when the current interface is related to the measurement service; The measurement execution module provides three different dimensional measurement methods to determine whether the current system is in a safe state: 1) Calculate the hash value of the data in the virtual address corresponding to the static data; 2) Calculate the permission bits of the specified virtual address in the second-stage page table; 3) Check and monitor the sharing status of physical addresses. 2. According to claim 1, the lightweight trusted measurement system based on the trusted execution environment is characterized in that the address translation module includes: maintaining a queue in the address translation module to store the hash values of the requests that have been translated and mapped, and arranging the order of the last execution according to this request; when a new measurement request is received and the hash value corresponding to this request cannot be found in the queue, subsequent operations such as translation and mapping are performed, and a handle is allocated for this measurement request to indicate to the measurement execution module which part of its own virtual address space the memory related to this request is mapped to; otherwise, no repeated translation and mapping operations are performed, the corresponding handle is found according to the hash value of the measurement request, and subsequent operations are performed directly. 3. According to claim 1, the lightweight trusted measurement system based on the trusted execution environment is characterized in that the measurement request needs to have a field to store the hash value of the request; by adopting the FirstIn, FirstOut strategy, a queue is maintained in the address translation module to store the hash values of the requests that have completed translation and mapping, and the hash values are arranged in the order of the last execution of the request; When a new measurement request is received and the hash value corresponding to this request cannot be found in the queue, subsequent operations such as translation and mapping are performed, and a handle is allocated for this measurement request to indicate to the measurement execution module which part of its own virtual address space the memory related to this request is mapped to; otherwise, no repeated translation and mapping operations are performed, and the corresponding handle is found according to the hash value of the measurement request, and subsequent operations are performed directly. 4. A lightweight trusted measurement method based on a trusted execution environment, characterized in that the lightweight trusted measurement system based on a trusted execution environment according to any one of claims 1 to 3 includes: a cloud platform startup process, a virtual machine startup process, a request transmission process, an address translation process, a measurement execution process, and a measurement result verification process; The cloud platform startup process includes: Step 1) The hardware platform manufacturer generates the public and private keys of the EK; Step 2) The hardware platform manufacturer places the public key of the EK in the security verifier; usually the security verifier is a service provided by the hardware platform manufacturer to the outside world; Step 3) The hardware platform manufacturer places the EK’s private key in the software image of the secure world in a secure and private manner; Step 4) The 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 the privacy information therein is not leaked; if the startup fails, jump to step 6); otherwise, proceed to the next step; Step 5) The startup is successful and the user's virtual machine can be deployed therein; Step 6) Creation failed, there was an exception or attack during the process; The virtual machine startup process includes: Step 1) The user uploads his own virtual machine image to the platform, starts the virtual machine itself, and initializes the measurement service driver; Step 2) After the virtual machine is started, it requests the secure world to generate an AK for subsequent measurement; Step 3) The secure world receives the AK generation request, generates the public and private keys of the AK, and binds the key pair to 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 correctness of the signature of the AK generation result. If the verification fails, jump to step 7), otherwise proceed to the next step; Step 5) The virtual machine verifier stores the public key of AK to verify the correctness of the subsequent measurement results; Step 6) The virtual machine startup phase ends and can respond to subsequent measurement requests; Step 7) Startup failure; The request delivery process includes: Step 1) The user who wants to initiate the measurement obtains a specific request from the virtual machine verifier through a remote function call; Step 2) The user initiates a request to the metric driver in the virtual machine; Step 3) The virtual machine driver sends the request directly to the secure world via smccall; Step 4) The secure world receives the measurement request and will perform the measurement operation; The address translation process includes: Step 1) SPMC preliminarily parses the obtained measurement request; Step 2) Mapping the measurement request to the address space of the SPMC and the measurement execution module respectively; Step 3) SPMC further parses the request and obtains address translation information; Step 4) Mapping the memory to be measured into the address space of the measurement execution module; Step 5) After the address is remapped, the address range in the request needs to be reconverted, and the conversion of the measurement request is performed here; Step 6) passing the request to the measurement execution module according to the FF-A specification; The measurement execution process includes: Step 1) The measurement execution module parses the received measurement request; Step 2) The measurement execution module maps the memory to be measured into its own first-level page table; Step 3) Perform a measurement operation and a hash operation on the measured memory; Step 4) Use the corresponding AK private key to sign the measurement result, thereby generating a verifiable measurement result; Step 5) Return the measurement result; The verification process of the measurement results includes: Step 1) The user passes the measurement result to the virtual machine verifier through a remote function call; Step 2) The virtual machine verifier verifies the correctness of the signature of the measurement result through the AK public key; if the verification fails, jump to step 6); otherwise, proceed to the next step; Step 3) The virtual machine verifier compares the measurement results to see if the content is correct; if the verification fails, jump to step 6); otherwise, proceed to the next step; Step 4) Return the verification result to the user; Step 5) The measurement is successful and the integrity of the measurement target is not compromised; Step 6) If the measurement fails, there is a possibility that the integrity of the measurement target will be compromised. 5. A computer-readable storage medium storing a computer program, characterized in that when the computer program is executed by a processor, the steps of the lightweight trusted measurement method based on a trusted execution environment described in claim 4 are implemented. 6. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the steps of the lightweight trusted measurement method based on a trusted execution environment as described in claim 4.