Method for verifying integrity of baseboard management controller firmware and electronic device

Abstract

The application discloses a substrate management controller firmware integrity verification method and electronic equipment, relates to the technical field of server management, and comprises the following steps: obtaining the storage path and content data of each function module, and constructing a tree structure according to the storage path prefix layering, so that full coverage verification of all function modules of the substrate management controller firmware is realized; the security level label in the structured description information is filtered, and the verification path is determined according to the target function module, so that the redundant operation of full-amount firmware image hash calculation is avoided, and the calculation amount and time consumption of the verification process are reduced; the hash is recalculated based on the target function module, and the path consistency is verified, so that whether the target function module is tampered with can be quickly judged, the whole firmware data does not need to be traversed, the verification comprehensiveness and efficiency are considered, and the bandwidth resource consumption is reduced; the function modules are associated with the storage path and content data, and the tree structure verification logic is combined, so that the firmware verification is refined from the full-amount image level to the function module level.

Description

Technical Field

[0001] This application relates to the field of server management technology, and in particular to a method for verifying the integrity of firmware for a baseboard management controller and an electronic device. Background Technology

[0002] In server management controller applications based on the Open Baseboard Management Controller (OpenBMC) architecture, firmware, as a core operating component, directly determines the security and reliability of the server management system through its integrity throughout the entire process of storage, startup, and operation.

[0003] The industry currently employs hash algorithms, digital signatures, and hardware root of trust verification technologies to prevent security risks such as unauthorized firmware modification and malicious code injection. However, both mainstream implementation methods still require recalculating the hash of the entire firmware image when only updating firmware sub-modules (such as configuration files or web service components), resulting in low verification efficiency, startup delays, and wasted bandwidth. Summary of the Invention

[0004] This application provides a method and electronic device for verifying the integrity of the firmware of a baseboard management controller, which at least solves the problems in the related art where a full calculation of the firmware image hash is required when updating a submodule, resulting in long verification time, affected startup speed, and high bandwidth overhead for remote updates.

[0005] This application provides a method for verifying the integrity of a baseboard management controller firmware, comprising: obtaining the storage path and content data of each functional module in the baseboard management controller firmware; constructing a tree structure based on the storage path and content data of each functional module, and determining the root hash and structured description information of the tree structure; wherein, the data units of the tree structure are stored hierarchically according to the prefix of the storage path, and a hash value is generated for the content data; selecting target functional modules based on the security level tags included in the structured description information, and determining the verification path corresponding to the target functional module in the tree structure based on the storage path of the target functional module; generating a reconstructed root hash based on the verification path; and comparing the reconstructed root hash with the root hash to verify the integrity of the baseboard management controller firmware.

[0006] This application also provides an integrity verification device for the firmware of a baseboard management controller, comprising:

[0007] The acquisition module is used to acquire the storage paths and content data of each functional module in the firmware of the baseboard management controller;

[0008] The determination module is used to construct a tree structure based on the storage path and content data of each functional module, and to determine the root hash and structured description information of the tree structure; wherein, the data units of the tree structure are stored hierarchically according to the prefix of the storage path, and a hash value is generated for the content data;

[0009] The filtering module is used to filter out target functional modules based on the security level tags included in the structured description information, and to determine the corresponding verification path of the target functional module in the tree structure based on the storage path of the target functional module.

[0010] The generation module is used to generate the reconstructed root hash based on the verification path;

[0011] The verification module is used to compare the reconstructed root hash with the root hash to verify the integrity of the baseboard management controller firmware.

[0012] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for implementing the steps of the above-described integrity verification method for the baseboard management controller firmware when executing the computer program.

[0013] This application also provides a computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, it implements the steps of the above-described integrity verification method for the baseboard management controller firmware.

[0014] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the above-described integrity verification method for the baseboard management controller firmware.

[0015] This application achieves full-coverage verification of all functional modules of the baseboard management controller firmware by acquiring the storage paths and content data of each functional module and constructing a hierarchical tree structure based on storage path prefixes. By filtering through security level tags in the structured description information and determining the verification path for the target functional module, redundant operations of full firmware image hash calculation are avoided, reducing the computational load and time consumption of the verification process. By recalculating the hash based on the target functional module and verifying path consistency, it is possible to quickly determine whether it has been tampered with without traversing all firmware data, balancing verification comprehensiveness and efficiency, and reducing bandwidth resource consumption. By associating each functional module with storage paths and content data, and combining the tree structure verification logic, firmware verification is refined from the full image level to the functional module level. Attached Figure Description

[0016] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 A schematic diagram of the specific hardware architecture on which the integrity verification method for a baseboard management controller firmware provided in this application depends;

[0018] Figure 2 A flowchart illustrating a method for verifying the integrity of firmware for a baseboard management controller, provided in an embodiment of this application;

[0019] Figure 3 A schematic diagram of the structure of a firmware integrity verification device for a baseboard management controller provided in this application embodiment;

[0020] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0021] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0022] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0023] To more clearly illustrate the embodiments of this application, the technical terms used in the embodiments will be briefly introduced below:

[0024] The Open Baseboard Management Controller (OpenBMC) is an open-source BMC firmware stack built on Linux, which can provide remote monitoring, management and control functions for hardware such as servers and network devices.

[0025] The Baseboard Management Controller (BMC) is an embedded dedicated microcontroller integrated into the motherboard of a computer (mainly servers). As the core execution component of hardware management standards such as intelligent platform management interfaces, it operates independently of the host core system. Through standardized interfaces, it realizes functions such as hardware status monitoring, fault log recording, remote control, and firmware management, providing out-of-band management capabilities that do not depend on the host's operating status for local and remote management.

[0026] The bootloader is the low-level software that runs first after the system is powered on. It is used to initialize the hardware, load the operating system kernel or applications, and acts as a bridge between the hardware and the upper-level system.

[0027] The core function of the Platform Configuration Register (PCR) is to store integrity metrics of system hardware, firmware, and software components. The PCR extension interface is a dedicated interface for the Trusted Platform Module (TPM) to extend and store these metrics in the PCR register.

[0028] The Extended Berkeley Packet Filter (eBPF) is a functional extension of the Berkeley Packet Filter. eBPF allows users to inject custom bytecode programs into the Linux kernel without modifying the kernel source code or loading kernel modules. These programs are then executed after security verification by the kernel's verifier, enabling efficient collection, filtering, and processing of kernel-mode and user-mode data.

[0029] Redfish Specification (Redfish) is a hardware management protocol developed by the Distributed Management Task Force. It is based on a Representational State Transition Style Application Programming Interface (RESTful API) and uses JavaScript Object Notation (JSON) or Hypertext Transfer Protocol (HTTP) as the data exchange format. It supports modern network standards such as Internet Protocol version 6 and Hypertext Transfer Security Protocol. It is used to unify the remote management (such as configuration, monitoring, and firmware upgrades) of hardware such as servers, storage devices, and network devices. It is a new generation management protocol that replaces traditional intelligent platform management interface protocols.

