Trustworthy measurement system and related methods and apparatus
By combining the trusted measurement subsystem and the trusted platform control module, proactive measurement and control are achieved, solving the problem of measurement subject transmission, improving the security and trustworthiness of the system, and ensuring the integrity and dynamic measurement of the object to be measured.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- XFUSION DIGITAL TECH CO LTD
- Filing Date
- 2021-02-25
- Publication Date
- 2026-05-15
AI Technical Summary
Existing trusted measurement systems suffer from problems with measurement subject transmission, resulting in low security, inability to achieve dynamic measurement, and vulnerability to attack when UEFI is used as a measurement proxy, thus affecting system security.
The system employs a combination of a trusted measurement subsystem and a trusted platform control module. The trusted platform control module actively performs measurements, avoiding the transfer of measurement subjects and control rights. It uses a protocol module and a requirement execution module to obtain the data to be measured, and then controls it through a control response module, thereby achieving proactive measurement and control.
This enhances system security, prevents the transfer of measurement subjects and control rights, enables dynamic measurement, ensures timely detection when the object to be measured has not been tampered with, and strengthens the system's credibility and security.
Smart Images

Figure CN114969748B_ABST
Abstract
Description
Technical Field
[0001] The embodiments of this application relate to the field of trusted computing technology, and in particular to a trusted measurement system and related methods and devices. Background Technology
[0002] Trusted computing, as a new development direction in the field of information security, is receiving increasing attention from companies and research institutions. The main goal of trusted computing is to build a computing environment that users can anticipate, thereby ensuring that computing resources are not maliciously tampered with or stolen, guaranteeing the integrity of systems and applications, and thus ensuring that the system or software operates in a predictable and trustworthy state. Trust and security are complementary; trust is the foundation of security.
[0003] Trusted metrics can perform integrity checks on the object to be measured before running firmware code, ensuring that the object has not been tampered with. However, trusted metrics suffer from the problem of passing the measurement subject, which affects security. Summary of the Invention
[0004] This application discloses a trust measurement system and related methods and devices, which can improve the security between electronic devices.
[0005] The first aspect of this application discloses a trusted measurement system applied in an electronic device. The trusted measurement system includes a trusted measurement subsystem and a trusted platform control module. The trusted measurement subsystem acquires the measurement data of the object to be measured in the electronic device, and the trusted platform control module generates measurement results based on the measurement data. The trusted measurement subsystem includes a trusted platform control module interface, a protocol module, and a requirement execution module. The trusted platform control module interface is connected to the protocol module and the trusted platform control module in the electronic device, and the protocol module is connected to the requirement execution module. The trusted platform control module interface communicates with the trusted platform control module. The protocol module handles the communication protocol between the trusted measurement subsystem and the trusted platform control module. The requirement execution module acquires the measurement data of the object to be measured in the electronic device.
[0006] This application's embodiments can solve the problem of measurement subject transmission in proactive measurement, avoiding the trusted measurement subsystem acting as a measurement proxy, reducing the number of measurement subjects, and the trusted measurement subsystem, as basic firmware, does not undertake measurement or verification tasks; the trusted platform control module actively performs measurement and control, thereby improving the security of the entire system. By adopting this technical solution, the trusted measurement subsystem does not undertake measurement and verification tasks, thereby reducing the number of measurement subjects and the transmission of control rights, and improving the security of the entire system. The trusted measurement subsystem obtains the measurement data of the object to be measured through the cooperation between the trusted platform control module interface, protocol module, and requirement execution module.
[0007] In some optional implementations, the Trusted Platform Control Module interface includes a device driver part and a transceiver interface function abstraction part. The device driver part is used to realize communication between the Trusted Measurement Subsystem and the Trusted Platform Control Module, and the transceiver interface function abstraction part is used to shield the differences between different hardware device drivers in the device driver part.
[0008] By adopting this technical solution, a trusted platform control module interface can be implemented, shielding the differences between different hardware device drivers in the device driver section.
[0009] In some optional implementations, the protocol module includes a protocol parsing submodule and a protocol packet encapsulation submodule. The protocol parsing submodule is used to parse the protocol structure of the protocol sent by the trusted measurement subsystem and to verify the protocol content of the protocol sent by the trusted measurement subsystem. The protocol packet encapsulation submodule is used to encapsulate the data to be measured.
[0010] By adopting this technical solution, protocol parsing and measurement data encapsulation can be achieved, facilitating the acquisition of data to be measured and the sending of control requests. The trusted platform control module interacts with the trusted measurement subsystem via the protocol, allowing for the addition of content to be measured and other functions by extending the protocol, thereby improving scenario adaptability.
[0011] In some optional implementations, the demand execution module includes multiple execution sub-modules, which are used to initialize the object to be measured and read the data to be measured from the object to be measured.
[0012] By adopting this technical solution, different execution sub-modules correspond to different objects to be measured, which can realize the initialization of different objects to be measured and the reading of the data to be measured for different objects to be measured.
[0013] In some optional implementations, in response to a measurement request from the Trusted Platform Control Module, the Trusted Measurement Subsystem performs trusted measurement, including: the Trusted Platform Control Module interface receiving the measurement request from the Trusted Platform Control Module; the Protocol Module determining the object to be measured corresponding to the measurement request based on the measurement request; the Requirement Execution Module obtaining the data to be measured based on the object to be measured; the Protocol Module encapsulating the data to be measured; and the Trusted Platform Control Module interface sending the encapsulated data to be measured to the Trusted Platform Control Module.
[0014] By adopting this technical solution, the trusted measurement subsystem does not undertake measurement and verification tasks, thereby reducing the measurement subject and the transfer of control, and improving the security of the entire system. Through the cooperation between the trusted platform control module interface, protocol module, and requirement execution module, the data to be measured for the object can be obtained. Furthermore, dynamic measurement of the object can be achieved based on dynamic measurement requests from the trusted platform control module.
[0015] In some alternative implementations, the trust measurement subsystem also includes a control response module for controlling the controlled object in the electronic device according to the control type.
[0016] By adopting this technical solution, the trust measurement subsystem can achieve control over the object to be controlled.
[0017] In some optional implementations, the trusted measurement subsystem executes the control request from the trusted platform control module, including: the trusted platform control module interface receiving the control request from the trusted platform control module; the protocol module determining the object to be controlled and the control type corresponding to the control request based on the control request; and the control response module controlling the object to be controlled based on the control type.
[0018] By adopting this technical solution, the trust measurement subsystem can achieve control over the object to be controlled.
[0019] In some alternative implementations, the Trusted Platform Control Module is connected to the Trusted Metrics Subsystem, which includes a Trusted Metrics Subsystem interface and an engine.
[0020] In some optional implementations, the trusted platform control module initiates proactive measurement, including: obtaining a measurement policy; sending a measurement request to the trusted measurement subsystem according to the measurement policy; receiving the data to be measured returned by the trusted measurement subsystem; and generating a measurement result based on the data to be measured.
[0021] By adopting this technical solution, the trusted platform control module can proactively measure the object to be measured, avoiding interference from the measurement subject and thus improving the security of the entire system. Furthermore, the trusted platform control module can dynamically measure the object to be measured, preventing situations where the object has been updated or tampered with without the trusted platform control module's timely detection.
[0022] In some optional implementations, after the trusted platform control module generates the measurement result based on the data to be measured, the trusted platform control module generates a control request through the engine based on the measurement result and the control policy; the trusted platform control module sends the control request to the trusted measurement subsystem.
[0023] By adopting this technical solution, the trusted platform control module can actively control the object to be measured, avoid the transfer of control authority, and thus improve the security of the entire system.
[0024] The second aspect of this application discloses a trusted measurement subsystem applied in an electronic device. The trusted measurement subsystem includes a trusted platform control module interface, a protocol module, and a requirement execution module. The trusted platform control module interface is connected to the protocol module and the trusted platform control module in the electronic device; the protocol module is connected to the requirement execution module; the trusted platform control module interface communicates with the trusted platform control module; the protocol module is used to handle the communication protocol between the trusted measurement subsystem and the trusted platform control module; the requirement execution module is used to obtain the measurement data of the object to be measured in the electronic device; and the trusted measurement subsystem is used to obtain the measurement data of the object to be measured in the electronic device.
[0025] The Trusted Measurement Subsystem provides the Trusted Platform Control Module with mechanisms to acquire relevant resources and execute control actions, thus providing the foundation for the Module's subject-based measurement and proactive control. The Trusted Measurement Subsystem responds to requests from the Trusted Platform Control Module through runtime services, enabling dynamic measurement of the objects to be measured. This prevents situations where the objects to be measured have been updated or tampered with, and the Trusted Platform Control Module fails to detect this in a timely manner.
[0026] In some optional implementations, the Trusted Platform Control Module interface includes a device driver part and a transceiver interface function abstraction part. The device driver part is used to realize communication between the Trusted Measurement Subsystem and the Trusted Platform Control Module, and the transceiver interface function abstraction part is used to shield the differences between different hardware device drivers in the device driver part.
[0027] In some optional implementations, the protocol module includes a protocol parsing submodule and a protocol packet encapsulation submodule. The protocol parsing submodule is used to parse the protocol structure of the protocol sent by the trusted measurement subsystem and to verify the protocol content of the protocol sent by the trusted measurement subsystem. The protocol packet encapsulation submodule is used to encapsulate the data to be measured.
[0028] In some optional implementations, the demand execution module includes multiple execution sub-modules, which are used to initialize the object to be measured and read the data to be measured from the object to be measured.
[0029] In some optional implementations, in response to a measurement request from the Trusted Platform Control Module, the Trusted Measurement Subsystem performs trusted measurement, including: the Trusted Platform Control Module interface receiving the measurement request from the Trusted Platform Control Module; the Protocol Module determining the object to be measured corresponding to the measurement request based on the measurement request; the Requirement Execution Module obtaining the data to be measured based on the object to be measured; the Protocol Module encapsulating the data to be measured; and the Trusted Platform Control Module interface sending the encapsulated data to be measured to the Trusted Platform Control Module.
[0030] In some alternative implementations, the trust measurement subsystem also includes a control response module for controlling the controlled object in the electronic device according to the control type.
[0031] In some optional implementations, the trusted measurement subsystem executes the control request from the trusted platform control module, including: the trusted platform control module interface receiving the control request from the trusted platform control module; the protocol module determining the object to be controlled and the control type corresponding to the control request based on the control request; and the control response module controlling the object to be controlled based on the control type.
[0032] The third aspect of this application discloses a trusted platform control module applied in an electronic device. The trusted platform control module includes a trusted measurement subsystem interface and an engine.
[0033] In some optional implementations, the Trusted Platform Control Module (TPM) initiates proactive measurement by: obtaining a measurement policy; sending a measurement request to the Trusted Measurement Subsystem according to the measurement policy; receiving the data to be measured returned by the Trusted Measurement Subsystem; and generating a measurement result based on the data to be measured.
[0034] In some optional implementations, after the trusted platform control module generates the measurement result based on the data to be measured, the trusted platform control module generates a control request through the engine based on the measurement result and the control policy; the trusted platform control module sends the control request to the trusted measurement subsystem.
[0035] The fourth aspect of this application discloses a trusted measurement method applied to a trusted measurement subsystem of an electronic device. The electronic device includes a trusted platform control module. The trusted measurement method includes: receiving a measurement request from the trusted platform control module; parsing the measurement request; determining the object to be measured and the execution submodule corresponding to the measurement request based on the parsed measurement request; obtaining the data to be measured based on the object to be measured through the determined execution submodule; encapsulating the data to be measured; and sending the encapsulated data to be measured to the trusted platform control module.
[0036] In some optional implementations, the trust measurement method further includes: detecting whether the current operating mode supports the mode of the Trusted Platform Control Module; if the current operating mode supports the mode of the Trusted Platform Control Module, initializing the Trusted Platform Control Module.
[0037] In some optional implementations, the trusted measurement method further includes: receiving measurement requests from the trusted platform control module through the trusted platform control module interface of the trusted measurement subsystem; implementing the trusted platform control module interface includes: initializing the device driver part of the trusted platform control module interface; establishing a low-level data transmission and reception channel between the trusted platform control module and the trusted measurement subsystem; determining the abstract part of the transmission and reception interface function based on the low-level data transmission and reception channel and the protocol characteristics of the trusted platform control module and the trusted measurement subsystem; and encapsulating the abstract part of the transmission and reception interface function to obtain the interface to be called.
[0038] In some optional implementations, after sending the packetized data to be measured to the trusted platform control module, the trusted measurement method further includes: receiving a control request from the trusted platform control module; determining the object to be controlled and the control type corresponding to the control request based on the control request; and controlling the object to be controlled based on the control type.
[0039] In some optional implementations, the measurement request is parsed by the protocol module of the trusted measurement subsystem, and the data to be measured is packaged by the protocol module, including: determining whether there is a protocol to be processed in the trusted measurement subsystem; if there is a protocol to be processed, determining whether to parse the measurement request or package the data to be measured based on the source of the protocol to be processed.
[0040] In some optional implementations, before obtaining the data to be measured based on the object to be measured through the determined execution submodule, the trusted measurement method further includes: calling the determined execution submodule through the demand execution module of the trusted measurement subsystem; determining the target path of the object to be measured based on the calling parameters; loading the driver corresponding to the object to be measured based on the target path; locating the object to be measured based on the driver corresponding to the object to be measured; and loading the object to be measured into the memory of the electronic device.
[0041] In some alternative implementations, after loading the object to be measured into the memory of the electronic device, the trusted measurement method further includes: invoking the protocol module of the trusted measurement subsystem to provide feedback on the data to be measured for the object to be measured.
[0042] The fifth aspect of this application discloses a trusted measurement method applied to a trusted platform control module of an electronic device. The electronic device includes a trusted measurement subsystem. The trusted measurement method includes: obtaining a measurement policy; sending a measurement request to the trusted measurement subsystem according to the measurement policy; receiving the data to be measured returned by the trusted measurement subsystem; and generating a measurement result based on the data to be measured.
[0043] In some optional implementations, after generating the measurement result based on the data to be measured, the trusted measurement method further includes: generating a control request based on the measurement result and control policy through the engine of the trusted platform control module; and sending the control request to the trusted measurement subsystem.
[0044] The sixth aspect of this application discloses a trusted measurement method applied to an electronic device. The electronic device includes a trusted measurement subsystem and a trusted platform control module. The trusted measurement method includes: the trusted platform control module acquiring a measurement strategy; the trusted platform control module sending a measurement request to the trusted measurement subsystem according to the measurement strategy; the trusted measurement subsystem acquiring the data to be measured of the object to be measured according to the measurement request; the trusted measurement subsystem sending the data to be measured to the trusted platform control module; and the trusted platform control module generating a measurement result based on the data to be measured.
[0045] In some optional implementations, after the trusted platform control module generates the measurement result based on the data to be measured, the trusted measurement method further includes: the trusted platform control module generating a control request based on the measurement result and the control policy; the trusted measurement subsystem receiving the control request from the trusted platform control module; the trusted measurement subsystem determining the object to be controlled and the control type corresponding to the control request based on the control request; and the trusted measurement subsystem controlling the object to be controlled based on the control type.
[0046] The seventh aspect of this application discloses an electronic device, including a processor and a memory; the memory is used to store instructions; the processor is used to call the instructions in the memory to cause the electronic device to run a trust measurement system, or to cause the electronic device to execute a trust measurement subsystem, or to cause the electronic device to execute a trust platform control module, or to cause the electronic device to execute a trust measurement method.
[0047] The eighth aspect of this application discloses a computer-readable storage medium storing at least one instruction, which, when executed by a processor, implements a trust measurement method for a trust measurement system. Attached Figure Description
[0048] Figure 1 This is a schematic diagram of the TPCM system architecture.
[0049] Figure 2 To support the UEFI architecture of TPCM.
[0050] Figure 3 The UEFI architecture supporting TPCM provided in the embodiments of this application.
[0051] Figure 4 The TPCM interface provided in the embodiments of this application.
[0052] Figure 5 The protocol module provided in the embodiments of this application.
[0053] Figure 6 The requirement execution module provided for the embodiments of this application.
[0054] Figure 7 The measurement and control flowchart provided for embodiments of this application.
[0055] Figure 8 The flowchart shows the startup process of the trust measurement system provided in this application embodiment.
[0056] Figure 9 This is a flowchart of a PCIe device driver provided in an embodiment of this application.
[0057] Figure 10 A flowchart illustrating the protocol processing provided in this application embodiment.
[0058] Figure 11 A flowchart for preparing OSLoader metrics in the embodiments of this application.
[0059] Figure 12 This is a flowchart illustrating the OSLoader execution response provided in an embodiment of this application.
[0060] Figure 13 A schematic diagram of an electronic device provided in an embodiment of this application. Detailed Implementation
[0061] It should be noted that in the embodiments of this application, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone, where A and B can be singular or plural. The terms "first," "second," "third," "fourth," etc. (if present) in the specification, claims, and drawings of this application are used to distinguish similar objects, not to describe a specific order or sequence.
[0062] To facilitate understanding, the relevant terms are briefly explained below.
[0063] Basic Input Output System (BIOS): The BIOS is a set of firmware programs embedded on the motherboard (single board) that provide the lowest-level hardware control for electronic devices. It is responsible for hardware initialization, self-test, hardware interrupt handling, program service requests, allocating basic resources, masking hardware differences, and booting the operating system. The BIOS's role is to initialize hardware, provide software abstraction for the hardware, and boot the operating system (OS); it also performs tasks such as detection, training, and enumeration. The BIOS is written in assembly language, making its development and maintenance relatively difficult.
[0064] Unified Extensible Firmware Interface (UEFI): UEFI is an alternative to BIOS. UEFI is both a standard and the name of an implementation scheme. The non-profit organization UEFI Alliance develops and maintains the UEFI series of specifications. The implementation scheme provided according to the specifications is also referred to as UEFI. Sometimes, for ease of understanding, UEFI is also called UEFI BIOS.
[0065] Trusted Platform Control Module (TPCM): A fundamental core module that can be integrated into a trusted computing platform to establish and secure trust sources, providing functions such as proactive measurement, proactive control, trusted authentication, encryption protection, and trusted reporting for the trusted computing platform.
[0066] Trusted Cryptography Module (TCM): A hardware module of the trusted computing platform that provides cryptographic operation functions for the trusted computing platform and has protected storage space.
[0067] Trusted Platform Module (TPM): A security chip standard defined by the Trusted Computing Organization, providing cryptographic algorithms, secure storage, integrity measurement, and signature authentication.
[0068] Operating system loader (OS Boot Loader, OSLoader): A loader used to boot an operating system, including LINUX boot loader (ELILO.efi), WINDOWS OS Loader (winload.efi), X86-64 PC (BOOTX64.efi), X86-32 PC (BOOTIA32.efi), Itanium (BOOTIA64.efi), 32-bit ARM AArch32 (BOOTARM.efi), 64-bit ARM AArch64 (BOOTAA64.efi), etc.
[0069] OPROM: A piece of firmware stored on an external expansion card that is executed by the UEFI firmware during the UEFI platform initialization phase; OPROM can typically include various firmware drivers, such as VBIOS on the graphics card, the Preboot Execution Environment (PXE) boot driver for the Ethernet adapter, and the storage driver on the Redundant Array of Independent Disks (RAID) controller.
[0070] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0071] Regarding trusted computing, TPM is used internationally, while TPCM is the mainstream approach in China. TPM, as an external device to the main CPU, is booted by the BIOS, creates a root of trust, performs measurement actions, and stores the Platform Configuration Register (PCR) and logs. It uses a top-down measurement approach, requiring the upper-level operating system or application to check the measurement results. TPCM, used domestically, is a dual-system approach. TPCM differs fundamentally from TPM, and these differences will be discussed below.
[0072] The Trusted Computing (TPM) standard, spearheaded by Intel and Microsoft, operates in a "passive" mode. The TPM is a common external device on the platform. For Intel x86, the TPM typically connects to the computer motherboard's southbridge (ICH, PCH) via interfaces such as Serial Peripheral Interface (SPI), Low Pin Count Bus (LPC), or Inter-Integrated Circuit (I2C). During the computer's power-on process, the CPU starts and executes before the TPM, initializing the northbridge and memory, then the southbridge, and finally the TPM. After startup, the TPM utilizes its provided trusted storage root, trusted report root, trusted measurement root, cryptographic algorithms, and PCR, along with the BIOS, to provide trusted computing support for the platform. Relative to the CPU, the TPM is an external device operating in a "passive" mode; if the BIOS is compromised early on, the TPM's protection can be bypassed.
[0073] To address the shortcomings of the "passive" mode of TPM (Total Productive Maintenance), TPCM (Trusted Computing Management) was proposed. The TPCM standard operates in an "active" mode. The core idea of TPCM includes: the protection component (TPCM) executes independently of the computing component, providing trusted computing platforms with trusted computing protection functions featuring proactive measurement and control. This achieves security protection while performing computation, ensuring that the computation results always match expectations, and that the entire computation process is controllable, measurable, and uninterrupted. In a trusted computing platform supported by TPCM, the TPCM should be the first component to power on and run. Throughout the platform's boot process and normal operation, the TPCM should operate independently and in parallel with the host computing components, unaffected by them. It is the fundamental component supporting trusted computing functions and the source of trust for the trusted computing platform.
[0074] like Figure 1 The diagram shown is a schematic of the TPCM system architecture. Based on the core concept of TPCM, TPCM is a protective component and an active measurement and calculation component, including the active measurement BIOS, OSLoader, OPROM, and other measurement objects. TPCM is a vast system involving various components of the computer system. Because it requires the use of Chinese cryptographic algorithms, modifications are needed in areas involving cryptographic algorithms and signature verification, resulting in a very large overall scale. This case mainly focuses on the active measurement system firmware, with BIOS / OSLoader / OPROM being the most crucial parts of the system firmware.
[0075] According to TCG's TPM-related theories, the BIOS, as the main body responsible for execution measurement, accesses resources outside the BIOS Flash, such as the OSLoader and OPROM, and performs measurement actions. The TPCM actively measures the OSLoader and OPROM, requiring the BIOS system to have relevant mechanisms to respond to the TPCM's active measurement requests, sending the objects to be measured (OSLoader, OPROM, etc.) to the TPCM. The TPCM then performs the measurement and actively controls the process based on the execution policy. The BIOS performs corresponding initialization actions based on the measurement results or the TPCM's control actions.
[0076] like Figure 2 The image shows a UEFI architecture supporting TPCM. UEFI (or BIOS) is responsible for masking hardware differences and booting the OS. It is technically complex, involves a large amount of code, and, since BIOS based on Intel CPUs is subject to Intel IBV limitations, modifying UEFI has a relatively high technical threshold. For example... Figure 2As shown, after TPCM boots, it verifies the integrity of the contents on the UEFI (BIOS) Flash memory of the computing unit. Once confirmed to be unaltered, TPCM releases control of the computing unit to the CPU. The CPU then boots UEFI, creates a C language execution phase, switches to protected mode, initializes memory, initializes some external devices, and creates a UEFI measurement agent. Based on the UEFI execution progress, the UEFI measurement agent uses TPCM to measure the integrity or verify the legitimacy of the external card's OPROM. After measuring the OPROM, control is released to the OPROM, and the external card performs its own device initialization and runs its functions. Based on the UEFI execution progress and user selections or settings, the UEFI measurement agent uses TPCM to measure the integrity or verify the legitimacy of the OS Loader. Once the measurement or verification is successful, control is released to the OS Loader to boot the corresponding operating system, and the UEFI boot phase ends.
[0077] like Figure 2 In the scheme shown, after the UEFI, as the object to be measured, obtains execution rights, it takes a part of the UEFI (BIOS) itself as the measurement execution subject again, and the UEFI directly measures the OSLoader and OPROM; its essence is to pass on the measurement function, and the UEFI BIOS is regarded as an extended measurement proxy point, which does not fully implement the TPCM active measurement concept.
[0078] The main reasons include: lack of suitable independent TPCM hardware; the common TPCM uses high-speed serial computer expansion bus standard (Peripheral Component Interconnect express, PCIe) plug-in card form, and the single board hardware wiring is modified to connect to the TPCM, resulting in incomplete related hardware interfaces; communication with the TPCM needs to be established in the BIOS after BIOS boot (dependent on hardware implementation); the requirements and protocols sent by the TPCM need to be understood and executed by the UEFI BIOS, which requires customization by both the BIOS and TPCM, which is highly complex, and there is currently no corresponding standard.
[0079] The main drawbacks include: The above scheme uses a trust-based transmission method; the longer the transmission chain, the lower the security. A problem in one link can lead to a complete loss of control over subsequent links. UEFI is relatively open; once UEFI is compromised, subsequent protections for OSLoader and OPROM will fail. Because TPCM decentralizes control, it can no longer provide protection or management, and cannot monitor in real time, resulting in low security. The UEFI boot process is a one-time power-on event. Besides providing UEFI runtime services, other UEFI servers will completely exit after the operating system starts. Therefore, measuring OSLoader and OPROM is also a one-time event, making multiple dynamic measurements difficult. For example, if the server's network card OPROM has been upgraded during runtime, the current scheme cannot remeasure it unless the system is powered off and restarted. Using UEFI as a measurement proxy is a temporary substitute due to limited technical means, but the way UEFI measures OSLoader and OPROM deviates from the proactive measurement and control philosophy of TPCM. In the process of UEFI acting as a measurement proxy, TPCM mainly provides cryptographic algorithm support and basic hardware; essentially, it treats TPCM as an ordinary external device, not as the TPCM master.
[0080] This application provides a trusted measurement system applied in an electronic device. The trusted measurement system includes a trusted measurement subsystem and a trusted platform control module. The trusted measurement subsystem acquires the measurement data of the object to be measured in the electronic device, and the trusted platform control module generates measurement results based on the measurement data. The trusted measurement subsystem includes a trusted platform control module interface, a protocol module, and a requirement execution module. The trusted platform control module interface is connected to the protocol module and the trusted platform control module in the electronic device, and the protocol module is connected to the requirement execution module. The trusted platform control module interface communicates with the trusted platform control module. The protocol module handles the communication protocol between the trusted measurement subsystem and the trusted platform control module. The requirement execution module acquires the measurement data of the object to be measured in the electronic device.
[0081] For the Trusted Measurement Subsystem, in response to the measurement request from the Trusted Platform Control Module, the Trusted Measurement Subsystem can perform trusted measurements. Specifically, the Trusted Platform Control Module interface receives the measurement request from the Trusted Platform Control Module; the Protocol Module determines the object to be measured corresponding to the measurement request based on the measurement request; the Requirement Execution Module obtains the data to be measured based on the object to be measured; the Protocol Module encapsulates the data to be measured; and the Trusted Platform Control Module interface sends the encapsulated data to be measured to the Trusted Platform Control Module.
[0082] The trust measurement subsystem also includes a control response module, which is used to control the controlled object in the electronic device according to the control type.
[0083] The Trusted Measurement Subsystem can execute control requests from the Trusted Platform Control Module. Specifically, the Trusted Platform Control Module interface receives control requests from the Trusted Platform Control Module; the Protocol Module determines the object to be controlled and the control type corresponding to the control request based on the control request; and the Control Response Module controls the object to be controlled according to the control type.
[0084] The Trusted Platform Control Module (TPC) connects to the Trusted Measurement Subsystem and includes an interface and an engine for the TPC. The TPC can initiate proactive measurements. Specifically, the TPC obtains the measurement policy through the TPC interface; sends a measurement request to the TPC based on the policy; receives the data to be measured from the TPC; and generates the measurement result based on the data using the engine.
[0085] After the Trusted Platform Control Module generates the measurement result based on the data to be measured, the Trusted Platform Control Module generates a control request through the engine based on the measurement result and control policy; the Trusted Platform Control Module then sends the control request to the Trusted Measurement Subsystem.
[0086] The following example illustrates a specific trust measurement system.
[0087] like Figure 3 The diagram illustrates a UEFI architecture supporting TPCM provided in this application embodiment. The UEFI architecture supporting TPCM provided in this application embodiment mainly includes a TPCM part as a protection component and a UEFI part as a computing component. The UEFI part (Trusted Measurement Subsystem) includes a Trusted Platform Control Module interface, a protocol module, a requirement execution module, and a control response module. The Trusted Platform Control Module interface connects to the protocol module and the Trusted Platform Control Module in the electronic device; the protocol module connects to the requirement execution module; the Trusted Platform Control Module interface communicates with the Trusted Platform Control Module; the protocol module handles the communication protocol between the Trusted Measurement Subsystem and the Trusted Platform Control Module; and the requirement execution module acquires the measurement data of the object to be measured in the electronic device. The TPCM part (Trusted Platform Control Module) generates measurement results based on the measurement data. The Trusted Platform Control Module connects to the Trusted Measurement Subsystem and includes a Trusted Measurement Subsystem interface and an engine.
[0088] The TPCM (Telemetry, Measurement, and Control) component initiates proactive measurement requests based on its measurement policy and sends them to the UEFI via the UEFI interface within the TPCM. It then receives the objects to be measured returned by the UEFI component. The TPCM's internal engine performs the corresponding proactive measurement actions, generating measurement results based on the measurement policy and benchmarks, and issuing control actions or commands corresponding to the measurement results in conjunction with the control policy. The TPCM component, acting as both the initiator of measurement and control actions, operates in a proactive mode.
[0089] The UEFI component receives measurement requests and other commands from the TPCM via the TPCM interface and sends UEFI feedback information. The protocol module, based on the protocol commands between the TPCM and UEFI, parses them to determine the corresponding TPCM request execution entity and invokes it. Different specific actions are performed according to different measurement content to fulfill the requirements of the TPCM. The UEFI component can read the OPROM of the resource to be measured from external devices, send the resource to be measured from the external device to the TPCM, and execute corresponding actions based on the control behavior fed back by the TPCM.
[0090] Since the UEFI on the BIOS Flash chip has already been actively measured by TPCM before booting, this embodiment does not need to repeatedly measure the code segment content (UEFI Driver and Framework, etc.) in the UEFI. Instead, it measures the content that is not on the BIOS Flash chip and has not been measured, namely, the content to be loaded from external storage such as the OSLoader and OPROM. The following will be based on Figure 3 The architecture is described in sections, focusing on each core module: the TPCM interface module, protocol module, requirement execution module, and control response module in UEFI.
[0091] like Figure 4 The diagram shows the TPCM interface provided in this embodiment. UEFI communicates with TPCM through the TPCM interface. The TPCM interface includes a device driver section and a transceiver interface function abstraction section. The device driver section is used to implement communication between the trusted measurement subsystem and the trusted platform control module, while the transceiver interface function abstraction section is used to shield the differences between different hardware device drivers in the device driver section.
[0092] The device driver section adapts the corresponding hardware device driver according to the hardware interface of the TPCM. The main hardware interfaces that the TPCM can use are PCIe, SPI, LPC, IPMB, etc. The device driver section is responsible for implementing communication between the UEFI and the TPCM device. Data will flow bidirectionally between the UEFI and the TPCM in the form of a binary stream.
[0093] The abstract part of the transceiver interface function hides the differences in specific hardware device drivers, enabling different TPCM hardware interfaces to communicate using the same software protocol. It is responsible for forming a unified transceiver interface function. When the TPCM sends a measurement request to the UEFI, the UEFI can obtain the content sent by the TPCM by reading the receiving interface; when the UEFI needs to send the content to be measured to the TPCM, it calls the sending interface to fill in the corresponding data.
[0094] like Figure 5 The diagram shows a protocol module provided in an embodiment of this application. The UEFI processes the communication protocol between the UEFI and the TPCM through this protocol module. For example... Figure 5 As shown, the protocol module parses the protocol input from the TPCM and encapsulates the UEFI's pending feedback content into protocol packets. In the embodiments of this application, protocol parsing may specifically include, but is not limited to: analyzing the protocol structure sent by the TPCM, understanding the specific content of the protocol, verifying the corresponding content, and distributing the requirements to the corresponding execution units according to the resources required by the protocol content; for cases where the UEFI needs to return corresponding data to be measured after executing the TPCM requirements, the data to be measured (such as the OSLoader binary file) is read into memory, and the data is encapsulated into data packets according to the protocol, and the data sending interface of the TPCM interface is called to send the content back to the TPCM.
[0095] like Figure 6 The diagram shows the requirement execution module provided in this embodiment. The requirement execution module is used to obtain the data to be measured from the object to be measured in the electronic device and execute the specific actions required by the TPCM. The TPCM sends the behavior of the OSLoader it needs to measure via a protocol, requiring the UEFI to send the OSLoader's binary file to the TPCM. At this time, the operating system loader submodule in the requirement execution module initializes the external storage device, such as a hard drive, calls the corresponding file system, searches for the corresponding OSLoader file in the bootable electronic device according to the user's settings, copies it into memory, and finally packages it into a protocol packet and sends it to the TPCM through the execution feedback part and protocol packet part of the protocol module.
[0096] The requirement execution module includes multiple execution sub-modules. The specific number and content of these sub-modules depend on the protocol between UEFI and TPCM. For example, TPCM needs to measure the Option ROM of the smart network card (OPC). (OPC originates from the PCI / PCIe specification; PCI Option ROM, also known as PCI Expansion ROM, is used for device initialization and system boot code. PCI Option ROM can be stored on the board or in the BIOS binary.) This requirement can be sent via the corresponding protocol command. UEFI needs a corresponding execution sub-module to read the OPC Option ROM, which is responsible for initializing the PCIe bus corresponding to the smart network card, locating the smart network card device based on the vendor ID and device ID, allocating memory and I / O resources, and reading target files, etc.
[0097] The control response module responds to the control actions of the TPCM. After the TPCM completes the measurement of the OSLoader, if it confirms that the OSLoader can start based on the policy and measurement results, it needs to perform corresponding active control. The TPCM sends the corresponding control request through the protocol. When the UEFI receives the request, it controls the OSLoader to run and start the operating system through the control response module.
[0098] This application provides a trusted measurement method applied to a trusted measurement subsystem of an electronic device, the electronic device including a trusted platform control module. Specifically, the trusted measurement subsystem receives a measurement request from the trusted platform control module; parses the measurement request; determines the object to be measured and the execution submodule corresponding to the measurement request based on the parsed measurement request; obtains the data to be measured based on the object to be measured through the determined execution submodule; encapsulates the data to be measured; and sends the encapsulated data to be measured to the trusted platform control module. After sending the encapsulated data to be measured to the trusted platform control module, the trusted measurement subsystem receives a control request from the trusted platform control module; determines the object to be controlled and the control type corresponding to the control request based on the control request; and controls the object to be controlled according to the control type.
[0099] This application provides a trusted measurement method applied to a trusted platform control module of an electronic device. The electronic device includes a trusted measurement subsystem and a trusted platform control module. Specifically, the trusted platform control module acquires a measurement policy; sends a measurement request to the trusted measurement subsystem according to the measurement policy; receives data to be measured returned by the trusted measurement subsystem; and generates a measurement result based on the data to be measured. After generating the measurement result based on the data to be measured, the engine of the trusted platform control module generates a control request based on the measurement result and the control policy; the trusted platform control module then sends the control request to the trusted measurement subsystem.
[0100] like Figure 7 The diagram shown is a flowchart of the measurement and control process provided in this embodiment. The TPCM acts as a protection component, and the UEFI acts as a computing component. The TPCM actively initiates a measurement request, transmitting the measurement request information to the UEFI's TPCM interface through the UEFI interface within the TPCM. The UEFI analyzes and distributes the received measurement request, calling different execution submodules according to different measurement requirements to perform actions such as reading OPROM from external storage. Then, it feeds back the data to be measured, encapsulates it according to the protocol, and sends the data to be measured to the TPCM for measurement through the sending interface. After the TPCM completes the active measurement, it directly executes the corresponding control behavior or indirectly executes the corresponding control behavior through the UEFI based on its measurement results and measurement strategy.
[0101] This embodiment solves the problem of transmitting the measurement subject in proactive measurement, avoiding the use of UEFI as a measurement proxy, and resolving and reducing the transmission of the measurement subject and control rights. UEFI, as the basic firmware, does not undertake measurement or verification tasks. By avoiding the transmission of the measurement subject and control rights, TPCM actively performs measurement and control, thereby improving the security of the entire system. This embodiment also solves the problem of the inability to perform dynamic measurement. TPCM actively measures the object to be measured, preventing the TPCM from failing to detect updates or tampering of the object in a timely manner. This embodiment also addresses the issue of deep support for TPCM proactive measurement in UEFI, avoiding treating TPCM as a mere peripheral providing cryptographic algorithms and basic hardware.
[0102] In one embodiment of this application, the trust measurement subsystem of the electronic device detects whether the current operating mode supports the mode of the Trusted Platform Control Module; if the current operating mode supports the mode of the Trusted Platform Control Module, the Trusted Platform Control Module is initialized.
[0103] For ease of understanding, this embodiment uses PCIe as the physical interface and OSloader as the object to be measured as an example. Other physical interfaces and objects to be measured are similar.
[0104] like Figure 8 The diagram shown is a startup flowchart of the trusted measurement system provided in an embodiment of this application. UEFI can shield underlying hardware differences and boot the operating system; therefore, for products actually using UEFI, it is best to be compatible with both traditional startup processes and startup processes that support TPCM mode. Figure 8As shown, after the UEFI powers on, it will perform basic initialization operations such as CPU initialization, chipset initialization, and memory resource initialization. After completing the basic initialization, it needs to use appropriate methods to detect whether it needs to run in a TPCM-supporting mode. Optionally, the appropriate methods include, but are not limited to, setting or embedding relevant flags, such as using EFUSE-related bits to indicate that TPCM support is required, or setting whether TPCM support is required by storing flag bits in UEFIVariable; it can also be determined by detecting TPCM hardware-related flags. If the UEFI needs to support TPCM, the TPCM UEFI Module (Trusted Measurement System) is run, in which TPCM-related initialization, configuration, parsing, execution, and response are performed. Otherwise, if the UEFI does not need to support TPCM, it will be initialized and booted according to the traditional UEFI boot process.
[0105] By adding a TPCM UEFI module to support TPCM functionality, the impact on the original UEFI functional architecture and startup process is minimal, and UEFI is conducive to deep support for TPCM.
[0106] In one embodiment of this application, the trusted measurement subsystem of the electronic device receives measurement requests from the trusted platform control module through the trusted platform control module interface of the trusted measurement subsystem. Specifically, the implementation of the trusted platform control module interface includes: the trusted measurement subsystem of the electronic device initializing the device driver part of the trusted platform control module interface; establishing a low-level data transceiver channel between the trusted platform control module and the trusted measurement subsystem; determining the functional abstraction part of the transceiver interface based on the low-level data transceiver channel and the protocol characteristics of the trusted platform control module and the trusted measurement subsystem; and encapsulating the functional abstraction part of the transceiver interface to obtain the interface to be called.
[0107] like Figure 9The diagram shown is a flowchart of the PCIe device driver provided in this embodiment. After the TPCM UEFI module starts running, it will begin initializing the PCIe device driver. To simplify the initialization of the PCIe device scanning operation, for a specific hardware platform, TPCM-related PCIe initialization can be performed based on the Device ID and Vendor ID on the specific PCIe slot, establishing a low-level data transmission and reception channel between UEFI and the PCIe TPCM device. After establishing the low-level data channel, the TPCM function driver will be determined according to the protocol characteristics between TPCM and UEFI. The TPCM function driver can shield the differences in the low-level device driver and form a function call interface for the upper layer. The TPCM OP PROTOCOL will encapsulate the TPCM function driver and form the Uefi_Tpcm_Send() and Uefi_Tpcm_Receive() interfaces in the form of a standard protocol for other modules (e.g., TPCM) to call. This part of the implementation will follow the UEFI Driver model to implement the relevant start interface, stop interface, and supported interface.
[0108] In one embodiment of this application, the trusted measurement subsystem can parse measurement requests through its protocol module. Specifically, the trusted measurement subsystem encapsulates the data to be measured through the protocol module by: determining whether the trusted measurement subsystem has a protocol to be processed; if a protocol to be processed exists, determining whether to parse the measurement request or encapsulate the data to be measured based on the source of the protocol.
[0109] like Figure 10The diagram shows a protocol processing flowchart provided in this application embodiment. To support the verification requirements of dynamic OPROM, the protocol module runs as a UEFI runtime service. Since the real-time requirements for measuring UEFI OSLoader and OPROM are not high, and the access latency of physical devices is not fixed, a periodic check of relevant statuses can be used to check for pending protocol data. If no processing is required, the check continues after a preset time. If protocol data needs processing, its source is checked to determine whether the request originates from TPCM (sent to UEFI by TPCM and requiring UEFI processing) or UEFI (the UEFI returns the processing result to TPCM). If the protocol data is sent from TPCM to UEFI, the TPCM request needs to be parsed and distributed according to the protocol between UEFI and TPCM. For example, if TPCM sends CMD as 0x0A, it indicates that TPCM expects to measure OSLoader; CMD as 0x0B indicates that it expects to measure RIAD Option ROM; and CMD as 0x0C indicates that it expects to measure Smart NIC Option ROM. When the protocol module parses the CMD sent by the TPCM as 0x0A, it will call the operating system loader submodule in the demand execution module; when the protocol module parses the CMD sent by the TPCM as 0x0B, it will call the disk array OPROM processing submodule in the demand execution module.
[0110] If the protocol module detects that UEFI needs to send feedback information to TPCM, it needs to prepare the information by combining the data to be fed back with the corresponding type (for example, if the data to be fed back is an OPROM BIN file, the corresponding type is RIAD), and then encapsulate the data packet before calling Uefi_Tpcm_Send() to send the content back to TPCM. After executing the corresponding actions, the protocol module will re-enter the runtime service detection and waiting state.
[0111] In one embodiment of this application, before obtaining the data to be measured from the object to be measured through a designated execution submodule, the trusted measurement subsystem performs a measurement preparation task. The trusted measurement subsystem calls the designated execution submodule through its demand execution module; determines the target path of the object to be measured based on the call parameters; loads the driver corresponding to the object to be measured based on the target path; locates the object to be measured based on the driver; and loads the object to be measured into the memory of the electronic device. After loading the object to be measured into the memory of the electronic device, the trusted measurement subsystem calls its protocol module to provide feedback on the data to be measured from the object to be measured.
[0112] like Figure 11The diagram shown is a flowchart of the OSLoader measurement preparation process provided in an embodiment of this application. The requirement execution module includes multiple execution sub-modules, among which the OSLoader processing function is one of the execution sub-modules, such as... Figure 11 As shown, the core function of the requirement execution module is to locate the OSLoader and read its corresponding content into memory so that it can be sent to the TPCM. When the OSLoader execution submodule is called by the requirement execution module, the device path of the OSLoader will be determined according to the call parameters, such as "\efi\boot\bootx64.efi". Then, it is necessary to confirm whether the corresponding driver has been loaded based on the location of the OSLoader. For example, if the OSLoader file is located on a network disk, external USB device, RIAD, or HDD, access to the corresponding physical external device requires the support of the corresponding device driver. If the corresponding driver has not yet been loaded in UEFI, it must be loaded first before the OSLoader can be located. Next, the remote OSLoader needs to be loaded into system memory. At this point, the standard UEFI service UEFI Boot Service gBS->LoadImage() can be used to load and relocate it into system memory. Once the OSLoader already exists in local memory, the protocol module can be called to execute the corresponding information feedback, sending the OSLoader BIN file to the TPCM and returning the corresponding status to the TPCM.
[0113] like Figure 12 The diagram shown is a flowchart of the OSLoader execution response provided in this embodiment. After completing the measurement, the TPCM will execute the corresponding control policy according to its internal policy and the measurement result. If a serious error is encountered in the measurement result, the TPCM can directly take strong control measures such as power-off restart; if the UEFI needs to cooperate in executing the corresponding action, it needs to send the corresponding execution protocol to the UEFI. Figure 12As shown, after the OSLoader measurement is completed, if the UEFI needs to continue booting the operating system, the TPCM behavior response module will be called. Upon receiving the OSLoader execution request, the behavior response module matches the OSLoader that has been loaded and relocated by gBS->LoadImage() from memory, and calls gBS->StartImage() to run the OSLoader. Since the OSLoader is a special type of application, it usually does not exit or return. The OSLoader will call gBS->ExitBootService() to transfer control of the platform from the firmware to the operating system, thereby starting the operating system. Therefore, before the controller transfer, the execution feedback of the protocol module needs to be called to report the information to be started and the OSLoader execution status to the TPCM.
[0114] In this embodiment, the active measurement is initiated and executed by the TPCM, and the UEFI provides a corresponding mechanism to supply the corresponding resources and perform control tasks.
[0115] In one embodiment of this application, in order to be compatible with both traditional UEFI and UEFI that supports TPCM, a settings page is added to UEFISetup to display TPCM-related information, as well as related control settings or configurations.
[0116] like Figure 13 The diagram shown is a schematic of an electronic device provided in an embodiment of this application. The electronic device 130 includes a memory 1301, a processor 1302, and computer-readable instructions stored in the memory 1301 and executable on the processor 1302, such as a trust measurement program. When the processor 1302 executes the computer-readable instructions, it implements the steps described in the trust measurement method embodiment.
[0117] Those skilled in the art will understand that the illustration Figure 13 This is merely an example of electronic device 130 and does not constitute a limitation on electronic device 130. It may include more or fewer components than shown, or combine certain components, or different components. For example, electronic device 130 may also include input / output devices, network access devices, buses, etc.
[0118] The processor 1302 may be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor, or processor 1302 may be any conventional processor. Processor 1302 is the control center of electronic device 130, connecting various parts of electronic device 130 through various interfaces and lines.
[0119] The memory 1301 can be used to store computer-readable instructions. The processor 1302 implements various functions of the electronic device 130 by running or executing the computer-readable instructions or modules stored in the memory 1301 and by calling the data stored in the memory 1301. The memory 1301 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, application programs required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the electronic device 130, etc. In addition, the memory 1301 may include a hard disk, memory, plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, at least one disk storage device, flash memory device, read-only memory (ROM), random access memory (RAM), or other non-volatile / volatile storage devices.
[0120] If the modules integrated in electronic device 130 are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by instructing related hardware through computer-readable instructions. These computer-readable instructions can be stored in a computer-readable storage medium, and when executed by a processor, they can implement the steps of the various method embodiments described above. The computer-readable instructions include computer-readable instruction code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying computer-readable instruction code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), etc.
[0121] This embodiment also provides a computer storage medium storing computer instructions. When the computer instructions are executed on an electronic device, the electronic device performs the aforementioned method steps to implement the trust measurement method in the above embodiment.
[0122] This embodiment also provides a computer program product that, when run on an electronic device, causes the electronic device to perform the aforementioned related steps to implement the trust measurement method in the above embodiment.
[0123] In addition, embodiments of this application also provide an apparatus, which may specifically be a chip, component or module. The apparatus may include a connected processor and a memory. The memory is used to store computer execution instructions. When the apparatus is running, the processor can execute the computer execution instructions stored in the memory to cause the chip to execute the trust measurement method in the above method embodiments.
[0124] In this embodiment, the electronic device, computer storage medium, computer program product or chip are all used to execute the corresponding method provided above. Therefore, the beneficial effects that can be achieved can be referred to the beneficial effects of the corresponding method provided above, and will not be repeated here.
[0125] Through the above description of the embodiments, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.
[0126] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.
[0127] The unit described as a separate component may or may not be physically separate. The component shown as a unit can be one physical unit or multiple physical units, that is, it can be located in one place or distributed in multiple different places. Some or all of the units can be selected to achieve the purpose of the solution in this embodiment according to actual needs.
[0128] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.
[0129] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, essentially or in other words, the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0130] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.
Claims
1. A trust measurement system, applied in electronic devices, characterized in that, The trusted measurement system includes a trusted measurement subsystem and a trusted platform control module. The trusted measurement subsystem is used to acquire the measurement data of the object to be measured in the electronic device, and the trusted platform control module is used to generate measurement results based on the measurement data. The trusted measurement subsystem includes a trusted platform control module interface, a protocol module, and a requirement execution module. The trusted platform control module interface is connected to the protocol module and the trusted platform control module in the electronic device. The protocol module is connected to the requirement execution module. The trusted platform control module interface communicates with the trusted platform control module. The protocol module is used to process the communication protocol between the trusted measurement subsystem and the trusted platform control module. The requirement execution module is used to acquire the measurement data of the object to be measured in the electronic device. In response to the measurement request from the trusted platform control module, the trusted measurement subsystem performs trusted measurement, including: The trusted platform control module interface receives the measurement request from the trusted platform control module; The protocol module determines the object to be measured corresponding to the measurement request based on the measurement request. The requirement execution module obtains the data to be measured based on the object to be measured. The protocol module encapsulates the data to be measured. The trusted platform control module interface sends the packetized data to be measured to the trusted platform control module.
2. The trust measurement system as described in claim 1, characterized in that, The trusted platform control module interface includes a device driver part and a transceiver interface function abstraction part. The device driver part is used to realize the communication between the trusted measurement subsystem and the trusted platform control module, and the transceiver interface function abstraction part is used to shield the differences between different hardware device drivers in the device driver part.
3. The trust measurement system as described in claim 1, characterized in that, The protocol module includes a protocol parsing submodule and a protocol packet encapsulation submodule. The protocol parsing submodule is used to parse the protocol structure of the protocol sent by the trusted measurement subsystem and verify the protocol content of the protocol sent by the trusted measurement subsystem. The protocol packet encapsulation submodule is used to encapsulate the data to be measured.
4. The trust measurement system as described in claim 1, characterized in that, The requirement execution module includes multiple execution sub-modules, which are used to initialize the object to be measured and read the data to be measured from the object to be measured.
5. The trust measurement system as described in claim 1, characterized in that, The trust measurement subsystem also includes a control response module, which is used to control the object to be controlled in the electronic device according to the control type.
6. The trust measurement system as described in claim 5, characterized in that, The trusted measurement subsystem executes the control requests from the trusted platform control module, including: The trusted platform control module interface receives the control request from the trusted platform control module; The protocol module determines the object to be controlled and the control type corresponding to the control request based on the control request; The control response module controls the object to be controlled according to the control type.
7. The trust measurement system as described in claim 1, characterized in that, The trusted platform control module is connected to the trusted measurement subsystem, and the trusted platform control module includes a trusted measurement subsystem interface and an engine.
8. The trust measurement system as described in claim 7, characterized in that, The trusted platform control module initiates proactive measurement, including: Obtain the measurement strategy; A measurement request is sent to the trusted measurement subsystem according to the measurement strategy; Receive the data to be measured returned by the trusted measurement subsystem; The measurement results are generated based on the data to be measured.
9. The trust measurement system as described in claim 8, characterized in that, After the trusted platform control module generates a measurement result based on the data to be measured, the trusted platform control module generates a control request through the engine based on the measurement result and the control strategy. The Trusted Platform Control Module sends the control request to the Trusted Measurement Subsystem.
10. A trust measurement subsystem, applied in electronic devices, characterized in that, The trusted measurement subsystem includes a trusted platform control module interface, a protocol module, and a requirement execution module. The trusted platform control module interface is connected to the protocol module and the trusted platform control module in the electronic device. The protocol module is connected to the requirement execution module. The trusted platform control module interface communicates with the trusted platform control module. The protocol module is used to process the communication protocol between the trusted measurement subsystem and the trusted platform control module. The requirement execution module is used to acquire the measurement data of the object to be measured in the electronic device. The trusted measurement subsystem is used to acquire the measurement data of the object to be measured in the electronic device. In response to the measurement request from the trusted platform control module, the trusted measurement subsystem performs trusted measurement, including: The trusted platform control module interface receives the measurement request from the trusted platform control module; The protocol module determines the object to be measured corresponding to the measurement request based on the measurement request. The requirement execution module obtains the data to be measured based on the object to be measured. The protocol module encapsulates the data to be measured. The trusted platform control module interface sends the packetized data to be measured to the trusted platform control module.
11. The trust measurement subsystem as described in claim 10, characterized in that, The trusted platform control module interface includes a device driver part and a transceiver interface function abstraction part. The device driver part is used to realize the communication between the trusted measurement subsystem and the trusted platform control module, and the transceiver interface function abstraction part is used to shield the differences between different hardware device drivers in the device driver part.
12. The trust measurement subsystem as described in claim 10, characterized in that, The protocol module includes a protocol parsing submodule and a protocol packet encapsulation submodule. The protocol parsing submodule is used to parse the protocol structure of the protocol sent by the trusted measurement subsystem and verify the protocol content of the protocol sent by the trusted measurement subsystem. The protocol packet encapsulation submodule is used to encapsulate the data to be measured.
13. The trust measurement subsystem as described in claim 10, characterized in that, The requirement execution module includes multiple execution sub-modules, which are used to initialize the object to be measured and read the data to be measured from the object to be measured.
14. The trust measurement subsystem as described in claim 10, characterized in that, The trust measurement subsystem also includes a control response module, which is used to control the object to be controlled in the electronic device according to the control type.
15. The trust measurement subsystem as described in claim 14, characterized in that, The trusted measurement subsystem executes the control requests from the trusted platform control module, including: The trusted platform control module interface receives the control request from the trusted platform control module; The protocol module determines the object to be controlled and the control type corresponding to the control request based on the control request; The control response module controls the object to be controlled according to the control type.
16. A trusted platform control module, applied in electronic devices, characterized in that, The trusted platform control module includes a trusted measurement subsystem interface and an engine; The trusted platform control module initiates proactive measurement, including: The trusted platform control module obtains the measurement strategy through the trusted measurement subsystem interface; The trusted platform control module sends a measurement request to the trusted measurement subsystem according to the measurement strategy; The trusted platform control module receives the data to be measured returned by the trusted measurement subsystem; wherein, the data to be measured is the object to be measured corresponding to the measurement request determined by the protocol module in the trusted measurement subsystem according to the measurement request, and obtained by the demand execution module in the trusted measurement subsystem according to the object to be measured; The trusted platform control module generates measurement results based on the data to be measured through the engine.
17. The trusted platform control module as described in claim 16, characterized in that, After the trusted platform control module generates a measurement result based on the data to be measured using the engine, the trusted platform control module generates a control request based on the measurement result and the control strategy using the engine. The Trusted Platform Control Module sends the control request to the Trusted Measurement Subsystem.
18. A trust measurement method applied to a trust measurement subsystem of an electronic device, the electronic device including a trust platform control module, characterized in that, The credibility measurement method includes: Receive the measurement request from the trusted platform control module; The measurement request is parsed; The object to be measured and the execution submodule corresponding to the parsed measurement request are determined based on the parsed measurement request. The determined execution submodule obtains the data to be measured based on the object to be measured; The data to be measured is packaged; The packet containing the data to be measured is sent to the trusted platform control module.
19. The credibility measurement method as described in claim 18, characterized in that, The credibility measurement method also includes: Check whether the current operating mode supports the trusted platform control module mode; If the current operating mode supports the mode of the trusted platform control module, initialize the trusted platform control module.
20. The credibility measurement method as described in claim 18, characterized in that, The trust measurement method further includes: receiving a measurement request from the trust platform control module through the trust platform control module interface of the trust measurement subsystem, wherein the trust platform control module interface includes: Initialize the device driver portion of the trusted platform control module interface; Establish the underlying data transmission and reception channel between the trusted platform control module and the trusted measurement subsystem; Based on the underlying data transceiver channel, the abstract part of the transceiver interface function is determined according to the protocol characteristics of the trusted platform control module and the trusted measurement subsystem. The abstract part of the send / receive interface function is encapsulated to obtain the interface to be called.
21. The credibility measurement method as described in claim 18, characterized in that, After sending the packet containing the data to be measured to the trusted platform control module, the trusted measurement method further includes: Receive the control request from the trusted platform control module; The control request is used to determine the object to be controlled and the control type corresponding to the control request. The object to be controlled is controlled according to the control type.
22. The credibility measurement method as described in claim 18, characterized in that, The measurement request is parsed by the protocol module of the trusted measurement subsystem, and the data to be measured is packaged by the protocol module, including: Determine whether the trust measurement subsystem has any pending protocols; If there is a pending protocol, the measurement request is parsed or the data to be measured is packaged based on the source of the pending protocol.
23. The credibility measurement method as described in claim 18, characterized in that, Before the determined execution submodule obtains the data to be measured based on the object to be measured, the trusted measurement method further includes: The demand execution module of the trustworthy measurement subsystem calls the determined execution submodule; The target path of the object to be measured is determined based on the calling parameters; Load the driver corresponding to the object to be measured according to the target path; The object to be measured is located based on the driver corresponding to the object to be measured; The object to be measured is loaded into the memory of the electronic device.
24. The credibility measurement method as described in claim 23, characterized in that, After loading the object to be measured into the memory of the electronic device, the trust measurement method further includes: The protocol module of the trusted measurement subsystem is invoked to provide feedback on the measurement data of the object to be measured.
25. A trust measurement method applied to a trust platform control module of an electronic device, wherein the electronic device includes a trust measurement subsystem, characterized in that, The credibility measurement method includes: Obtain the measurement strategy; A measurement request is sent to the trusted measurement subsystem according to the measurement strategy; The system receives the data to be measured returned by the trusted measurement subsystem; wherein the data to be measured is obtained by the trusted measurement subsystem through parsing, determining the object to be measured and the execution submodule corresponding to the measurement request based on the parsed measurement request, and obtaining the data based on the object to be measured by the execution submodule. The measurement results are generated based on the data to be measured.
26. The credibility measurement method as described in claim 25, characterized in that, After generating the measurement result based on the data to be measured, the reliable measurement method further includes: The engine of the trusted platform control module generates a control request based on the measurement results and control strategy. The control request is sent to the trust measurement subsystem.
27. An electronic device, characterized in that, It includes a processor and a memory; the memory is used to store instructions; the processor is used to invoke the instructions in the memory to cause the electronic device to run the trust measurement system as described in any one of claims 1 to 9, or to cause the electronic device to execute the trust measurement subsystem as described in any one of claims 10 to 15, or to cause the electronic device to execute the trust platform control module as described in any one of claims 16 to 17, or to cause the electronic device to execute the trust measurement method as described in any one of claims 18 to 26.
28. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores at least one instruction, which, when executed by a processor, implements the trust measurement method as described in any one of claims 18 to 26.