System, method, and baseboard management controller for updating root of trust firmware

Abstract

This application provides a system, method, and baseboard management controller for updating root firmware, which can be applied to the field of firmware security technology. The update system includes: a baseboard management controller, configured to perform third-party security authentication with a security processor and the root firmware in response to an update command carrying target version information; if the third-party security authentication is successful, to obtain the target root firmware corresponding to the target version information and to read the backup image firmware corresponding to the root firmware to be updated in the main storage area of ​​the security processor from the backup storage area; to compare the backup image firmware with the target root firmware to generate a differential update package; to split the differential update package into multiple encrypted data blocks; and a security processor communicatively connected to the baseboard management controller, configured to receive the multiple encrypted data blocks and write them into the main storage area of ​​the security processor to complete the update of the root firmware to be updated.

Description

Technical Field

[0001] This application relates to the field of firmware security technology, specifically to a trusted root firmware update system, method, and baseboard management controller. Background Technology

[0002] Existing server firmware security update solutions, especially those targeting platform root firmware, largely rely on full image transfers and static signature-based verification methods. These methods cannot achieve dynamic mutual recognition between firmware source, hardware identity, and update commands, posing security risks of source forgery and hardware identity impersonation.

[0003] Meanwhile, full update mode results in high network bandwidth consumption, long update time, and a lack of real-time linkage with hardware operating status, making it difficult to quickly interrupt and recover from hardware anomalies during the update process. Therefore, there is an urgent need for a firmware update solution that can achieve high efficiency, security, and hardware status coordination. Summary of the Invention

[0004] In view of the above problems, this application provides a trusted root firmware update system, method and baseboard management controller to achieve efficient and secure firmware updates while ensuring the trustworthiness of the firmware source and the authenticity of the hardware identity.

[0005] According to a first aspect of this application, a system for updating root trust firmware is provided, comprising: a baseboard management controller, configured to perform third-party security authentication with a security processor and the root trust firmware in response to an update command carrying target version information; if the third-party security authentication is successful, to obtain a target root trust firmware corresponding to the target version information, and to read a backup image firmware corresponding to the root trust firmware to be updated in the main storage area of ​​the security processor from a backup storage area; to compare the backup image firmware with the target root trust firmware to generate a differential update package; and to split the differential update package into multiple encrypted data blocks; and a security processor, which is communicatively connected to the baseboard management controller, on which the root trust firmware runs, and is configured to receive multiple encrypted data blocks and write the multiple encrypted data blocks into the main storage area of ​​the security processor to complete the update of the root trust firmware to be updated.

[0006] The second aspect of this application provides a method for updating a root trust firmware, comprising: in response to an update instruction carrying target version information, performing a three-party security authentication with a security processor and the root trust firmware; if the three-party security authentication is successful, obtaining a target root trust firmware corresponding to the target version information, and reading a backup image firmware corresponding to the root trust firmware to be updated in the main storage area of ​​the security processor from a backup storage area; comparing the backup image firmware with the target root trust firmware to generate a differential update package; splitting the differential update package into multiple encrypted data blocks; sending the multiple encrypted data blocks to a security processor that is communicatively connected to a baseboard management controller, triggering the security processor to write the multiple encrypted data blocks into the main storage area of ​​the security processor to complete the update of the root trust firmware to be updated.

[0007] A third aspect of this application provides a baseboard management controller, including: one or more processors and a memory for storing one or more computer programs.

[0008] In this embodiment, the processor and memory are coupled, together forming the hardware foundation for executing the update method of this application. The processor may be a central processing unit (CPU), a microcontroller (MCU), a system-on-a-chip (SoC), or an application-specific integrated circuit (ASIC), etc. The memory may include non-volatile memory (such as ROM, Flash) for storing firmware code, and volatile memory (such as RAM) for storing data and state during program execution. The computer program stored in the memory contains instruction code configured to implement the trusted root firmware update method as described in the first aspect of this application (or referring to any of the foregoing embodiments).

[0009] In one specific embodiment, when one or more processors execute a computer program stored in memory, they are specifically configured to perform the following logical steps: in response to an update instruction, perform third-party security authentication with a security processor acting as root of trust hardware and root of trust firmware running on the security processor; if the third-party security authentication is successful, obtain the target root of trust firmware based on the target firmware version information and read the backup image firmware from the backup storage area; compare the backup image firmware with the target root of trust firmware to generate a differential update package; split the differential update package into multiple encrypted data blocks and transmit them to the security processor via a communication interface to trigger its integrity verification; after confirming that the integrity verification is complete, send a write instruction to the security processor to trigger the security processor to complete the update. The detailed implementation logic of these steps corresponds to the description of the foregoing method embodiments.

[0010] In another embodiment, the baseboard management controller may further include a communication interface (such as an SPI, I2C, or USB controller), a backup storage area (such as an eMMC chip or Flash partition), and a network interface for communicating with an upper-layer management platform. The processor connects to these components via a bus or dedicated interface, coordinating their operation to fully implement the update functions of this application.

[0011] In this embodiment, the update system establishes a trusted mutual recognition foundation between firmware source, hardware identity, and update commands through three-party security authentication involving the baseboard management controller, the security processor, and the trusted root firmware running on them. After successful three-party authentication, the baseboard management controller obtains the target firmware based on the target version information and compares it with the local backup image to generate a differential update package. This differential update package is then split into encrypted data blocks and transmitted to the security processor. The encrypted data blocks received by the security processor are written to the main storage area to complete the update. While ensuring a high level of security in the update process—namely, trustworthy source, authentic identity, and complete data—the incremental update and block transmission mechanism significantly improves the efficiency and system reliability of large-scale updates. Attached Figure Description

[0012] The above-mentioned contents, other objects, features and advantages of this application will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0013] Figure 1 This illustration schematically shows a structural diagram of a trusted root firmware update system according to an embodiment of this application;

[0014] Figure 2 This illustration schematically shows a hardware architecture diagram of a trusted root firmware update system according to an embodiment of this application;

[0015] Figure 3 The diagram illustrates the architecture of the firmware storage and update path according to an embodiment of this application.

[0016] Figure 4 A flowchart illustrating a method for updating trusted root firmware according to an embodiment of this application is shown. Detailed Implementation

[0017] The embodiments of this application will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are merely examples and are not intended to limit the scope of this application. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of this application for ease of explanation. However, it will be apparent that one or more embodiments may be implemented without these specific details. Furthermore, descriptions of well-known structures and technologies are omitted in the following description to avoid unnecessarily obscuring the concepts of this application.