[0030] The Intelligent Platform Management Interface (IPMI) protocol is a hardware-level remote management protocol that runs independently of the operating system. It supports functions such as power control, hardware status monitoring (temperature / voltage), log collection, and remote control console, and is suitable for the operation and maintenance management of server clusters.

[0031] The Secure Hash Algorithm 256 (SHA-256) can convert input data of any length into a fixed-length hash value of 256 bits (32 bytes), which has the characteristics of collision resistance and tamper resistance.

[0032] The SM3 Cryptographic Hash Algorithm (SM3) can generate a fixed-length message digest of 256 bits (32 bytes) from an input message of arbitrary length through steps such as block division, padding, and iterative compression.

[0033] Currently, OpenBMC firmware integrity verification technology mainly adopts two implementation methods: one is to perform full hash calculation on the entire firmware image, for example, to generate the hash value of the complete firmware image through the 256-bit secure hash algorithm (SHA-256), and use this as the basis for integrity verification; the other is to construct a static Merkle Tree structure and implement the integrity verification of firmware components based on the tree-like hash structure.

[0034] However, these two technical solutions have obvious drawbacks in practical applications: On the one hand, when only a sub-module in the firmware needs to be updated, the entire firmware image still needs to be re-hashed, resulting in an excessively long verification process. This not only affects the server's startup speed but also significantly increases bandwidth overhead in remote update scenarios. On the other hand, the relevant technologies mainly verify the static integrity of the firmware in the storage medium. However, once the firmware kernel or service program is loaded into memory and runs, if an attacker exploits system vulnerabilities to tamper with the code in memory, traditional verification mechanisms cannot detect such dynamic security threats in real time. Furthermore, TPM's PCR extension operations are mostly based on the hash value of the firmware image in the storage medium and do not correlate with the integrity status of the actual running code in memory, further reducing the security protection capabilities during firmware operation.

[0035] To address all or part of the aforementioned technical issues, this application obtains the storage paths and content data of each functional module, constructs a hierarchical tree structure based on storage path prefixes, generates an independent hash value for the content data of each functional module, and finally aggregates them into the root hash of the tree structure. Simultaneously, it records the storage path, hash value, and security level label of each module through structured description information. This design breaks away from the limitations of traditional solutions that treat the entire firmware image as a single verification unit, achieving fine-grained module-level splitting and hash storage. This ensures that each functional module corresponds to a clearly defined hierarchical node in the tree structure, and its hash value does not need to be bound to the hash values ​​of other modules for calculation.

[0036] Secondly, for submodule update scenarios, this method filters target functional modules through security level tags in structured description information and locates the corresponding verification path in the tree structure based on its storage path. This verification path only contains the target functional module and its associated hash information from its parent node to the root node in the tree structure, not all nodes in the entire tree structure. Based on this, when generating the reconstructed root hash through the verification path, only the content hash of the target functional module needs to be recalculated, and the hashes of parent nodes are aggregated upwards along the verification path until the reconstructed root hash is generated. There is no need to involve hash calculations for other unupdated functional modules. In contrast, traditional solutions, when updating submodules, require rereading all data in the entire firmware image and recalculating the complete hash, even if only one submodule is modified, because the hash value is calculated based on the entire firmware image, resulting in a large amount of invalid data processing. This method, through precise path location and partial node aggregation calculation, strictly limits the verification calculation scope to the target functional module and its associated hierarchical paths. The hash values ​​of unupdated modules can directly reuse historical data already stored in the tree structure without repeated calculations.

[0037] Finally, integrity verification is achieved by comparing the reconstructed root hash with the original root hash, which not only ensures the security of the verification but also reduces the amount of computation, data reading, and transmission bandwidth usage, shortens the verification delay when BMC starts up, and reduces the bandwidth waste caused by transmitting complete mirror hash data during firmware updates.

[0038] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0039] like Figure 1 The diagram shows a specific hardware architecture on which the integrity verification method of the baseboard management controller firmware depends, including a root of trust component, memory and storage media, baseboard management controller, hardware auxiliary execution unit, and communication and auxiliary verification components.

[0040] The trusted root component comprises a hardware trusted root, a trusted platform module, and a hardware security module. The hardware trusted root writes the vendor's public key hash and root hash to ensure that the baseline data for firmware verification cannot be physically or logically tampered with; it is also responsible for initializing the trusted environment. The trusted platform module provides hardware-level integrity measurement, key management, and digital signature capabilities. Its platform configuration register records the hash values ​​of target functional modules during startup through extended operations, and stores the device's asymmetric key pairs, providing hardware-level signing capabilities for signature reports generated for remote verification requests. The hardware security module securely stores the firmware static integrity baseline (i.e., the root hash), reconstructs the root hash, and other verification data, and provides secure generation, storage, and access control for encryption keys.

[0041] During firmware boot and verification, memory serves two main functions. Memory is used to temporarily store initialization code and hash values, as well as to load firmware images, functional module content data, and tree structures, providing memory space for hash calculations and root hash reconstruction. Storage media stores information about firmware logical function partitions, functional modules, and their corresponding storage paths. It also provides a stable storage structure for locating the physical offset addresses of functional modules, ensuring accurate reading of content data from the corresponding areas for hash calculations.

[0042] As the core execution unit of the verification method, the baseboard management controller performs core logic such as firmware parsing, functional module extraction, storage path location, and physical offset calculation. At the same time, it provides hardware acceleration for hash operation and digital signature / verification, reducing the computational overhead of the verification process and improving verification efficiency.

[0043] The hardware-assisted execution unit can non-intrusively intercept firmware file writing and execution operations at the kernel level, and trigger hash verification of the target functional module in real time.

[0044] The communication and auxiliary verification components include a remote management communication interface, a clock module, and a hardware monitoring and recovery module. The remote management communication interface supports standardized protocols such as Redfish and IPMI, providing a secure communication channel for integrity verification requests / responses between the remote management terminal and the BMC. This interface must have data encryption transmission capabilities to ensure that the verification data packet and signature value are not eavesdropped on or tampered with during transmission. The clock module provides the current timestamp, constructs the integrity verification data packet, and ensures the uniqueness and timeliness of each verification request. The hardware monitoring and recovery module monitors the hardware status during firmware startup. When firmware verification failure is detected, it can trigger emergency operations such as primary / backup firmware switching and firmware recovery. It also supports hardware-level abnormal interruption; when tampering is detected during verification, it quickly terminates firmware loading or operation, reducing the risk of malicious code execution and improving system fault tolerance and security.

[0045] Embodiments of this application provide a method for verifying the integrity of a baseboard management controller firmware, such as... Figure 2 As shown, the method includes the following steps:

[0046] S201. Obtain the storage path and content data of each functional module in the firmware of the baseboard management controller.

[0047] Among them, functional modules are code or data units that have independent operation or configuration significance; such as the boot program module in the bootloader partition, the hardware management service module in the root file system partition, and the network configuration module in the configuration data partition.

[0048] In some embodiments, the firmware of the baseboard management controller is parsed to identify multiple logical functional partitions contained therein; for each logical functional partition, the functional modules contained therein and the storage path of each functional module in the file system are extracted; the physical offset address and data length of the functional module in the firmware image are located according to the storage path of the functional module, and the content data of the corresponding area is read.