[0018] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The terms “comprising,” “including,” etc., as used herein indicate the presence of features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0019] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0020] When using expressions such as "at least one of A, B and C", they should generally be interpreted in accordance with the meaning that is commonly understood by those skilled in the art (e.g., "a system having at least one of A, B and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B and C, etc.).

[0021] Figure 1 The schematic diagram illustrates the structure of an update system for trusted root firmware according to an embodiment of this application.

[0022] like Figure 1 As shown, the update system consists of a baseboard management controller 101, a security processor 102 as the root of trust hardware, and root of trust firmware 103 running on the security processor 102. The baseboard management controller 101 is connected to the security processor 102 via a communication interface and works together to perform the security update task of the root of trust firmware.

[0023] The root firmware 103, as the foundation of the server hardware trust chain, is responsible for initializing security hardware and verifying upper-layer firmware. Its integrity and trustworthiness directly determine the security status of the entire platform. The baseboard management controller 101 plays a core driving and coordinating management role in the update process, and is responsible for executing the root firmware update method.

[0024] During the update process, the baseboard management controller 101 responds to the update command from the management platform and performs a three-way security authentication with the security processor 102 and the trusted root firmware 103 running on it to ensure mutual trust between the firmware source, hardware identity, and update command. After successful authentication, the baseboard management controller 101 obtains the target firmware based on the target version information and compares it with the backup image read from the backup storage area to generate a differential update package.

[0025] The baseboard management controller 101 splits the differential packet into multiple encrypted data blocks and transmits them sequentially to the security processor 102 via the communication interface, triggering the security processor 102 to perform integrity verification on each data block. After all data blocks pass verification, the baseboard management controller 101 issues a write command to the security processor 102, which then writes the data to its main storage area, thereby completing the secure, incremental update of the trust root firmware 103. This improves update efficiency while ensuring the controllability of the update process and the stability of the entire server hardware trust foundation.

[0026] It should be noted that the root firmware update system in this application embodiment, through its modular and collaborative design, enables it to support distributed deployment and centralized management, and can effectively support large-scale firmware update tasks at the data center level.

[0027] The following will be based on Figure 1 The structural diagram described herein provides a detailed description of the trusted root firmware update system of the disclosed embodiments.

[0028] In this embodiment, the baseboard management controller is used to perform third-party security authentication with the security processor, which is the root of trust hardware, and the root of trust firmware running on the security processor in response to an update command carrying target version information.

[0029] In this embodiment, the update instruction can refer to a command or request data packet initiated by a data center management platform or authorized administrator to start a root trust firmware update process, which at least includes target firmware version information pointing to the target update. The security processor can be a physical chip or security module configured as root trust hardware, such as a chip conforming to the Open Compute Project Caliptra (OCPCaliptra) specification. The security processor integrates a cryptographic engine, a Physical Unclonable Function (PUF) unit, and a secure storage area, providing the system with hardware-level root trust and secure computing capabilities.

[0030] Root firmware is foundational, trusted software running on a secure processor. It is responsible for initializing the hardware trust chain, verifying upper-layer firmware, and managing secure processor resources, serving as the cornerstone for secure startup and operation of a server platform. Root hardware refers to a dedicated hardware module or chip, physically embedded in a computing device (such as a server), that provides the most basic and highest level of trust to the system. Third-party security authentication involves the Baseboard Management Controller (BMC), the secure processor hardware, and the root firmware running on top of the secure processor hardware. Through exchanging and verifying certificates, challenge-response mechanisms, and other methods, they mutually confirm each other's legitimacy, the trustworthiness of the firmware source, and the authorization status of the current update operation.

[0031] The target firmware version information can be metadata used to uniquely identify a specific version of the trusted root firmware to which an update is expected, such as a version number, compiler identifier, or cryptographic hash value. It is the core basis for determining the target firmware to be obtained and for performing version comparison.

[0032] In this embodiment, when the third-party security authentication is successful, the baseboard management controller obtains the target trusted root firmware corresponding to the target version information and reads the backup image firmware corresponding to the trusted root firmware to be updated in the main storage area of ​​the security processor from the backup storage area.

[0033] In this embodiment, the target root firmware refers to a complete binary image of the new version of the root firmware to which the update is expected, determined based on the target firmware version information. It is typically stored in a data center management platform or a local trusted image repository as the source for this update. The backup storage area can be a protected area within non-volatile memory located in the baseboard management controller, specifically used to store a complete copy of the currently running version of the root firmware in the main storage area of ​​the security processor, i.e., the backup image firmware.

[0034] The backup image firmware corresponds exactly to the root trust firmware to be updated and serves as the baseline data source for generating incremental difference packages. It is used to ensure data integrity during rollbacks or when calculating differences. The primary storage area can be a non-volatile storage space located inside the security processor, used to store and directly run the current active version of the root trust firmware, such as a flash security partition. It is the target write location for this update.

[0035] In this embodiment, the baseboard management controller is used to compare the backup image firmware with the target trusted root firmware and generate a difference update package.

[0036] In this embodiment, the baseboard management controller identifies the actual differences between two firmware images instead of transmitting the complete firmware image. The generated difference update package is a structured and encrypted data set that reflects the minimum set of data changes required to transition from the current backup version to the target version. This incremental update method significantly reduces the amount of data that needs to be transmitted and processed, thereby improving update efficiency and reducing the consumption of network bandwidth and computing resources.

[0037] In this embodiment, the baseboard management controller is used to split the differential update package into multiple encrypted data blocks and transmit the multiple encrypted data blocks to the security processor respectively.

[0038] In this embodiment, the baseboard management controller splits the differential update packet into a series of smaller, independently processable data units that conform to the transmission channel capacity. Each data unit, after independent encryption, forms an encrypted data block. These encrypted data blocks are sequentially sent to the security processor via a communication interface (such as SPI, I2C, or a USB secure channel). During transmission, the security processor simultaneously performs an integrity check on each received encrypted data block.

[0039] In this embodiment of the application, when the integrity verification is completed, a write command is sent to the security processor to trigger the security processor to write multiple encrypted data blocks that have passed the verification to the main storage area of ​​the security processor, so as to complete the update of the trust root firmware to be updated.

[0040] In this embodiment, after determining that all encrypted data blocks have passed integrity verification, the baseboard management controller sends a specific write command to the security processor. The write command authorizes and triggers the security processor to perform the write operation. Upon receiving this command, the security processor merges the multiple encrypted data blocks that have passed verification according to their logical order and internal structure, and writes them into its own main storage area, i.e., the dedicated storage partition used to store the root trust firmware.

[0041] In this embodiment, the update system establishes a trusted mutual recognition foundation between firmware source, hardware identity, and update commands through three-party security authentication involving the baseboard management controller, the security processor, and the trusted root firmware running on them. After successful three-party authentication, the baseboard management controller obtains the target firmware based on the target version information and compares it with the local backup image to generate a differential update package. This differential update package is then split into encrypted data blocks and transmitted to the security processor. The encrypted data blocks received by the security processor are written to the main storage area to complete the update. While ensuring a high level of security in the update process—namely, trustworthy source, authentic identity, and complete data—the incremental update and block transmission mechanism significantly improves the efficiency and system reliability of large-scale updates.

[0042] In this embodiment, the update system further includes a data management platform; the baseboard management controller receives an update instruction from the upper-layer data management platform, the update instruction carrying a digital signature certificate. The digital signature certificate includes at least the target firmware version, its cryptographic hash value, and a digital signature generated by the Open Compute Project's private key; the complete firmware image is not transmitted at this time.

[0043] In this embodiment, the baseboard management controller is used to verify the authorization security of the update instruction by comparing the preset root certificate public key with the digital signature certificate carried in the update instruction.

[0044] In this embodiment, the baseboard management controller needs to verify the legitimacy of the update command. Using a pre-stored authoritative root certificate public key, it decrypts and compares the digital signature certificate carried by the update command to determine whether the update is trusted and whether the command content is complete. This verification is a prerequisite for initiating subsequent security processes, ensuring the legitimacy and basic security of the update operation.

[0045] In this embodiment, the baseboard management controller is used to obtain hardware authentication information for verifying the security processor when the authorized security verification is passed.

[0046] In this embodiment, after confirming the legality of the update command, the baseboard management controller needs to obtain authenticity information that can prove the identity of the security processor hardware. To this end, the baseboard management controller and the security processor perform a security interaction to generate or obtain a set of dynamic authentication data related to hardware uniqueness, establishing the necessary hardware identity credentials for subsequent verification.

[0047] In this embodiment, the baseboard management controller is used to provide hardware authentication information to the root firmware, triggering the root firmware to request the security processor to perform security verification on the hardware authentication information.

[0048] In this embodiment, the baseboard management controller transmits the obtained hardware authentication information to the root firmware running on the security processor. Using the root firmware as an intermediary, it initiates a verification request for its own hardware identity information to the security processor, entrusting the verification of hardware identity to the security processor itself or its internal trusted components, thereby completing a closed-loop confirmation of hardware authenticity.

[0049] In this embodiment, the baseboard management controller uses its pre-set root certificate public key to verify the authorized source of the update command, ensuring the legitimacy of the update command. Based on this, it further obtains hardware dynamic authentication information from the security processor and provides this hardware identity information to the trusted root firmware, thereby triggering the firmware to drive the security processor to complete hardware-level cryptographic verification. This achieves the division of responsibilities and cross-recognition among the baseboard management controller, firmware, and hardware, establishing a secure foundation of trusted firmware source and unique hardware identity, effectively preventing the risk of single-point breaches, and significantly improving the integrity and robustness of the three-party authentication.

[0050] In this embodiment, the baseboard management controller is further configured to decrypt the digital signature in the digital signature certificate using a preset root certificate public key to obtain a signature declaration hash value; determine the target firmware hash value related to the target trusted root firmware in the digital signature certificate; and determine that the authorization security verification of the update instruction is passed if the signature declaration hash value is the same as the target firmware hash value.

[0051] In this embodiment, the digital signature in the certificate is decrypted using the root certificate public key to obtain the signature hash value declared by the issuer. Simultaneously, the firmware hash value corresponding to the target trusted root firmware is parsed from specific fields of the digital signature certificate. The decrypted signature hash value is compared with the parsed target firmware hash value; only when they are completely identical can the authorization security verification of this update command be confirmed as successful.

[0052] For example, the baseboard management controller invokes its cryptography library to perform asymmetric decryption on the received digital signature certificate using a pre-configured root certificate public key, extracting the embedded signature hash value. Simultaneously, following a predefined certificate format, it reads and parses the hash value of the target trusted root firmware from the extended fields or specific metadata area of ​​the digital signature certificate. The decrypted hash value is then compared byte-by-byte with the parsed target hash value. If the comparison results in a perfect match, a verification pass signal is generated; if any mismatch exists, the update process is immediately terminated and an authorization verification failure is reported.

[0053] In this embodiment, the baseboard management controller uses a pre-set root certificate public key to decrypt the signature in the digital signature certificate to obtain the signature declaration hash value; simultaneously, it extracts the target firmware hash value from the same certificate as a trusted benchmark. By comparing the consistency of these two hash values, the authorization security of the update command is determined, achieving dual and accurate verification of the authenticity and integrity of the firmware source. This effectively eliminates the risk of forged or tampered update commands being executed incorrectly, constructing the first verifiable cryptographic defense line for the entire update process.

[0054] In this embodiment, the baseboard management controller is further configured to generate an authentication challenge code and send the authentication challenge code to the security processor; receive a response value generated by the security processor processing the authentication challenge code based on a preset physical identifier function, and use the authentication challenge code and the response value as hardware authentication information.

[0055] In this embodiment, the baseboard management controller generates a random or pseudo-random authentication challenge code and sends it to the security processor via a secure communication interface. The security processor processes the challenge code using its internally integrated physically unclonable function module, generates a response value uniquely bound to the hardware's physical characteristics, and returns it. The generated challenge code and the received response value are combined to form hardware authentication information for subsequent verification.

[0056] For example, the substrate management controller calls a random number generator to generate a byte sequence of a specified length as a challenge code, and then encrypts it via SPI or I²C bus before sending it to the security processor. Upon receiving the challenge code, the security processor's PUF circuitry utilizes its internal non-replicable physical characteristics, such as subtle differences in the silicon wafer, to execute a specific transformation function to generate a unique response value, which is then returned via the same communication path. Upon receiving the response value, it associates the response value with the locally stored original challenge code in memory, forming a "challenge code-response value" pair.

[0057] In this embodiment, after the authorization security verification is passed, the baseboard management controller generates an authentication challenge code and sends it to the security processor. The security processor processes the challenge code using its preset physical identification function, generates a unique response value, and returns it. The authentication challenge code and the received response value are used together as hardware authentication information. Leveraging the uniqueness and unpredictability of physically non-cloning functions, the abstract hardware authentication is transformed into a one-time challenge-response cryptographic interaction, effectively verifying the physical identity of the security processor and ensuring that the hardware foundation for subsequent third-party authentication is unforgeable.

[0058] In this embodiment, the baseboard management controller is further configured to send hardware authentication information to the root trust firmware, which submits the hardware authentication information to the hardware security engine of the security processor, whereby the hardware security engine performs cryptographic verification based on a pre-set hardware certificate; receive the verification result returned by the root trust firmware after performing security verification on the hardware authentication information; and determine that the security processor's security verification is complete based on the verification result.

[0059] In this embodiment, the baseboard management controller transmits its hardware authentication information to the root firmware running on the security processor via a secure interface. The root firmware, acting as a trusted proxy, submits this authentication information to the hardware security engine integrated within the security processor. This hardware security engine uses its pre-installed certificate, uniquely bound to the hardware, to perform cryptographic verification on the received authentication information. After verification, the engine obtains and confirms the verification result from the security processor, thereby completing the security verification of the hardware identity.

[0060] For example, the baseboard management controller sends hardware authentication information, including a challenge code and response value, to the root firmware via shared memory or a secure messaging mechanism. The root firmware then sends the authentication information to the hardware security engine's verification interface by invoking security service instructions provided by the security processor. The hardware security engine extracts the pre-set hardware certificate and performs cryptographic operations such as signature verification or key matching based on the challenge code and response value. After verification, the hardware security engine writes a success or failure status code to a designated status register. The baseboard management controller reads the status code via polling or interrupts, using this as evidence of completed hardware security verification, thus ensuring the unforgeability of the verification result at the physical level.

[0061] In this embodiment, the baseboard management controller transmits the acquired hardware authentication information to the root trust firmware. This firmware, acting as the initiator, submits the information to the hardware security engine within the security processor. The hardware security engine performs independent cryptographic verification of this information based on its pre-installed hardware certificate and returns the verification result, achieving hard isolation of the verification process. This not only eliminates the possibility of external forgery of verification results but also, through the bridging role of the root trust firmware, precisely connects external authentication with the chip's internal security capabilities.

[0062] In this embodiment, the baseboard management controller is used to determine the download address of the target trusted root firmware corresponding to the target firmware version information from the updated digital certificate based on the target firmware version information. The download address includes a data management platform or a local image repository. According to the download address, the target trusted root firmware image corresponding to the target firmware version information is downloaded.

[0063] In this embodiment, the baseboard management controller parses the update digital certificate carried in the update instruction and determines the firmware download address corresponding to the target firmware version information based on the version mapping relationship recorded in the update digital certificate. The firmware download address can point to an external trusted data management platform or a locally certified image repository. Based on the parsed download address, the baseboard management controller establishes a secure connection and downloads the complete target trusted root firmware image to the local cache area for subsequent comparison and update.

[0064] For example, the baseboard management controller parses the received digital credentials in different formats. By querying specific fields corresponding to the target version, it extracts the Hypertext Transfer Security Protocol link or local file path recorded in the download address field as the download address. If the download address is a remote network address, it accesses the application programming interface of the data management platform through a transport layer secure encrypted channel, initiates a download request, and receives the data stream of the target trusted root firmware image.

[0065] If the download address is a local address, the target root firmware image is read from the specified directory of the embedded multimedia card or non-volatile high-speed memory. During the download or reading process, the controller calculates the hash value of the received data in real time. After the target root firmware image is fully acquired, the calculated hash value is compared with the hash value pre-stored in the digital certificate to ensure the integrity and consistency of the source of the acquired target root firmware image.

[0066] In this embodiment, the baseboard management controller parses the update digital certificate attached to the update instruction, locates the download address (pointing to the data management platform or local image repository) that matches the target firmware version information, and downloads the target firmware image according to the address. Through the credential-based address addressing mechanism, the firmware source channel is standardized and trusted, ensuring the integrity, source controllability, and update deployment flexibility of the target firmware.

[0067] In this embodiment, the baseboard management controller is used to determine, based on pre-stored index information, a target storage area for storing the backup image firmware corresponding to the trust root firmware to be updated from the backup storage area; and to read the backup image firmware corresponding to the trust root firmware to be updated from the target storage area.

[0068] In this embodiment, the baseboard management controller obtains a firmware backup index maintained internally by the baseboard management controller. This index records the specific physical or logical locations of different versions of the root trust firmware in the backup storage area. Based on the identifier of the root trust firmware to be updated, the baseboard management controller queries the firmware backup index and locates the target area storing its corresponding backup image. The baseboard management controller reads the complete backup image firmware data from the target area into its working memory, providing an accurate benchmark data source for subsequent difference comparisons.

[0069] For example, the baseboard management controller accesses an index table stored in the controller's non-volatile memory. This table maps the firmware version number to the corresponding starting logical block address and image size. The baseboard management controller queries this table to obtain the starting logical block for the current firmware version backup. Data blocks of a specified length are read sequentially from the calculated physical address via the embedded multimedia card (EMMC) or the Serial Peripheral Interface Flash Controller Interface (SPIFlash). During the reading process, a cyclic redundancy check (CRC) value is calculated for the read data and compared with the checksum stored in the index. This verifies the integrity of the backup image during the reading phase, ensuring the accuracy of the source data upon which subsequent difference calculations are based.

[0070] In this embodiment, the baseboard management controller locates the target storage area containing the backup image of the trusted root firmware to be updated in the backup storage area based on its internally stored index information, and accurately reads the backup image firmware from it. Through indexed management, it achieves fast and accurate location and access to backup data, avoids the efficiency loss caused by full disk traversal, and ensures the integrity and reliability of the source data (backup image) used for difference comparison, laying a key foundation for the subsequent generation of accurate incremental update packages.

[0071] In this embodiment, the baseboard management controller is used to obtain the metadata of the backup image firmware to be updated and the target version metadata of the target trusted root firmware.

[0072] In this embodiment, the baseboard management controller first needs to extract metadata information identifying the firmware version in order to initiate the difference calculation. The version metadata is parsed and obtained from both the locally backed-up image firmware and the target firmware image to be updated. The obtained version metadata, which includes key identifying information such as version number and compilation time, is the fundamental basis for determining whether two firmware versions need to be compared at the content level, and is also a prerequisite for triggering subsequent difference calculations.

[0073] In this embodiment, the baseboard management controller is used to compare the metadata of the version to be updated with the metadata of the target version. If there is a difference between the metadata of the version to be updated and the metadata of the target version, the controller performs difference calculation on a specified data area of ​​the backup image firmware and the target trusted root firmware to generate the original difference content.

[0074] In this embodiment, by comparing the two sets of version metadata obtained, it can be determined whether there are differences between the current backup version and the target version. If a version difference is confirmed, it indicates that a content update is required. Instead of performing a full comparison of the two complete firmware images, a difference calculation is performed only on specific, potentially changeable data areas within the two images according to a predefined strategy.

[0075] In this embodiment, the baseboard management controller is used to encrypt and encapsulate the original difference content to generate a difference update package.

[0076] In this embodiment of the application, to ensure the security and reliability of the generated difference data during subsequent transmission and processing, the calculated original difference content needs to be securely hardened and structurally encapsulated. The original difference content is encrypted using an encryption algorithm, and necessary metadata, such as version information and data integrity verification values, is added. This is then encapsulated into a complete data packet conforming to a predetermined format, i.e., a difference update packet.

[0077] In this embodiment, the baseboard management controller compares the version metadata of the backup image and the target firmware. After confirming the existence of version differences, it performs difference calculations only on a pre-defined specified data area between the two, generating the original difference content. The original difference content is then encrypted and encapsulated to form the final difference update package. This process, through a two-step strategy of metadata comparison and filtering and specified area difference calculation, effectively avoids the computational overhead of full image comparison, achieving accuracy and minimization of the update package.

[0078] In this embodiment of the application, the baseboard management controller is further configured to determine that there is a difference between the version metadata to be updated and the target version metadata when the version number to be updated in the version metadata to be updated is different from the target version number.

[0079] In this embodiment, the baseboard management controller reads the metadata of the version to be updated of the backup image firmware from the local cache, and reads the target version metadata of the target trusted root firmware from its non-volatile storage partition. The baseboard management controller extracts and compares the core identification fields of the metadata of the version to be updated and the target metadata. The core identification fields include, but are not limited to, the version number to be updated and the target version number.

[0080] For example, the version number to be updated is V1.18, and the target version number is V1.19. If the version number to be updated and the target version number are the same, it is determined that no update is needed, the process terminates, and feedback is sent to the management platform that the current version is already the latest version; if the two are different, it is determined that there is a difference between the metadata of the version to be updated and the metadata of the target version, and the subsequent difference calculation steps are allowed to be executed.

[0081] In this embodiment, the baseboard management controller directly determines whether there is a difference in version metadata by comparing whether the version number to be updated of the backup image is the same as the target version number of the target trusted root firmware. This efficient version change determination criterion is a prerequisite for triggering subsequent fine-grained difference calculations, thus avoiding unnecessary waste of computing resources.

[0082] In this embodiment of the application, before performing difference calculation on the specified data area of ​​the backup image firmware and the target trusted root firmware to generate the original difference content, the backup image firmware and the target trusted root firmware image are divided into data areas according to the preset firmware partition structure to obtain multiple candidate data areas; at least one candidate data area with data changes is selected from the multiple candidate data areas as the specified data area.

[0083] In this embodiment, the baseboard management controller logically divides the backup image firmware and the target trusted root component image according to a preset firmware partitioning structure, resolving them into multiple candidate data regions. Based on identification strategies, such as metadata analysis, version change records, or fast hash comparison, it identifies and selects one or more regions from the multiple candidate data regions that have actually undergone data content changes, clearly defining these regions as the targets for subsequent precise difference calculations, i.e., designated data regions.

[0084] For example, the baseboard management controller divides the backup image firmware and the target root trust firmware image into data regions according to a preset firmware partitioning structure. Using an industry-standard partitioning model, taking a structure including a boot sector, code sector, configuration sector, and verification sector as an example, each image is split into multiple corresponding candidate data regions. By analyzing the characteristics of each region—for example, the code sector and configuration sector are often the core areas of version differences—the baseboard management controller can strategically select one or more of the multiple candidate data regions. For instance, it can select only the code sector and configuration sector as designated data regions for subsequent difference calculations, thereby filtering out data regions such as the boot sector and verification sector that are usually unchanged or only require format updates.

[0085] In this embodiment, the baseboard management controller partitions two firmware images according to a preset firmware partitioning structure, and selects the areas where data changes actually occur as designated areas for difference calculation. This achieves accurate positioning of the difference calculation object, avoids invalid comparisons of areas without changes, and thus greatly improves the efficiency of difference calculation and the accuracy of generating incremental packets.

[0086] In this embodiment, the baseboard management controller is further configured to use data from a specified data area in the backup image firmware as source data and data from a specified data area in the target trusted root firmware image as target data; identify continuous byte blocks in the target data that are consistent with the content of the source data and record the position information of the continuous byte blocks in the source data; extract byte blocks in the target data that are inconsistent with the content of the source data as new data; and combine and encapsulate the recorded position information with the new data to generate the original difference content.

[0087] In this embodiment, the baseboard management controller uses data from a specified data region in the backup image firmware as source data and data from the corresponding specified data region in the target trust root firmware image as target data. By scanning and analyzing the target data, it identifies continuous byte sequences (i.e., duplicate data blocks) that are completely identical to the source data content, and records the start position and length information of these byte blocks in the source data. Byte sequences in the target data that are inconsistent with the source data are extracted as new data. Finally, the recorded position information describing the duplicate data blocks and the extracted new data are combined and structured to generate the original difference content representing the changes required from the source data to the target data.

[0088] For example, the baseboard management controller invokes a differential algorithm, such as a binary differential algorithm, using data from a specified data region in the backup image firmware as source data and data from the corresponding specified data region in the target trusted root firmware image as target data. The differential algorithm indexes the source data to quickly locate recurring patterns. It scans the target data and identifies consecutive byte blocks that match the source data content, recording the position information of these consecutive byte blocks in the source data, such as offset and length. For byte blocks that do not match in the target data, they are directly extracted as new data. All recorded position information and the extracted new data are combined and encapsulated in a specific format, outputting the original differential content.

[0089] In this embodiment, the baseboard management controller identifies and records the location information of the part of the target data that is consistent with the source data, while extracting the inconsistent part as new data, and finally combines and encapsulates it into the original difference content. By using a hybrid encoding strategy of recording the same and extracting the difference, the controller achieves the minimum encoding and efficient storage of incremental data while ensuring data integrity.

[0090] In this embodiment, the baseboard management controller is further configured to acquire difference description information corresponding to the original difference content. The difference description information is used for the security processor to parse and locate the data area to be updated. The difference description information and the original difference content are encrypted as a whole, and the encrypted data is encapsulated according to a preset incremental update package format to generate a difference update package.

[0091] In this embodiment, the baseboard management controller generates or acquires difference description information that corresponds to the original difference content. After transmitting the difference description information to the security processor, the security processor correctly parses, locates, and applies this difference description information after unpacking. The difference description information and the original difference content are treated as a logical whole, and an encryption operation is performed to protect the confidentiality and integrity of the logical whole. The encrypted data stream is formatted and encapsulated according to a predefined incremental update packet structure, and the output is a complete difference update packet that can be directly used for transmission.

[0092] For example, the baseboard management controller acquires difference description information, which includes at least the source version, target version, the involved difference partition number, the total size of the original difference content, and its cryptographic hash value. The baseboard management controller uses a dynamically generated one-time session key to encrypt both the difference description information and the original difference content. The encrypted data blocks are then assembled according to a preset incremental update packet format, such as a header containing a format identifier and length, followed by the encrypted data body, to generate a difference update packet that can be transmitted in subsequent steps. After the difference update packet is sent to the security processor, the security processor can decrypt it according to the format specification and use the difference description information to accurately locate and apply the original difference content.

[0093] In this embodiment, the baseboard management controller merges the difference description information used for parsing and positioning with the original difference content, encrypts the whole, and then encapsulates it into the final difference update package according to a preset format. This not only ensures the security of the update data through encryption, but also ensures that the receiver can correctly parse and locate the update through structured encapsulation (including description information).

[0094] In this embodiment, the baseboard management controller is used to determine the total number of fragments based on the total data length of the differential update package and the data length of the fixed fragment; to split the differential update package into multiple data fragments according to the data length of the fixed fragment and the total number of fragments; to assign a fragment identifier to each data fragment and to perform encrypted encapsulation to generate multiple encrypted data blocks.

[0095] In this embodiment, the baseboard management controller calculates the required total number of data fragments based on a preset fixed fragment length and the total data length of the differential update package to be split. According to the total number of fragments and the fixed fragment length, the complete differential update package data stream is sequentially and uniformly divided into multiple data fragments. Each generated data fragment is assigned a unique fragment identifier, and each data fragment undergoes independent encryption and encapsulation operations, thereby generating multiple ordered encrypted data blocks.

[0096] For example, the baseboard management controller can set a fixed data fragment length, such as 128KB, to suit a specific transmission channel. First, the total number of fragments is calculated as the total size of the difference update packet divided by the fixed fragment length. Then, based on this total number of fragments and the fixed fragment length, the data is sequentially divided from the start position of the difference update packet, resulting in N data fragments. The size of the last data fragment can be smaller than the fixed length. Each data fragment is sequentially assigned a unique fragment identifier, such as a number from 1 to N. Each data fragment with a fragment identifier is encrypted using an independent key and initialization vector, and a header containing the fragment identifier, size, and integrity check value is appended. This completes the encrypted encapsulation, generating multiple independent encrypted data blocks, which are arranged in order of their fragment identifiers and await transmission.

[0097] For example, the baseboard management controller uses a 256-bit key advanced cryptographic standard counter mode algorithm to encrypt the data in each data fragment and generates an independent initialization vector for each fragment. This initialization vector is composed of a fragment identifier and a random number to prevent duplication of encryption modes under the same key. The integrity hash value of the encrypted data block is calculated: a 256-bit secure hash algorithm is performed on the combination of the fragment identifier, the encrypted fragment data, and the initialization vector to obtain a 32-byte hash value. A 16-byte fragment header is created, including the fragment identifier (4 bytes), the fragment size (i.e., the original data length of the fragment, 4 bytes), and the first 8 bytes of the 32-byte hash value calculated in the previous step. The fragment header (16 bytes) and the encrypted fragment data (not exceeding 128KB) are concatenated sequentially to form an encrypted data block. All generated encrypted data blocks are stored in the baseboard management controller's transmission queue in ascending order of their fragment identifiers, awaiting transmission.

[0098] In this embodiment, the baseboard management controller calculates the total number of fragments based on the fixed fragment length and the total length of the update package, and then evenly divides the entire differential update package into multiple data fragments. Finally, a unique identifier is assigned to each fragment and encrypted encapsulation is performed to generate an independent encrypted data block. This effectively adapts to the carrying capacity of the transmission channel and provides a precise structured foundation for subsequent implementation of reliable streaming transmission, block-by-block verification, and breakpoint resume mechanisms.

[0099] In this embodiment, the difference update package includes a metadata portion and a difference data portion arranged in sequence. The baseboard management controller is further configured to, when the data length of the metadata portion is not greater than the data length of the fixed fragment, split the starting data fragment from the start byte of the difference update package, the data length of the starting data fragment being equal to the data length of the metadata portion, and split the remaining data from the end byte of the starting data fragment according to the data length of the fixed fragment; when the data length of the metadata portion is greater than the data length of the fixed fragment, split the data from the start byte of the difference update package according to the data length of the fixed fragment.

[0100] In this embodiment, when the difference update package has an internal structure consisting of sequentially arranged metadata and difference data parts, the baseboard management controller's splitting process prioritizes the integrity of the metadata part. Specifically, if the data length of the metadata part is not greater than the data length of a fixed fragment, a starting data fragment of the same length as the metadata part is split from the starting byte of the difference update package to ensure that the first fragment can completely carry the metadata. Subsequently, starting from the ending byte of this starting data fragment, the subsequent difference data parts are split according to the fixed fragment data length. If the data length of the metadata part is greater than the data length of the fixed fragment, it is no longer guaranteed to be encapsulated in a single fragment, but rather the entire difference update package (including metadata and difference data) is split uniformly according to the fixed fragment data length, starting directly from the starting byte.

[0101] For example, if the metadata portion is no longer than 128KB, the first data fragment is the starting data fragment, and its length is equal to the length of the metadata portion. Any portion less than 128KB can be padded with padding bytes. This data fragment contains the complete metadata portion. If the metadata portion is longer than 128KB, the starting data fragment and any subsequent consecutive fragments will only contain the first 128KB or smaller units of metadata until all metadata has been split and a metadata identifier is marked in the header.

[0102] After the initial data sharding or when the metadata sharding is complete, the controller continues to split the subsequent difference data portion according to a fixed shard length of 128KB, forming multiple data shards. When the last data shard contains the remaining difference data, and its difference data length is less than or equal to 128KB, it is marked as the last shard identifier. Throughout the marking process, each generated data shard is assigned a unique, sequentially increasing shard number, such as 0001 to NNNN, according to its splitting order in the difference update package, to ensure its ordering.

[0103] In this embodiment, the baseboard management controller implements different fragmentation strategies for the difference update package, which is composed of metadata and difference data in sequence, based on the relationship between the metadata length and the fixed fragment length. If the metadata is not longer than the fixed fragment length, the first fragment accurately contains all the metadata, and the remaining part is then split according to the fixed length. Otherwise, all data is evenly split according to the fixed length. By prioritizing the integrity encapsulation of the key metadata of the update package, it ensures that the receiver can parse the global information of the update task first and accurately.

[0104] In this embodiment, the baseboard management controller and the security processor are connected via a communication interface. The baseboard management controller is used to sequentially transmit multiple encrypted data blocks to the security processor. Transmitting any encrypted data block includes: receiving an acknowledgment signal returned by the security processor after verifying the previous encrypted data block; if the received acknowledgment signal indicates that the integrity verification is successful, determining that the previous encrypted data block was successfully transmitted, and transmitting any encrypted data block to the security processor; if the received acknowledgment signal indicates that the integrity verification failed, retransmitting the previous encrypted data block according to a preset retransmission strategy.

[0105] In this embodiment, the baseboard management controller transmits multiple encrypted data blocks sequentially to the security processor. Each time an encrypted data block is transmitted, the security processor performs an independent integrity check on the newly received data block. The baseboard management controller synchronously receives confirmation signals returned by the security processor after verifying each encrypted data block. If the received confirmation signal indicates successful verification, the current encrypted data block is confirmed to have been successfully transmitted, and the next encrypted data block is automatically sent to the security processor according to the predetermined transmission order. If the confirmation signal indicates verification failure, the encrypted data block that failed verification is retransmitted according to a preset retransmission strategy.

[0106] For example, the board management controller sends encrypted data blocks to the security processor sequentially via a communication interface such as USB, according to their transmission order, such as the fragment numbering order 0001→0002→…→NNNN. After transmitting each encrypted data block, the controller pauses and waits for an acknowledgment signal from the security processor before deciding whether to send the next encrypted data block or perform a retransmission. Simultaneously, it can periodically synchronize the transmission progress to the data management platform, such as reporting "12 / 58 fragments transmitted, progress 20.7%" after approximately 10% of the encrypted data blocks have been transmitted.

[0107] It should be noted that if a failure confirmation signal is received, the current encrypted data block will be retransmitted according to the retransmission policy (e.g., setting the maximum number of retransmissions to 3). If the retransmission still fails after exceeding the limit, it may trigger an abnormal interruption of the transmission process.

[0108] In this embodiment, the baseboard management controller transmits encrypted data blocks sequentially. Each time a block is transmitted, the security processor is triggered to perform integrity verification and wait for confirmation. If the verification is successful, the next block is transmitted. If it fails, the block is retransmitted according to a preset strategy. This achieves real-time reliability and integrity assurance of the updated data stream at the transmission layer, ensuring that each data block is verified before being written, effectively preventing errors or data tampering.

[0109] In this embodiment, after the update is interrupted due to timeout, verification failure or communication error, the baseboard management controller and the security processor collaboratively locate the successfully received and missing data fragments based on the transmission state before the interruption, and resume the subsequent transmission process from the interruption point.

[0110] For example, after an interruption occurs, the baseboard management controller receives a list of successfully received fragments compiled by the security processor. This list includes fragment numbers and their corresponding hash values. The baseboard management controller compares the received list with its local complete fragment index table. This verifies the hash consistency of the received fragments to confirm their validity, and also calculates a list of missing or abnormal fragments by traversing the list in fragment number order. The baseboard management controller sends a resume request to the security processor along with the list of missing fragments. After the security processor confirms the request, it retransmits the abnormal fragments in the order listed, prioritizing them, and then resumes transmission of the unsent fragments to restore transmission.

[0111] It should be noted that each fragment in the resumed transmission still needs to go through the same integrity verification process as the first transmission. After all missing fragments have passed the reception verification, the security processor will report that the reception is complete and the resume transmission process ends.

[0112] In this embodiment, the breakpoint resume mechanism relies on globally unique and ordered fragment numbers rather than transmission-dependent hash values ​​for state synchronization and sorting, ensuring the accuracy and reliability of recovery positioning. This minimizes the impact of non-fatal interruptions caused by temporary hardware fluctuations or network outages, achieving resilience in the update task. It avoids the significant waste of time and bandwidth resources caused by the forced restart of the entire large update task due to partial, transient transmission failures, significantly improving the robustness and efficiency of the firmware update system in unstable environments.

[0113] In this embodiment, the baseboard management controller periodically reads the hardware status data of the security processor through the communication interface while splitting the differential update packet into multiple encrypted data blocks and transmitting them through the communication interface; if the hardware status data exceeds a preset security threshold, it triggers a transmission interruption and notifies the trusted root firmware to suspend the transmission operation; thus shortening the reading cycle of the hardware status data.

[0114] In this embodiment, while transmitting encrypted data blocks, the baseboard management controller actively reads various hardware status data of the security processor, such as chip temperature, operating voltage, and physical tamper detection signals, through the communication interface at a fixed initial period. When any of the read hardware status data exceeds a preset security operating threshold, a forced interruption of the entire firmware update transmission process is immediately triggered, and a notification is simultaneously sent to the trusted root firmware running on the security processor, causing it to suspend any update-related internal processing operations. To ensure more sensitive monitoring of recovery during abnormal states, after triggering the interruption, the baseboard management controller automatically shortens the hardware status data reading cycle and enters a high-frequency monitoring mode.

[0115] For example, during the transmission of encrypted data blocks via a communication interface such as a USB channel, the baseboard management controller periodically (e.g., every 100ms) reads the status register of the security processor through the same communication interface as a foreground or background task to obtain its real-time hardware status data, including core temperature, power supply voltage, and the level status of physical anti-tampering pins. When any indicator, such as voltage fluctuation exceeding ±5%, is detected, exceeding the preset safety threshold, the controller immediately performs the following actions: 1) Triggers a transmission interrupt, stopping the transmission of subsequent encrypted data blocks; 2) Notifies the trusted root firmware through a secure message channel, requesting it to suspend current update-related internal operations, such as suspending the processing of received data or locking the storage interface; 3) Significantly shortens the hardware status data reading cycle, such as adjusting it from 100ms to 50ms, to track the recovery of the hardware status more frequently.

[0116] It should be noted that this mechanism strongly binds the critical software operation of firmware updates to the actual operational health of the underlying hardware. Its purpose is to prevent firmware writing operations that could undermine the foundation of trust from continuing when the security processor itself is unstable, unreliable, or potentially under physical attack such as abnormal voltage, high temperature, or tampering attempts. This adds a real-time hardware security barrier to the update process, effectively avoiding the risk of update failure or even damage to the security chip due to hardware anomalies.

[0117] In this embodiment, the security processor hardware status data is periodically read during transmission. Once the baseboard management controller detects an anomaly exceeding the security threshold, it immediately interrupts the transmission and notifies the trusted root firmware to suspend operation. At the same time, the monitoring frequency is increased, and the hardware health status is dynamically bound to the update process. This enables real-time perception and rapid response to potential hardware failures or attacks, effectively preventing critical update operations from being performed in unstable or attacked hardware environments, thereby ensuring the security and reliability of the update process.

[0118] In this embodiment, the baseboard management controller is further configured to generate a recovery command and send it to the root trust firmware to trigger the root trust firmware to release the paused transmission operation when the hardware status data is detected to be at a preset security threshold for a preset duration; receive a recovery response from the root trust firmware, and continue the transmission process of the encrypted data block from the point of transmission interruption based on the recovery response.