[0049] The logical function partitions include the Bootloader partition, kernel image partition, root file system partition, and configuration data partition. The Bootloader partition is used to store the bootloader firmware and is responsible for booting; the kernel image provides the running kernel; the root file system stores application and library files; and the configuration data partition stores device parameters.

[0050] In the specific implementation process of the above embodiments, the OpenBMC firmware is first analyzed as a whole to identify core logical function partitions such as the Bootloader partition, kernel image partition, root file system partition, and configuration data partition. These partitions are the basic building blocks of the OpenBMC firmware, each carrying different core functions. Splitting by partition can avoid confusion and omission of functional modules during the analysis process.

[0051] Next, for each logical function partition, the functional modules that have independent operation or configuration significance are further extracted, and the complete storage path of each module in the file system (such as " / usr / bin / ipmitool" and " / etc / network / config") is recorded. This storage path will serve as a unique identifier for subsequent identification of functional modules.

[0052] Subsequently, the physical offset address and data length of the module in the firmware image are located by reverse-engineering the storage path. Since the firmware image is essentially a binary file, and the functional modules are stored in the form of continuous binary data, the original data area corresponding to the module can be accurately located by using the physical offset and length, ensuring that the read content data is complete and without redundancy.

[0053] The above embodiments, through logical partitioning and functional module extraction, achieve full coverage of the core functional units of the OpenBMC firmware, ensuring that no critical modules are omitted and laying the foundation for subsequent full firmware integrity verification. The storage path of a functional module reflects its logical location in the baseboard management controller firmware and is a key index for distinguishing different modules and associating them with verification benchmark data. By working backward from the storage path of the functional module to deduce the physical offset and data length, the original binary data area corresponding to each functional module can be accurately located. This avoids resource consumption caused by reading redundant data and ensures that the read data is consistent with the functional module itself, thereby guaranteeing the accuracy of hash value verification.

[0054] Optionally, a cryptographic hash operation is performed on the content data to generate a hash value for the content data, which is then paired with the corresponding storage path to form a basic data set. A cryptographic hash operation is performed on the content data of each functional module to generate a unique corresponding hash value, which is then paired with the module's storage path to form a basic data set of "storage path-hash value." This completes the transformation from raw firmware data to trusted verification data, ensuring that any minor change to the module's content will result in a significant change in the hash value. Subsequent verification of the hash value is sufficient to quickly determine whether the module has been tampered with.

[0055] The pairing design of storage path and hash value not only ensures the unique identifier of each functional module (the storage path cannot be repeated), but also provides the core data unit of "key (storage path) - value (hash value)" for the subsequent construction of the tree structure, ensuring that the tree structure can achieve accurate path verification and tamper location based on the module identifier.

[0056] S202. Construct a tree structure based on the storage path and content data of each functional module, and determine the root hash and structured description information of the tree structure.

[0057] In this tree structure, data units are stored hierarchically according to the prefixes of the storage path, and hash values ​​are generated for the content data. The tree structure can be a Merkle-Patricia Trie (MPT), a hybrid data structure that combines the efficient prefix lookup properties of the Patricia Trie with the cryptographic verifiability of the Merkle Tree. By storing the data keys hierarchically according to prefixes (a characteristic of Patricia Trees) and generating a Merkle hash value for each node (a characteristic of Merkle Trees), modifications to the data can be quickly detected through hash value changes, while also supporting efficient data verification in zero-knowledge proof scenarios.

[0058] It's important to note that merging nodes with the same path in a Patricia tree eliminates redundant prefixes and reduces storage overhead. Each node's hash value is calculated jointly from its stored data and the hash values ​​of its child nodes. The root node's hash value (Merkle Root) uniquely represents the state of the entire tree. If any data in the tree is modified, it will cause changes to the hash values ​​of all nodes along its path, ultimately reflecting a change in the root hash.

[0059] In some embodiments, during the process of constructing a tree structure based on the storage paths and content data of each functional module, the storage paths of each functional module are first mapped to the value paths of the tree structure according to the directory hierarchy. Then, the internal nodes of the tree structure are established according to the principle of path prefix sharing. The storage paths of each functional module are used as keys and the content data is used as values ​​to form leaf nodes in the tree structure.

[0060] The path prefix sharing principle means that when functional modules have the same storage path prefix, they share the branch node corresponding to that storage path. The leaf nodes of the tree structure are mappings of functional modules.

[0061] Specifically, the storage path of each functional module is first split according to the directory hierarchy (for example, the path " / boot / loader" is split into two fragments "boot" and "loader"). These fragments naturally form a unique search path from the root node of the trie to the corresponding leaf node. This splitting method essentially maps the directory hierarchy of the file system to the branch path of the tree structure, so that each module has a clear location in the tree, providing a natural logical basis for subsequent path verification.

[0062] Next, the Trie structure is initialized and the root node is created. Then, internal nodes are built layer by layer according to the principle of path prefix sharing. For example, the functional modules " / boot / loader" and " / boot / kernel" have the same path prefix "boot". They will share the branch node corresponding to "boot" without having to create nodes with the same prefix repeatedly. This design reduces redundant nodes in the tree structure and reduces storage overhead, especially suitable for scenarios where multiple modules share directory prefixes in OpenBMC firmware.

[0063] Then, the "storage path (key) - hash value (value)" of each module is inserted into the tree to form leaf nodes. The leaf nodes are direct mappings of firmware modules, and the hash values ​​they store are the "fingerprints" of the module content, ensuring a direct association between the module content and the tree structure.

[0064] The prefix sharing mechanism solves the problem of redundant storage in traditional hash trees. By sharing branch nodes with the same path prefix, it can maintain the lightweight tree structure even in scenarios with a large number of firmware modules and complex directory hierarchy, thereby improving the efficiency of path retrieval during subsequent verification.

[0065] In some embodiments, when calculating the root hash of the tree structure, the hash value of the bottom-level internal node of the tree structure is calculated first. The bottom-level internal node is the internal node in the tree structure that is directly connected to the leaf node. Then, based on the hash value of the bottom-level internal node, the hash values ​​of the score nodes are aggregated layer by layer upwards until all branches of the tree structure are covered to obtain the hash value of the top-level root node, which is used as the root hash of the tree structure.

[0066] The hash value of each non-leaf node is calculated layer by layer from the leaf node upwards. The hash value of a non-leaf node is obtained by hashing the concatenated bytes of its child nodes. The child node information includes key data such as the path fragment and hash value. This makes each non-leaf node an intermediate verification benchmark for the integrity of all modules in its subordinate branches.

[0067] Calculate the hash value H of the top-level node in the Merkle prefix tree structure. root The root hash of the Merkle prefix tree is used to represent the integrity of the entire firmware. The hash value of the top-level root node is the result of a hierarchical aggregation of the hash values ​​of all leaf nodes in the entire tree structure. Any change to the content of any module (which causes a change in the hash value of its leaf node) will propagate upwards along the branches of the tree, eventually affecting the root hash H. root Things have changed.

[0068] When calculating the hash value of the top-level root node, the hash value is aggregated layer by layer. The core of this process is to follow the bottom-up calculation logic of "leaf node → child branch node → parent branch node → top-level root node". The hash value of each non-leaf node is generated by aggregating the key information of its direct child nodes. Finally, through multiple rounds of hash operations, the integrity status of all leaf nodes is condensed into the unique hash value of the root node. The specific implementation steps are as follows:

[0069] The first step is to define a unified aggregation format: For each non-leaf node, three core pieces of information from all its direct child nodes need to be collected: "path fragment identifier + node type identifier + node hash value". The path fragment identifier is the storage path segment corresponding to the child node (e.g., "boot" or "loader"), used to distinguish different sub-branches under the same parent node; the node type identifier distinguishes whether the child node is an internal branch node or a leaf node (e.g., "0x01" for leaf nodes and "0x02" for internal nodes), avoiding confusion between different types of node information; the node hash value is the hash result of the child node (for leaf nodes, it's the hash of the module content; for internal nodes, it's the hash of the aggregated sub-nodes). All three types of information from all child nodes are sorted lexicographically by path fragment and concatenated using a fixed byte encoding format to form the child node aggregation data string for that non-leaf node.

[0070] The second step is to calculate the hash value of the lowest-level internal nodes. In the Merkle Patricia Trie structure, the internal nodes (lowest-level branch nodes) that directly connect to leaf nodes are the starting point for aggregation. For example, if an internal node has three leaf nodes as its direct children (corresponding to path segments "a", "b", and "c"), then these three child nodes are first arranged in lexicographical order, and then the following are extracted sequentially: "path segment identifier (a / b / c) + node type identifier (all 0x01) + node hash value (H)". a / H b / H c ), and press "a+0x01+H" to store this information. a +b+0x02+H b +c+0x01+H c The nodes are concatenated into a complete byte stream in the format of “”, and then the same cryptographic hash operation as that performed on the leaf node is performed on the byte stream to generate the hash value of the lowest level internal node (denoted as H1). At this time, H1 contains the complete information of all its subordinate leaf nodes.

[0071] The third step involves calculating the hash value of the parent node based on the hash result of the lowest-level internal node. For example, if the node corresponding to H1 shares the same parent node as another lowest-level internal node with hash value H2 (corresponding to other leaf node branches), then the "path fragment identifier + node type identifier (0x02) + H1" of node H1 and the "path fragment identifier + node type identifier (0x02) + H2" of node H2 are collected according to the same rules. These are then concatenated in lexicographical order to form a new aggregated byte stream, and a hash operation is performed to obtain the parent node hash value H3. H3 has now aggregated the complete information of all leaf nodes under H1 and H2. This process is repeated, and for each internal node at each level of the tree structure, the aggregation range is gradually passed upwards by aggregating the key information of its direct child nodes and performing hash operations to generate its own hash value, until all branches of the tree structure are covered.

[0072] The fourth step is to generate the hash value H of the top-level root node. root When the aggregation process reaches the highest level of the tree structure (where there is only one top-level root node and no higher-level parent nodes), the hash calculation logic of the root node is consistent with that of other internal nodes: Collect the "path segment identifier + node type identifier + child node hash value" of all direct child nodes of the root node (i.e., the core branch nodes of the second level of the tree structure), sort and concatenate them according to rules to form the aggregated byte stream of the root node, and perform a final cryptographic hash operation on this byte stream. The result is the hash value of the top-level root node. Since this process starts from all leaf nodes (corresponding to all firmware modules), and goes through layer-by-layer aggregation and hash operations at each level of branch nodes, the final H... rootIt has fully contained the integrity information of all nodes in the entire tree structure. Any change in the content of any leaf node (firmware module) will cause a change in the hash value of its corresponding child nodes, which will propagate upwards along the aggregation path and ultimately be reflected in H. root On the changes.

[0073] The aforementioned structured construction using Merkle-Patricia prefix trees transforms the scattered "storage path-hash value" basic data into a unified firmware integrity verification benchmark (root hash). This leverages the path-sharing characteristic of prefix trees to optimize storage and verification efficiency, while utilizing the hash chain verification of Merkle trees to achieve traceability of tampering. If the root hash verification fails, the path branch corresponding to the tampered module can be quickly located by comparing the hash values ​​of branch nodes layer by layer, without traversing all modules. The final generated root hash condenses the integrity status of multiple scattered modules into a fixed-length hash value, which is convenient for storage in the hardware security module and can also serve as the core benchmark for subsequent verification.

[0074] In some embodiments, when generating structured description information for the tree structure, the structured description information is generated based on the storage path of each functional module, the hash value of the content data, the hash algorithm identifier used, the security level label, and the version identifier of the tree structure.

[0075] Structured descriptive information is fundamental to achieving traceability in verification. This descriptive information is not a single piece of data, but rather integrates key metadata required for firmware verification. The storage paths of each functional module and the hash values ​​of their corresponding content data provide the initial comparison basis for subsequent verification; hash algorithm identifiers (such as SHA-256, SM3) clarify the verification algorithm standard, ensuring algorithm consistency during subsequent verification; module security level labels (such as high / medium / low) provide a basis for differentiated verification; and the tree-structured version identifier adapts to structural compatibility management in firmware update scenarios. This structured integration of information ensures that the hardware security module stores not only the root hash as a result-based benchmark, but also the procedural metadata required for verification, ensuring that the verification context can be fully restored during subsequent verification and avoiding verification failures due to missing information.

[0076] In some embodiments, the root hash and structured description information of the tree structure are transmitted to the hardware security module via a preset secure programming interface. The hardware security module then performs a verification operation on the root hash and structured description information, writes the verified root hash and structured description information into the storage area of ​​the hardware security module, and sets the access control policy for the storage area. A hardware circuit breaker mechanism is then triggered to lock the storage area.

[0077] The root hash and structured description information are transmitted to the hardware security module for trusted storage via a pre-defined secure programming interface. Within the hardware security module, verification is performed on the root hash and structured description information; the root hash is written to the persistent storage area, and access control policies are set. Upon completion, a hardware circuit breaker mechanism is triggered to lock the persistent storage area. The access control policies prohibit any runtime modification or read operations except during the trusted boot process.

[0078] Through the trusted storage and access control mechanism of the Hardware Security Module (HSM), the core benchmark for firmware integrity verification (root hash H) is established. root It provides tamper-proof and traceable secure storage for core verification data and related information, eliminating the risk of core verification data being forged, tampered with, or illegally accessed from the hardware level.

[0079] The above approach ensures traceability of verification through structured description information, secure data transmission and writing through dedicated interfaces and internal verification, and constructs a multi-layered anti-tampering barrier through protected storage areas, access control policies, and hardware circuit breakers. Ultimately, it achieves hardware-level trusted storage of root hash and associated verification information, providing an unshakable and trustworthy foundation for subsequent firmware integrity verification, remote proof, and other processes.