[0119] In this embodiment, the baseboard management controller continuously monitors hardware status data after an interruption. When all monitored data returns to within a preset safety threshold range, and this stable state persists for a preset duration, a recovery command is generated and sent to the root firmware to trigger the root firmware to release the internal pause and lock operations implemented due to the anomaly. Only after receiving confirmation from the root firmware regarding this recovery command is the recovery condition deemed fully ready, and the subsequent encrypted data block transmission process continues based on the transmission progress points recorded before the interruption.

[0120] For example, after a transmission interruption is triggered due to hardware status data exceeding a preset security threshold, the baseboard management controller enters a high-frequency monitoring mode, such as shortening the reading cycle to 50ms. It continuously checks the hardware status data of the security processor, such as voltage and temperature. When all monitored indicators remain stable within the preset security threshold range for a continuous period, such as 1 second, the baseboard management controller generates an encrypted recovery command and sends it to the root firmware via a secure channel. Upon receiving the recovery command, the root firmware independently verifies the current hardware status. If it confirms that everything is correct, it releases its internal pause and lock states in stages and returns a recovery response to the baseboard management controller. Upon receiving the recovery response, the hardware monitoring cycle is immediately restored to the normal frequency, and the transmission process of subsequent encrypted data blocks continues from the previously recorded transmission interruption point. If the hardware status data fails to stabilize within a longer period, such as 10 seconds, the baseboard management controller reports to the data management platform and waits for manual intervention.