[0080] Specifically, data is transmitted through a dedicated secure programming interface during the device manufacturing phase, blocking security risks at the source. This dedicated secure programming interface during manufacturing differs from the ordinary interface used during runtime, featuring physical isolation and encrypted transmission, effectively preventing eavesdropping, tampering, or injection of malicious data during data transmission. Compared to dynamic writing at runtime, the one-time secure transmission during manufacturing better ensures the purity of the written data, avoiding security vulnerabilities caused by the complexity of the runtime environment. This design ensures H... root The entire process of generating and writing structured description information into the hardware security module was not subject to unauthorized interference, laying the foundation for subsequent trusted verification.

[0081] The internal verification operations of the hardware security module serve as the final security barrier before data is written. These verification operations include data integrity checks (such as verifying whether data has been lost or tampered with during transmission) and format validity checks (such as verifying whether structured description information conforms to a preset format and whether the hash algorithm identifier is within the supported range). Data that passes these verifications is allowed to be written to the storage area. This step leverages the isolation characteristics of the hardware security module to exclude invalid or malicious data before it is formally stored, preventing unauthorized data from entering the protected area and further enhancing the trustworthiness of the stored data.

[0082] Writing to a protected persistent storage area and setting access control policies are the core means of achieving trusted storage. The protected persistent storage area of ​​the hardware security module possesses physical isolation and tamper-proof hardware characteristics, resisting both physical and logical attacks. The access control policy settings restrict the scope of data access at the permission level, allowing only the core process of firmware trusted boot to read the root hash for integrity verification, preventing other processes from illegally modifying or reading the data during runtime, and ensuring H... root The structured description information always remains in its original state as written during the manufacturing stage, becoming an immutable and trustworthy root.

[0083] Triggering the hardware circuit breaker mechanism to lock the storage area provides ultimate protection: a one-time write operation ensures permanent and reliable data. The hardware circuit breaker is an irreversible locking mechanism at the hardware level. Once triggered, the storage area is permanently locked, and no subsequent operations (including legitimate update requests) can modify or erase the data. This design fundamentally eliminates the possibility of subsequent attacks tampering with the stored data, ensuring H... root The stability and reliability of structured description information throughout the entire device lifecycle provide a reliable benchmark for firmware integrity verification that spans the entire lifecycle of the device.

[0084] S203. Filter out the target functional modules based on the security level tags included in the structured description information, and determine the verification path of the target functional modules in the tree structure based on the storage path of the target functional modules.

[0085] The system reads structured description information and filters out high-security target functional modules based on their security level tags. These modules include system initialization scripts, critical service programs, and firmware update components. These target functional modules are the core of the baseboard management controller firmware, and their integrity directly determines the security of the entire firmware system. Specifically, the system initialization script affects the reliability of startup; critical service programs ensure core hardware management functions; and the firmware update components protect against malicious update attacks.

[0086] In some embodiments, when determining the verification path of the target functional module in the tree structure based on the storage path of the target functional module, the hash sequence of its sibling nodes in the tree structure is obtained according to its storage path to form a verification path from the leaf node to the root node.

[0087] Among them, sibling nodes are all adjacent nodes on the path from the leaf node to the root node of the target functional module. This path constitutes a complete verification path from the leaf node to the root node, thus eliminating the need to obtain all node information of the entire tree structure.

[0088] Specifically, the firmware integrity daemon of the open-source baseboard management controller is launched. This daemon reads structured description information from the hardware security module and filters out high-security functional modules based on the security level tags. The firmware integrity daemon extracts sibling nodes from the tree structure based on the storage path of the target functional module. The storage path, as the unique logical identifier of the target functional module in the tree structure, can be directly mapped to the corresponding leaf node position, thereby accurately locating the complete path from the leaf node to the root node. The sibling node hash sequence covers the hash information of all adjacent nodes on the path. This information is the core basis for aggregating upwards layer by layer to generate the root hash. The hash value of each sibling node carries the integrity state of the corresponding branch, which, together with the current hash value of the target module, constitutes the complete input for reconstructing the root hash.

[0089] The above embodiments construct the verification path by extracting the hash sequence of sibling nodes on the target functional module path, avoiding a full traversal of the entire tree structure, reducing the amount of data read and overhead during the verification process, and improving the response speed of integrity verification.

[0090] This application addresses scenarios involving updates to certain functional modules by generating a set of difference blocks between the old and new tree structures, along with corresponding verification paths. This forms lightweight incremental proof data, avoiding the bandwidth consumption and latency associated with full firmware data transmission while ensuring the integrity of the incremental update can be remotely verified. This improves the efficiency and security of firmware updates in large-scale device clusters, balancing practicality and security.

[0091] S204. Generate a reconstructed root hash based on the verification path.

[0092] Based on the verification path corresponding to the target functional module in the tree structure, the reconstructed root hash is generated by calculating layer by layer upwards according to the reconstruction rules of the Merkel prefix tree.

[0093] In some embodiments, when performing step S204, a hash operation is first performed on the content data of the target functional module to generate the current hash value, and the current hash value is used as the leaf node hash value; then, based on the leaf node hash value, the hash values ​​of sibling nodes are aggregated upwards layer by layer to generate the reconstructed root hash.

[0094] Specifically, the firmware integrity daemon uses the current hash value of the target functional module as the leaf node hash value, combines it with the hash values ​​of sibling nodes in the verification path, and calculates upwards layer by layer according to the hash aggregation rules of the Merkle Patricia Trie to finally generate the reconstructed root hash. This process does not require traversing the entire tree; the root hash reconstruction is completed through the verification path of a single target functional module, improving verification efficiency. Furthermore, since the verification path contains information on all key nodes in the branch where the target functional module resides, the reconstructed root hash accurately reflects the integrity status of the module and its corresponding branch.

[0095] The above embodiments recalculate the current hash value of high-security modules, ensuring the real-time nature and authenticity of the verification data. For each selected high-security module, the daemon process does not rely on pre-stored historical hash values, but directly reads its currently stored content data from the storage medium, re-executes the same cryptographic hash algorithm as when the tree structure was initially built, and generates the current hash value. This design avoids verification failures caused by relying on cached data or historical records, ensuring that the hash value can truly reflect the current integrity status of the module. If the module content is maliciously tampered with, its current hash value will differ from the original hash value pre-stored in the Merkle Patricia Trie, providing an accurate basis for subsequent verification.

[0096] S205. Compare the reconstructed root hash with the root hash to verify the integrity of the baseboard management controller firmware.

[0097] The firmware integrity daemon performs tamper detection and security response by comparing the reconstructed root hash with the pre-stored root hash. The generated reconstructed root hash is compared with the root hash stored in the hardware security module. If they match, it means that the target functional module and all nodes in its branch have not been tampered with, and the integrity of the core firmware function is guaranteed. If they do not match, it means that the target functional module itself or a node on its path has been tampered with, and the firmware integrity is directly determined to have been compromised.

[0098] Optionally, if the integrity of the baseboard management controller firmware is compromised, a preset security response strategy can be triggered, including but not limited to interrupting firmware operation, disabling critical services, reporting tampering alarms, and restoring the original firmware version. This quickly blocks the spread of malicious attacks and reduces the security risks caused by tampering.