[0121] In this embodiment, when the hardware status returns to normal and remains stable, the baseboard management controller sends a recovery command to the trusted root firmware and continues transmission from the previous interruption point after receiving its confirmation response. This realizes controllable pause and automatic resumption of the update process, ensuring that the update task can be seamlessly and safely resumed after the temporary hardware anomaly is resolved.

[0122] In this embodiment, the trust root firmware update method applied to the baseboard management controller also includes a cluster collaboration and health-aware scheduling strategy. This strategy involves, based on the single-device update process, the baseboard management controller and the data center management platform collaborating to determine whether a server is suitable for inclusion in the current update batch based on the server's hardware health status and processor load level; and during the execution of the update task, real-time synchronization of its hardware status changes to support dynamic adjustment and intelligent management of cluster-level updates.

[0123] For example, before or during an update command response, the baseboard management controller acquires and reports the processor load status of its server (e.g., CPU utilization below 50%) and critical hardware health status (e.g., temperature and voltage of the security processor). Based on these two types of status information reported by each node, the data management platform filters out servers with low processor load and normal hardware status, marks them as updateable nodes, and formulates a plan to push update tasks in batches, such as groups of 50. During the push of update tasks to a node group, if a baseboard management controller detects an abnormal hardware status of its local security processor (e.g., voltage exceeding a threshold), it immediately triggers a local update transmission interruption and reports an event containing the node identifier and hardware anomaly type to the data management platform. Upon receiving the event containing the node identifier and hardware anomaly type, the data management platform can dynamically remove the node marked as abnormal from the current update batch at the cluster level, mark it as abnormal and pending processing, and continue updating the remaining nodes in the batch. Simultaneously, the real-time update progress information integrates hardware status codes containing specific states such as "normal" and "hardware anomaly - paused," making the cluster-level update status visible.