[0099] The above embodiments focus on target functional modules with high security levels, rather than all functional modules. This reduces the resource consumption of the verification process and concentrates security protection resources on key links, thereby improving the targeting and efficiency of verification.

[0100] In summary, the integrity verification method for the baseboard management controller firmware provided in this application converts scattered firmware data into a standardized data set corresponding to hash values ​​of storage paths by parsing the logical functional partitions and extracting functional modules of the baseboard management controller firmware. This constructs a tree structure, condensing the firmware integrity status into a root hash, enabling comprehensive verification of all functional modules. By selecting target functional modules for focused protection, verification blind spots are avoided. The prefix-sharing characteristic of the tree structure reduces redundant node storage, and the construction of verification paths based on sibling nodes eliminates the need to traverse the entire tree for verification of a single functional module. The root hash can be reconstructed by aggregating local nodes layer by layer, reducing data reading and computation overhead.

[0101] In some embodiments, the integrity verification method for the baseboard management controller firmware provided in this application further includes: when the system powers on, the first-stage boot code in the read-only memory performs basic hardware initialization operations; then the first-stage boot code loads the bootloader and verifies the integrity of the bootloader. If the bootloader passes verification, the bootloader loads the kernel image into a preset address range in memory. This triggers a dynamic root of trust mechanism, creating an isolated secure execution environment. In the isolated secure execution environment, the preset address range is accessed to obtain the data content of the kernel image, and then a hash operation is performed on the data content of the kernel image to generate a hash value of the kernel image at runtime, which is then extended to the platform configuration register.

[0102] Specifically, during the system boot process, basic hardware initialization is first performed by the first-stage boot code in the read-only memory (ROM). Since the code in the ROM is fixed and unmodifiable, it has a natural foundation of trust, and starting from this point can prevent the boot process from being tampered with at its source.

[0103] After hardware initialization is complete, the bootloader is loaded and its initial code block is verified for integrity. This verification step provides a trusted execution environment for the subsequent loading of the kernel image, ensuring that the bootloader itself has not been injected with malicious code.

[0104] The bootloader loads the kernel image from non-volatile storage into a preset address range in memory, completing the preparation work before the kernel runs. Then, a dynamic root of trust mechanism is triggered, creating an isolated secure execution environment independent of the normal execution environment through security instructions provided by the processor. This secure execution environment possesses features such as memory isolation and code isolation, resisting interference from malicious processes in the normal runtime environment and preventing tampering with the hash calculation process, such as malicious programs replacing kernel image data in memory or altering intermediate hash calculation results.

[0105] In a secure execution environment, a preset address range in memory is accessed to obtain the data content of the memory image, ensuring that the input data for the hash calculation is completely consistent with the kernel image loaded into memory; a cryptographic hash algorithm is then executed on the data content of the memory image to calculate the runtime hash value h of the kernel image. kernel This hash value is a digital fingerprint of the integrity status after the kernel image is loaded.

[0106] The platform configuration register extension interface provided by the trusted platform module is invoked to extend the runtime hash value to the platform configuration register (PCR), which is specifically used to store integrity status. During the extension, the currently stored hash value in the register is first compared with the newly calculated hash value. kernel Concatenate the data byte by byte, then perform a hash operation on the concatenated complete data, and update R with the result. integrity The new value of R. This superimposed extension design makes R... integrity The final value not only contains the integrity information of the current kernel image but also inherits the trusted state from the previous boot phase. Furthermore, because the PCR possesses the hardware characteristic of being immutable once written and can only be updated through a dedicated extension interface, R... integrity The kernel integrity state stored in the kernel cannot be modified by malicious programs during runtime, thus serving as a trusted hardware benchmark for subsequent verification of whether the kernel has been tampered with.

[0107] The above embodiments solidify the runtime integrity state of the kernel image into the hardware registers of the Trusted Platform Module (TPM), constructing a trusted link from boot to kernel operation, and eliminating the risk of the kernel image being tampered with in the early stages of loading or running.

[0108] In some embodiments, the integrity verification method for the baseboard management controller firmware provided in this application further includes: calculating a file hash value based on the data content of the target firmware file when the target firmware file is written or executed, then querying the pre-stored hash value corresponding to the file path of the target firmware file, and comparing the file hash value with the pre-stored hash value. If the two do not match, it is determined that the target firmware file has been tampered with, the writing or execution of the target firmware file is blocked, and a security alarm log is generated.

[0109] The target firmware file is the firmware file located in a preset critical path, such as the path where system initialization scripts, key service programs, and firmware update components are located. The pre-stored hash value is the original digital fingerprint of the file when it has not been tampered with.

[0110] The Extended Berkeley Packet Filter (eBPF) program can be loaded to detect whether a target firmware file is being written to or executed. The eBPF program is a lightweight kernel-level program used for kernel event tracing and network packet filtering, enabling real-time monitoring of network data flow. Deploying the eBPF program at the kernel level bypasses potential interference from user space, directly capturing all access requests to the target file, ensuring comprehensive and reliable monitoring.

[0111] When the eBPF program detects a write or execution operation on a target file under a preset critical path, it first pauses the execution of the operation to prevent the file from being written or executed before the verification is completed, thus preventing malicious files from bypassing the protection by exploiting the timing difference of the operation.

[0112] Then, the content data of the target firmware file is obtained, and the same cryptographic hash algorithm used during the initial construction of the Merkle Patricia Trie is executed to calculate the file hash value. Simultaneously, the pre-stored hash value corresponding to the preset critical path is queried from the structured description information of the tree structure stored in the hardware security module. If they do not match, it indicates that the target firmware file has been tampered with, and write or execution operations are blocked, preventing malicious files from damaging the firmware system at the source. At the same time, a security alarm log is generated, containing information such as the operation process identifier, file path, tampering time, and hash value difference. If they match, it indicates that the target firmware file is intact, and write or execution operations continue, ensuring that legitimate operations are not affected and maintaining the normal operation of the firmware system.

[0113] The above embodiments use eBPF programs to achieve real-time interception and dynamic hash verification of access to critical firmware files. By pausing the execution process, the verification timing is ensured to be secure. By accurately identifying file tampering through hash comparison, malicious operations on critical files after startup can be intercepted in real time, achieving continuous security protection throughout the firmware's entire lifecycle.

[0114] In some embodiments, the integrity verification method for the baseboard management controller firmware provided in this application further includes: receiving an integrity proof request sent from a remote management terminal; reading the hash extension value of the platform configuration register from the trusted platform module, the hash extension value being used to reflect the integrity of the device's dynamic operating state; reading the root hash of the tree structure from the hardware security module, the root hash being used to reflect the integrity of the device's static storage state; constructing a proof data packet based on the hash extension value, the root hash, the device identifier, the current timestamp, and a random value; digitally signing the proof data packet using an asymmetric private key to generate a signature value; and encapsulating the proof data packet and the signature value into an integrity proof response message, and returning the response message to the remote management terminal.