[0124] In this embodiment, the cluster scheduling strategy achieves deep integration and linkage between firmware update tasks and the underlying hardware health status of the server platform. By performing dual filtering based on health and load before scheduling decisions, it ensures that updates are executed only on stable, low-load nodes, reducing the risk of update failures due to resource contention or hardware instability from the outset. By establishing a closed-loop feedback mechanism of "real-time reporting of node anomalies and dynamic adjustment of cluster tasks" during update execution, hardware anomalies on individual nodes are localized, preventing their spread and impact on the progress and success rate of the entire update batch. This significantly improves the overall success rate, efficiency, and operational intelligence level of firmware updates for large-scale server clusters.

[0125] In this embodiment, the security processor is configured to sequentially receive multiple encrypted data blocks sent by the baseboard management controller, verify the multiple encrypted data blocks, and return a confirmation signal corresponding to the multiple encrypted data blocks. Verifying any encrypted data block and returning a confirmation signal corresponding to any encrypted data block includes: calculating the verification value of any received encrypted data block according to a preset verification algorithm; determining the confirmation signal based on the comparison result between the calculated verification value and the preset hash value of any encrypted data block; returning an acknowledgment signal corresponding to any encrypted data block to the baseboard management controller; and writing the verified encrypted data block to the main storage area of ​​the security processor in response to receiving a write command from the baseboard management controller.