[0115] In this process, remote management endpoints (such as data center cloud management platforms and equipment maintenance systems) send integrity verification request messages through the industry-standard Redfish protocol (suitable for modern cloud infrastructure) or the IPMI protocol (compatible with traditional server hardware). Both of these protocols are standardized protocols in the hardware management field, ensuring that devices from different manufacturers and models can be uniformly invoked by the remote management endpoint, avoiding the invalidation of remote verification due to protocol incompatibility.

[0116] The device's unique identifier is used by the remote management end to locate the target device and avoid cross-device confusion; the current timestamp can prevent replay attacks and ensure the timeliness of the proof message; the random challenge value is generated by the remote management end or randomly generated by the device to prevent malicious attackers from forging proof messages.

[0117] Specifically, integrity verification requests are received from the remote management terminal via Redfish or IPMI protocols. The platform configuration register R is read from the Trusted Platform Module. integrity The hash extension value. The hash extension is generated through hash extension operations during the boot phase, recording the entire metric history from the ROM boot code and bootloader to the kernel image. It is a core benchmark for the integrity of the device's dynamic operating state, reflecting whether the device boot process has been tampered with. The root hash H of the pre-stored tree structure is read from the hardware security module. root The root hash is an aggregate representation of the static storage state of all functional modules in the firmware, reflecting the integrity of the firmware storage layer.

[0118] By integrating the hash extension value, root hash, device identifier, current timestamp, and random value to construct the proof data packet, the remote management terminal can verify the device identity and proof validity while obtaining complete integrity status data, ensuring the rigor of the verification logic. Furthermore, the device's built-in asymmetric private key is used to perform a digital signature operation on the constructed proof data packet, generating a unique signature value, providing cryptographic protection for the feasibility of the proof data packet.

[0119] Subsequently, the proof data packet and signature value are encapsulated into an integrity proof response message and returned to the remote management end through a secure communication channel (such as HTTPS encrypted transmission) to prevent the request from being eavesdropped on, tampered with, or forged.

[0120] After receiving the response, the remote management terminal can use the public key to verify the trusted status of the device. First, it verifies the validity of the signature value: if the signature verification passes, it means the data packet has not been tampered with and indeed originated from the target device. Then, it can be verified by comparing the R... integrity The expected value (such as a pre-stored confidence metric sequence) and H root The pre-stored value is used to determine the current trusted status of the device; if the signature verification fails, the proof message is directly deemed invalid, and the device is refused to be trusted.

[0121] The above embodiments achieve cross-platform compatibility through the Redfish / IPMI protocol, ensure the comprehensiveness of the proof through two-dimensional state data, and guarantee the credibility of the message through asymmetric encryption signature. Ultimately, they provide the remote management end with a verifiable and unforgeable proof of device integrity, effectively solving the problem of difficulty in confirming the trusted status of remote devices in distributed deployment scenarios.

[0122] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0123] like Figure 3 As shown, embodiments of this application also provide an integrity verification device for the firmware of a baseboard management controller, the device comprising:

[0124] The acquisition module 301 is used to acquire the storage path and content data of each functional module in the firmware of the baseboard management controller;

[0125] The determination module 302 is used to construct a tree structure based on the storage path and content data of each functional module, and to determine the root hash and structured description information of the tree structure; wherein, the data units of the tree structure are stored hierarchically according to the prefix of the storage path, and a hash value is generated for the content data;

[0126] The filtering module 303 is used to filter out target functional modules based on the security level tags included in the structured description information, and to determine the verification path of the target functional module in the tree structure based on the storage path of the target functional module.

[0127] Generation module 304 is used to generate a reconstructed root hash based on the verification path;

[0128] The verification module 305 is used to compare the reconstructed root hash with the root hash to verify the integrity of the baseboard management controller firmware.

[0129] As an optional implementation provided in this application, the acquisition module 301 is specifically used for: parsing the firmware of the baseboard management controller and identifying the multiple logical function partitions it contains; extracting functional modules from the multiple logical function partitions and determining the storage path of each functional module; locating the physical offset address and data length of each functional module in the baseboard management controller firmware according to the storage path; and reading the content data of each functional module according to the physical offset address and data length.

[0130] As an optional implementation provided in this application, the determining module 302 is specifically used for: mapping the storage paths of each functional module to branch paths of a tree structure according to the directory hierarchy; establishing internal nodes of the tree structure according to the path prefix sharing principle; the path prefix sharing principle means that when the storage path prefixes of functional modules are the same, the branch nodes corresponding to the storage path prefix are shared; inserting leaf nodes into the tree structure with the storage path of each functional module as the key and the content data as the value, the leaf nodes are the mappings of the functional modules; calculating the hash value of the bottom-level internal node, the bottom-level internal node is the internal node in the tree structure that is directly connected to the leaf node; based on the hash value of the bottom-level internal node, aggregating the hash values ​​of branch nodes layer by layer upwards until the branches covering the tree structure are obtained to obtain the hash value of the top-level root node; using the hash value of the top-level root node as the root hash; generating structured description information according to the storage path of each functional module, the hash value of the content data, the hash algorithm identifier used, the security level label, and the version identifier of the tree structure.

[0131] As an optional implementation provided in this application, the filtering module 303, when determining the verification path of the target functional module in the tree structure according to the storage path of the target functional module, is specifically used to: obtain the hash sequence of the sibling nodes of the target functional module in the tree structure according to the storage path of the target functional module, and form a verification path; wherein, the sibling node is an adjacent node on the path from the leaf node to the root node corresponding to the target functional module.

[0132] As an optional implementation provided in this application, the generation module 304 is specifically used to: perform a hash operation on the content data of the target functional module to generate a current hash value, and use the current hash value as the leaf node hash value; based on the leaf node hash value, aggregate the hash values ​​of sibling nodes layer by layer upwards to generate a reconstructed root hash.

[0133] As an optional implementation provided in this application, the device further includes a remote integrity verification module, configured to: receive an integrity verification request sent from a remote management terminal; read the hash extension value of the platform configuration register from the trusted platform module, the hash extension value being used to reflect the integrity of the device's dynamic operating state; read the root hash of the tree structure from the hardware security module, the root hash being used to reflect the integrity of the device's static storage state; generate a verification data packet based on the hash extension value and the root hash, as well as the device identifier, current timestamp, and random value; digitally sign the verification data packet using an asymmetric private key to generate a signature value; encapsulate the signature value and the data packet into a response message for the integrity verification request; and return the response message to the remote management terminal.

[0134] As an optional implementation provided in this application, the device further includes a hardware security module, used for: transmitting the root hash and structured description information to the hardware security module through a preset secure programming interface; performing a verification operation on the root hash and structured description information through the hardware security module; writing the verified root hash and structured description information into the storage area of ​​the hardware security module and setting the access control policy of the storage area; and triggering a hardware circuit breaker mechanism to lock the storage area.

[0135] As an optional implementation provided in this application, the device further includes a kernel image loading module, configured to: perform basic hardware initialization operations by the first-stage boot code in the read-only memory during system power-on startup; load a bootloader by the first-stage boot code and verify the integrity of the bootloader; if the bootloader passes verification, load the kernel image into a preset address range in memory by the bootloader; trigger a dynamic root of trust mechanism to create an isolated secure execution environment; access the preset address range in the isolated secure execution environment to obtain the data content of the kernel image; perform a hash operation on the data content of the kernel image to generate a hash value of the kernel image at runtime; and extend the hash value of the kernel image at runtime to the platform configuration register.

[0136] As an optional implementation provided in this application, the device further includes a monitoring module, configured to: calculate a file hash value based on the data content of the target firmware file when the target firmware file is written or executed; query the pre-stored hash value corresponding to the file path of the target firmware file; compare the file hash value with the pre-stored hash value; if the file hash value does not match the pre-stored hash value, determine that the target firmware file has been tampered with, block the writing or execution of the target firmware file, and generate a security alarm log.

[0137] For a description of the features in the embodiment corresponding to the integrity verification device for the baseboard management controller firmware, please refer to the relevant description of the embodiment corresponding to the integrity verification method for the baseboard management controller firmware, which will not be repeated here.

[0138] like Figure 4 As shown, embodiments of this application also provide an electronic device, including a memory 401 and a processor 402. The memory 401 stores a computer program, and the processor 402 is configured to run the computer program to perform the steps in any of the above embodiments of the integrity verification method for the baseboard management controller firmware.

[0139] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above embodiments of the integrity verification method for baseboard management controller firmware.

[0140] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0141] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above embodiments of the integrity verification method for the baseboard management controller firmware.

[0142] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above embodiments of the integrity verification method for the baseboard management controller firmware.

[0143] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0144] The integrity verification method and electronic device for a baseboard management controller firmware provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only intended to help understand the method and core ideas of this application. It should be noted that those skilled in the art can make several improvements and modifications to this application without departing from the principles of this application, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A method for verifying the integrity of firmware for a baseboard management controller, characterized in that, include: Obtain the storage path and content data of each functional module in the firmware of the baseboard management controller; A tree structure is constructed based on the storage path and content data of each functional module, and the root hash and structured description information of the tree structure are determined; wherein, the data units of the tree structure are stored hierarchically according to the prefix of the storage path, and a hash value is generated for the content data; The target functional modules are selected based on the security level tags included in the structured description information, and the verification path corresponding to the target functional modules in the tree structure is determined based on the storage path of the target functional modules. Generate a reconstructed root hash based on the verification path; The integrity of the baseboard management controller firmware is verified by comparing the reconstructed root hash with the root hash. The step of constructing a tree structure based on the storage paths and content data of each functional module, and determining the root hash and structured description information of the tree structure, includes: The storage paths of each functional module are mapped to branch paths of the tree structure according to the directory hierarchy; Based on the path prefix sharing principle, the internal nodes of the tree structure are established; wherein, the path prefix sharing principle means that when the storage path prefixes of functional modules are the same, the branch nodes corresponding to the storage path prefix are shared; Using the storage path of each functional module as the key and the content data as the value, leaf nodes are inserted into the tree structure, and the leaf nodes are mappings of the functional modules. Calculate the hash value of the bottom-most internal node of the tree structure, where the bottom-most internal node is the internal node in the tree structure that is directly connected to the leaf node; Based on the hash value of the lowest-level internal node, the hash values ​​of the branch nodes are aggregated layer by layer upwards until the branch covering the tree structure is obtained to obtain the hash value of the top-level root node; Use the hash value of the top-level root node as the root hash; The structured description information is generated based on the storage path of each functional module, the hash value of the content data, the hash algorithm identifier used, the security level label, and the version identifier of the tree structure.

2. The method according to claim 1, characterized in that, The acquisition of the storage paths and content data of each functional module in the baseboard management controller firmware includes: The firmware of the baseboard management controller is parsed to identify its multiple logical function partitions; Extract functional modules from the multiple logical functional partitions and determine the storage path of each functional module; Based on the storage path, locate the physical offset address and data length of each functional module in the firmware of the baseboard management controller; The content data of each functional module is read based on the physical offset address and data length.

3. The method according to claim 1, characterized in that, Determining the verification path of the target functional module corresponding to the tree structure based on the storage path of the target functional module includes: Based on the storage path of the target functional module, obtain the hash sequence of the sibling nodes of the target functional module in the tree structure to form the verification path; The sibling node is the adjacent node on the path from the leaf node to the root node corresponding to the target functional module.

4. The method according to claim 3, characterized in that, The step of generating the reconstructed root hash based on the verification path includes: Perform a hash operation on the content data of the target functional module to generate a current hash value, and use the current hash value as the leaf node hash value; Based on the hash value of the leaf node, the hash values ​​of the sibling nodes are aggregated layer by layer upwards to generate the reconstructed root hash.

5. The method according to claim 1, characterized in that, After constructing a tree structure based on the storage paths and content data of each functional module, and determining the root hash and structured description information of the tree structure, the method further includes: The root hash and the structured description information are transmitted to the hardware security module through a preset secure programming interface; The hardware security module performs a verification operation on the root hash and the structured description information. The verified root hash and structured description information are written into the storage area of ​​the hardware security module, and the access control policy of the storage area is set. The hardware circuit breaker mechanism is triggered to lock the storage area.

6. The method according to claim 5, characterized in that, The method further includes: Receive integrity verification requests from remote management terminals; Read the hash extension value of the platform configuration register from the trusted platform module. The hash extension value is used to reflect the integrity of the device's dynamic operating status. The root hash of the tree structure is read from the hardware security module. The root hash is used to reflect the integrity of the device's static storage state. A proof data packet is generated based on the hash extension value and the root hash, as well as the device identifier, current timestamp, and random value; The proof data packet is digitally signed using an asymmetric private key to generate a signature value; The signature value and the data packet are encapsulated into a response message for the integrity proof request; The response message is returned to the remote management terminal.

7. The method according to claim 1, characterized in that, The method further includes: During the system power-on startup process, basic hardware initialization operations are performed by the first-stage boot code in the read-only memory; The bootloader is loaded by the first-stage boot code, and the integrity of the bootloader is verified. If the bootloader passes verification, the bootloader loads the kernel image into a preset address range in memory; Trigger the dynamic root of trust mechanism to create an isolated secure execution environment; In the isolated secure execution environment, the preset address range is accessed to obtain the data content of the kernel image; Perform a hash operation on the data content of the kernel image to generate the hash value of the kernel image at runtime; The runtime hash value of the kernel image is extended to the platform configuration register.

8. The method according to claim 1, characterized in that, The method further includes: When the target firmware file is written or executed, the file hash value is calculated based on the data content of the target firmware file; Query the pre-stored hash value corresponding to the file path of the target firmware file; Compare the file hash value with the pre-stored hash value; If the file hash value does not match the pre-stored hash value, it is determined that the target firmware file has been tampered with, the writing or execution of the target firmware file is blocked, and a security alarm log is generated.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the integrity verification method for the baseboard management controller firmware as described in any one of claims 1 to 8 when executing the computer program.

Images