[0126] In this embodiment, the received data block content is processed according to a preset cryptographic verification algorithm to generate a real-time verification value. The calculation result is then compared bit by bit with the base hash value pre-stored in the encrypted data block header or associated metadata. Depending on whether the comparison result is completely identical or shows a difference, the internal state machine of the security processor generates a clear confirmation signal uniquely bound to the current data block. The confirmation signal is fed back to the baseboard management controller in real time, forming the direct basis for the controller to determine whether the current block transmission was successful and to decide on subsequent actions. After all data blocks have completed the verification process and the controller issues a write command, the security processor integrates all the verified data blocks and writes them to its protected main storage area, thereby ensuring data integrity while achieving reliable and orderly firmware updates.

[0127] For example, upon receiving an encrypted data block, the security processor immediately initiates an integrity check on the encrypted data block. The check process may include: parsing the data block header to obtain metadata such as fragment number, size, and partial hash value; calculating the complete hash value of the received data using a pre-agreed algorithm; and comparing it step-by-step with the check information carried in the header: first, quickly comparing the hash leading byte; if they match, then requesting and comparing the complete hash. Only after the check passes completely will the security processor return a confirmation signal indicating success; otherwise, it returns a confirmation signal indicating failure.

[0128] In this embodiment, the abstract data integrity verification is transformed into a concrete, quantifiable and feedback-enabled hardware operation through a standardized single-block verification and confirmation signal generation mechanism. This ensures the independent and reliable state of each data block during transmission, providing flow control basis for the baseboard management controller, thereby achieving high reliability and real-time controllability of the update process at the data level.

[0129] Figure 2 The diagram illustrates the hardware architecture of a trusted root firmware update system according to an embodiment of this application.

[0130] In the embodiments of this application, such as Figure 2 As shown, this architecture illustrates the physical platform composition for executing the update method of this application. OpenBMC (Open Source Baseboard Management Controller), as an open-source implementation of the baseboard management controller, runs on an independent coprocessor such as CM4 and is a concrete implementation instance of the baseboard management controller. It is responsible for executing core control logic such as update command response, third-party authentication initiation, difference packet generation, and fragment transmission. Caliptra (Secure Processor compliant with Open Compute Project specifications), as a secure processor compliant with Open Compute Project specifications, is the physical entity of the security processor serving as the root of trust hardware. Internally, it integrates a RISC-V (an open instruction set architecture) core, a hardware root of trust module, and a secure storage area. OpenPROT (Open Source Platform Root of Trust Firmware), running on Caliptra, is an open-source implementation of the root of trust firmware. It is responsible for collaborating with the baseboard management controller to complete authentication and managing the verification and write operations within the security processor during the update process. The root of trust update arrows in the diagram indicate the firmware update data flow and trust establishment direction driven by the method of this application. This architecture diagram intuitively illustrates the three-party collaborative update system composed of the baseboard management controller, the security processor, and its root of trust firmware.

[0131] Figure 3 The diagram illustrates the architecture of the firmware storage and update path according to an embodiment of this application.

[0132] In the embodiments of this application, such as Figure 3 As shown, this architecture diagram details the firmware storage and update data path. The BMC (Baseboard Management Controller) is connected to the management platform to receive update commands. The BMC contains an EMMC (Embedded Multimedia Card) memory, which corresponds to the backup storage area. This backup storage area securely stores a backup image of the root firmware to be updated. The MCU (Microcontroller Unit) module represents a security processor, such as Caliptra, acting as the root hardware. The Flash primary partition and Flash backup partition connected to the MCU module together constitute the main storage area of ​​the security processor. The Flash primary partition runs the currently active firmware, while the Flash backup partition provides redundancy during updates or rollbacks. This architecture diagram illustrates the complete update data flow and control chain from the data management platform to the BMC, and then to the security processor's storage area. It demonstrates the physical implementation basis of the series of steps: reading the backup image from the backup storage area, comparing it with the target firmware, generating a difference data packet, and triggering the writing of the difference data packet to the security processor's main storage area.

[0133] Figure 4 A flowchart illustrating a method for updating trusted root firmware according to an embodiment of this application is shown.

[0134] In the embodiments of this application, such as Figure 4 As shown, the method includes the following steps:

[0135] Step S410: In response to the update command carrying the target version information, perform third-party security authentication with the security processor and the trusted root firmware.

[0136] Step S420: If the third-party security authentication is successful, obtain the target trusted root firmware corresponding to the target version information, and read the backup image firmware corresponding to the trusted root firmware to be updated in the main storage area of ​​the security processor from the backup storage area.

[0137] Step S430: Compare the backup image firmware with the target trusted root firmware to generate a differential update package; split the differential update package into multiple encrypted data blocks.

[0138] In step S440, multiple encrypted data blocks are sent to the security processor, which is connected to the baseboard management controller, to trigger the security processor to write the multiple encrypted data blocks into the main storage area of ​​the security processor, so as to complete the update of the trust root firmware to be updated.

[0139] It should be noted that the embodiments of the update method section are similar to those of the update system section, and the technical effects achieved are also similar. For specific details, please refer to the embodiments of the update system section above, which will not be repeated here.

Claims

1. A system for updating trusted root firmware, characterized in that, include: The baseboard management controller is used to perform third-party security authentication with the security processor and the trusted root firmware in response to an update command carrying target version information; If the third-party security authentication is successful, obtain the target trusted root firmware corresponding to the target version information, and read the backup image firmware corresponding to the trusted root firmware to be updated in the main storage area of ​​the security processor from the backup storage area. The backup image firmware is compared with the target trusted root firmware to generate a difference update package; The difference update package is split into multiple encrypted data blocks; A security processor, which is communicatively connected to the baseboard management controller, runs a root trust firmware on the security processor. The security processor is used to receive the plurality of encrypted data blocks and write the plurality of encrypted data blocks into the main storage area of ​​the security processor to complete the update of the root trust firmware to be updated.

2. The system according to claim 1, characterized in that, The baseboard management controller is also used for: The authorization security of the update instruction is verified by comparing the pre-set root certificate public key with the digital signature certificate carried by the update instruction. If the authorized security verification passes, obtain the hardware authentication information used to verify the security processor; The hardware authentication information is provided to the root firmware, triggering the root firmware to request the security processor to perform security verification on the hardware authentication information.

3. The system according to claim 2, characterized in that, The substrate management control is also used for: The digital signature in the digital signature certificate is decrypted using the pre-set root certificate public key to obtain the signature declaration hash value; Determine the target firmware hash value associated with the target trusted root firmware in the digital signature certificate; If the hash value of the signature declaration is the same as the hash value of the target firmware, the authorization security verification of the update instruction is deemed to have passed.

4. The system according to claim 1, characterized in that, The baseboard management controller is also used to determine the download address of the target trusted root firmware corresponding to the target firmware version information from the updated digital credentials based on the target firmware version information. The download address includes a data management platform or a local mirror repository. Download the target trusted root firmware image corresponding to the target firmware version information according to the download address.

5. The system according to claim 1, characterized in that, The baseboard management controller is also used for: Obtain the metadata of the version to be updated of the backup image firmware and the target version metadata of the target trusted root firmware; The metadata of the version to be updated is compared with the metadata of the target version. If there is a difference between the metadata of the version to be updated and the metadata of the target version, the difference calculation is performed on the specified data area of ​​the backup image firmware and the target trusted root firmware to generate the original difference content. The original difference content is encrypted and encapsulated to generate the difference update package.

6. The system according to claim 5, characterized in that, The substrate management control is also used for: Based on the preset firmware partitioning structure, the backup image firmware and the target trusted root firmware image are divided into data regions to obtain multiple candidate data regions. At least one candidate data region whose data has changed is selected from the plurality of candidate data regions as the designated data region.

7. The system according to claim 5, characterized in that, The substrate management control is also used for: The data in the specified data area of ​​the backup image firmware is used as the source data, and the data in the specified data area of ​​the target trusted root firmware image is used as the target data. A continuous byte block in the target data that is consistent with the content of the source data is identified, and the position information of the continuous byte block in the source data is recorded. Extract the byte blocks in the target data that are inconsistent with the content of the source data, and use them as new data; The recorded location information is combined and encapsulated with the newly added data to generate the original difference content.

8. The system according to claim 5, characterized in that, The substrate management control is also used for: Obtain the difference description information corresponding to the original difference content. The difference description information is used for the security processor to parse in order to locate the data area to be updated. The difference description information and the original difference content are encrypted as a whole, and the encrypted data is encapsulated according to a preset incremental update package format to generate the difference update package.

9. The system according to claim 1, characterized in that, The baseboard management controller is also used for: The total number of fragments is determined based on the total data length of the difference update package and the data length of the fixed fragment; The difference update package is split into multiple data fragments according to the fixed fragment data length and the total number of fragments; Each data fragment is assigned a fragment identifier and encrypted and encapsulated to generate multiple encrypted data blocks.

10. The system according to claim 9, characterized in that, The substrate management control is also used for: If the data length of the metadata part is not greater than the data length of the fixed fragment, starting from the starting byte of the difference update package, a starting data fragment is split out. The data length of the starting data fragment is equal to the data length of the metadata part. Starting from the ending byte of the starting data fragment, the remaining data is split according to the data length of the fixed fragment. If the data length of the metadata section is greater than the data length of the fixed fragment, the data is split according to the data length of the fixed fragment, starting from the first byte of the difference update package.

11. The system according to claim 1, characterized in that, The baseboard management controller and the security processor are connected via a communication interface, and the baseboard management controller is further configured to: The plurality of encrypted data blocks are sequentially transmitted to the security processor, wherein transmitting any one of the encrypted data blocks includes: Upon receiving an acknowledgment signal returned by the security processor after verifying the previous encrypted data block; if the received acknowledgment signal indicates that the integrity verification was successful, it is determined that the previous encrypted data block was successfully transmitted, and the any encrypted data block is transmitted to the security processor. If the received confirmation signal indicates that the integrity verification has failed, the previous encrypted data block is retransmitted according to a preset retransmission strategy.

12. The system according to claim 11, characterized in that, The security processor is also used for: The system sequentially receives the plurality of encrypted data blocks sent by the baseboard management controller, verifies the plurality of encrypted data blocks, and returns a plurality of determination signals corresponding to the plurality of encrypted data blocks. Verifying any encrypted data block and returning a determination signal corresponding to that encrypted data block includes: Calculate the verification value of any received encrypted data block according to the preset verification algorithm; The determination signal is determined based on the comparison result between the calculated verification value and the preset hash value of any of the encrypted data blocks; Return an acknowledgment signal corresponding to any of the encrypted data blocks to the baseboard management controller; In response to receiving a write command from the baseboard management controller, the verified encrypted data block is written to the main storage area of ​​the security processor.

13. The system according to claim 1, characterized in that, The baseboard management controller is also used to periodically read the hardware status data of the security processor through a communication interface; If the hardware status data exceeds a preset security threshold, a transmission interruption is triggered and the trusted root firmware is notified to suspend the transmission operation. Shorten the reading cycle of the hardware status data.

14. A method for updating trusted root firmware, characterized in that, Applied to a baseboard management controller, the method includes: In response to an update command carrying target version information, a third-party security authentication is performed with the security processor and the root trust firmware. If the third-party security authentication is successful, the target root trust firmware corresponding to the target version information is obtained, and the backup image firmware corresponding to the root trust firmware to be updated in the main storage area of ​​the security processor is read from the backup storage area. The backup image firmware is compared with the target root trust firmware to generate a differential update package. The differential update package is split into multiple encrypted data blocks. Multiple encrypted data blocks are sent to the security processor, which is communicatively connected to the baseboard management controller, triggering the security processor to write the multiple encrypted data blocks into the main storage area of ​​the security processor to complete the update of the trust root firmware to be updated.

15. A baseboard management controller, characterized in that, include: One or more processors; Memory, used to store one or more computer programs. The one or more processors execute the one or more computer programs to implement the steps of the method according to claim 14.

Images