Service chain firmware incremental update verification method based on domestic trusted root

Abstract

The application relates to the technical field of firmware update verification, in particular to a service chain firmware incremental update verification method based on a domestic trusted root, which comprises the following steps: a management end generates an incremental package and a target firmware version certificate by adopting a binary difference algorithm, encapsulates an update task into a safe update instruction, signs the safe update instruction, and then issues the safe update instruction to a server baseboard management controller; an update agent verifies the signature by using a preset public key, initiates a session request to a trusted cryptographic module, the trusted cryptographic module creates a session context, selects an idle platform configuration register as an update process register and resets the update process register to zero; the update agent sequentially executes chain updating, and after the chain updating is completed, the trusted cryptographic module signs a final value of the register, generates an update completion voucher, and returns the update completion voucher to the management end. The method realizes precise control and closed-loop verification of an update process state, prevents tampering risks, and improves the safety and credibility of service chain firmware incremental update.

Description

Technical Field

[0001] This invention relates to the field of firmware update verification technology, and in particular to a service chain firmware incremental update verification method based on a domestically developed root of trust. Background Technology

[0002] In the field of service chain firmware update technology, conventional firmware incremental update verification methods involve the management end using a binary differential algorithm to generate an incremental packet, generating a version certificate for the target firmware version, encapsulating the update task into a secure update command, signing it, and then sending it to the server baseboard management controller. Its built-in update agent verifies the signature using a pre-set management end public key. Upon successful verification, the firmware update operation is executed, and the update result is sent back to the management end. This conventional technology is currently the mainstream implementation method for service chain firmware incremental updates and is widely used in various server firmware update scenarios.

[0003] Conventional technical solutions have shortcomings. During the update process, there is no dedicated state recording carrier, and the state throughout the update process cannot be effectively isolated and accurately recorded, making it susceptible to problems such as state confusion and tampering. After the update is completed, only the update result is transmitted back, lacking a closed-loop verification mechanism based on a root of trust. This makes it impossible to confirm the integrity and authenticity of the update result, and it is difficult to prevent security risks such as malicious tampering and unauthorized updates, failing to meet the high security requirements of service chain firmware updates. Therefore, a technical solution is needed to address the problems of insufficient state control during the update process and the lack of trusted closed-loop verification of update results, thereby improving the security and reliability of incremental updates to service chain firmware. Summary of the Invention

[0004] The purpose of this invention is to address the shortcomings of existing technologies by proposing a service chain firmware incremental update verification method based on a domestically developed root of trust.

[0005] To achieve the above objectives, the present invention adopts the following technical solution: a service chain firmware incremental update verification method based on a domestically developed root of trust, comprising:

[0006] The management terminal uses a binary differential algorithm to generate an incremental package from the current firmware version to the target firmware version, and generates a corresponding version certificate for the target firmware version.

[0007] The management terminal encapsulates the update task into a secure update instruction and signs the secure update instruction using the management terminal's private key;

[0008] The signed security update command and the incremental package are sent to the baseboard management controller of the server. The update agent built into the baseboard management controller uses a preset management public key to verify the signature of the security update command.

[0009] After successful verification, the update agent initiates a security update session request to the trusted cryptographic module of the server. In response to the request, the trusted cryptographic module creates a session context internally, selects an idle platform configuration register as the update process register, and resets the current value of the update process register to zero.

[0010] The update agent performs chained firmware update operations on each target component in the order of the target components defined in the security update instruction.

[0011] After all target components have been updated, the update agent sends a session submission instruction to the trusted cryptographic module. The trusted cryptographic module digitally signs the final value recorded in the update process register and returns the update completion credential containing the digital signature to the update agent, which then sends it back to the management terminal.

[0012] As a further aspect of the present invention, the update agent performs chained firmware update operations on each target component sequentially according to the target component order defined in the security update instruction, including:

[0013] The security update instruction includes a list of target components, the target version number of each component, the hash value of the incremental package, and a task identifier;

[0014] The update operation for each target component includes four stages: pre-measurement, incremental application, post-verification, and submission and consolidation.

[0015] The update agent combines the component identifier of the current target component, the target version number of the target component, and the hash value of the incremental package into a pre-measurement data, and sends the pre-measurement data to the trusted cryptographic module.

[0016] The trusted cryptographic module receives the pre-measured data, calls the national cryptographic hash algorithm to calculate the message digest of the pre-measured data, and writes the calculated message digest into the update process register in an extended manner to form a first-level integrity measurement record.

[0017] The update agent calls the firmware application logic to restore the incremental package in a local isolated temporary storage area, generating a complete image file corresponding to the target firmware version;

[0018] The update agent calls the national cryptographic hash algorithm again to calculate the message digest of the generated complete image file, and compares the calculation result with the hash value in the version certificate of the target firmware version carried in the security update instruction.

[0019] If the comparison results are consistent, the update agent writes the verified complete image file to the firmware main storage area corresponding to the target component, and writes the version certificate to the non-volatile storage area of ​​the trusted cryptographic module, thus completing the submission and solidification of the target component firmware.

[0020] As a further aspect of the present invention, after the trusted cryptographic module creates a session context internally in response to the request and selects an idle platform configuration register as the update process register, it further includes:

[0021] The trusted cryptographic module generates a session handle that is uniquely bound to the security update session and returns the session handle to the update agent;

[0022] In each subsequent pre-measurement operation, the update agent must send a measurement request to the trusted cryptographic module with the session handle to ensure that the measurement operation is performed in the correct session context.

[0023] When processing the measurement request, the trusted cryptographic module verifies the validity of the session handle. Only after the verification is successful does it perform the operation of expanding the latest measurement value into the update process register, thereby preventing cross-session measurement data obfuscation at the physical level.

[0024] As a further aspect of the present invention, when the update agent initiates a security update session request to the trusted cryptographic module of the server, it carries a complete list of all components involved in this update.

[0025] The trusted cryptography module establishes a component state tracking table in the session context based on the component list. The component state tracking table is used to record the update progress of each target component.

[0026] When performing the pre-measurement operation for each target component, the trusted cryptographic module, after completing the expansion of the measurement value, synchronously updates the corresponding component's mark in the component state tracking table to the measured state;

[0027] Before the update agent sends a session commit instruction to the trusted cryptographic module, the trusted cryptographic module first checks the component state tracking table to confirm that all components in the component list have been marked as measured; otherwise, it refuses to perform the session commit operation.

[0028] As a further aspect of the present invention, the security update instruction also includes a replay-prevention random number generated by the management terminal;

[0029] While creating a session context within the trusted cryptographic module, the anti-replay random number is stored in the session context;

[0030] When the update agent initiates a session submission command, it must send the anti-replay random number along with the current session handle to the trusted cryptographic module.

[0031] Upon receiving a session submission instruction, the trusted cryptographic module first checks whether the anti-replay random number in the instruction is completely consistent with the value stored in the session context. Only if the consistency is confirmed will the module continue to sign and return the final value of the update process register.

[0032] As a further aspect of the present invention, when a system startup failure or an abnormal firmware running state is detected, a firmware rollback process is triggered, specifically including:

[0033] The server's baseboard management controller or basic input / output system generates a rollback request, which explicitly specifies the target historical version number to which the rollback is expected, and sends the rollback request to the management terminal.

[0034] The management terminal evaluates the received rollback request. If the evaluation is successful, a secure rollback instruction is generated. The secure rollback instruction contains the target historical version number and the corresponding reverse incremental packet hash value, and is signed using the management terminal's private key.

[0035] The management terminal simultaneously extracts a reverse incremental package from the firmware repository for restoring from the current version to the target historical version;

[0036] After receiving the signed secure rollback instruction and the reverse incremental packet, the update agent of the baseboard management controller repeats the verification and execution process to complete the reverse update of the firmware.

[0037] As a further aspect of the present invention, when performing the reverse update process of the firmware, the trusted cryptographic module no longer reuses the previous update process register, but instead selects another platform configuration register that is in an idle state as the rollback process register.

[0038] The trusted cryptographic module creates a new session context for the rollback operation and resets the initial value of the rollback process register to zero;

[0039] In each loop of the update agent performing rollback operations in the order of components, the component identifier of the current component, the target historical version number, and the hash value of the reverse incremental packet are combined into rollback pre-measurement data and sent to the trusted cryptographic module.

[0040] The trusted cryptographic module calculates the message digest of the rollback pre-metric data and extends it into the rollback process register, thereby generating an independent rollback metric log.

[0041] As a further aspect of the present invention, after the reverse update process of the firmware is completed, the trusted cryptographic module signs the final value in the rollback process register to generate a rollback completion certificate.

[0042] The update agent sends the rollback completion certificate back to the management terminal;

[0043] After receiving the rollback completion certificate, the management terminal sends a global state reset command to the baseboard management controller.

[0044] In response to the global state reset command, the baseboard management controller restores the runtime version information of all components to the version information recorded in the version certificate corresponding to the target historical version number, and restarts the system to load the old firmware image.

[0045] As a further aspect of the present invention, a version certificate mapping table is maintained in the non-volatile storage area of ​​the trusted cryptographic module;

[0046] Whenever the firmware of a component completes an update or rollback operation, the update agent sends a certificate update instruction to the trusted cryptographic module, which contains the latest version certificate of the component.

[0047] The trusted cryptographic module searches for the corresponding component entry in the version certificate mapping table according to the certificate update instruction, and replaces the original entry content with the received new version certificate.

[0048] Each entry in the version certificate mapping table is bound to the metric log in its corresponding platform configuration register, together forming a complete firmware trusted state snapshot.

[0049] As a further aspect of the present invention, in the initial stage of each system power-on startup, the baseboard management controller will send a status proof request to the trusted cryptographic module.

[0050] The trusted cryptographic module combines the register values ​​of all current platform configuration registers and the digest information of the version certificate mapping table into a status report, and signs the status report using the identity key of the trusted cryptographic module to generate a startup status credential.

[0051] After obtaining the boot status certificate, the baseboard management controller compares it with its own maintained list of legitimate statuses to confirm the integrity and legitimacy of the current firmware chain, thereby deciding whether to allow the subsequent boot process to continue.

[0052] Compared with the prior art, the advantages and positive effects of the present invention are as follows:

[0053] Upon receiving a secure update session request from the update agent, the trusted cryptography module internally creates a session context and selects an idle platform configuration register as the update process register, resetting its current value to zero. By creating a dedicated session context, the update process is isolated from other system operations, preventing interference between different operations. Selecting a dedicated update process register and resetting its initial value provides a unique state record carrier for the update process, accurately recording the state information throughout the entire update process and preventing the update state from being confused or tampered with. Compared to conventional technologies that lack a dedicated state record carrier, this achieves precise control and traceability of the update process state.

[0054] After all target components have been updated, the trusted cryptographic module digitally signs the final value recorded in the update process register and returns the update completion credential containing the digital signature to the update agent, which then sends it back to the management terminal. By digitally signing the final value of the update process register, the update completion credential is directly bound to the status of the entire update process. The integrity and authenticity of the update result can be confirmed solely through this digital signature, forming a closed-loop verification of the update based on a domestically developed root of trust. Compared to conventional technologies that only send back the update result, this effectively prevents the risk of malicious tampering with the update result and forging update completion information, thus improving the security and reliability of incremental firmware updates in the service chain. Attached Figure Description

[0055] Figure 1 This is a flowchart of the service chain firmware incremental update verification method based on domestically developed root of trust as described in this invention;

[0056] Figure 2 A flowchart for the generation and verification of session handles;

[0057] Figure 3 A flowchart for the component state tracking table;

[0058] Figure 4 A graph showing the pass rate for integrity verification at each stage of rollback;

[0059] Figure 5 A time-consuming analysis diagram of the process for verifying the system's power-on startup status. Detailed Implementation

[0060] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0061] In the description of this invention, it should be understood that the terms "length," "width," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicating orientation or positional relationships, are based on the orientation or positional relationships shown in the accompanying drawings and are only for the convenience of describing the invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the invention. Furthermore, in the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0062] See Figure 1 The management terminal uses a binary differential algorithm to generate an incremental package from the current firmware version to the target firmware version and generates a corresponding version certificate for the target firmware version. The management terminal encapsulates the update task into a secure update command and signs the secure update command using its private key. The signed secure update command and incremental package are sent to the baseboard management controller on the server. The update agent built into the baseboard management controller verifies the signature of the secure update command using a pre-set management terminal public key. After successful verification, the update agent initiates a secure update session request to the server's trusted cryptographic module. In response to this request, the trusted cryptographic module internally creates a session context and selects an idle platform configuration register as the update process register, resetting the current value of the update process register to zero. The update agent performs chained firmware update operations on each target component sequentially according to the target component order defined in the secure update command. After all target components have been updated, the update agent sends a session commit command to the trusted cryptographic module. The trusted cryptographic module digitally signs the final value recorded in the update process register and returns an update completion credential containing the digital signature to the update agent, which then sends it back to the management terminal.

[0063] In one embodiment of the present invention, an embodiment of a service chain firmware incremental update verification method based on a domestically developed trusted root is applied to the firmware update process of a server. This process involves the sequential update of two components: "motherboard baseboard management controller firmware" and "hard disk backplane firmware." The security update instruction pre-generated by the management terminal explicitly specifies the target component order as follows: first update the "motherboard baseboard management controller firmware," then update the "hard disk backplane firmware." The security update instruction also includes the target version number "2.1.0" of the "motherboard baseboard management controller firmware," the target version number "1.5.0" of the "hard disk backplane firmware," the hash value "0xA1B2C3…" of the incremental packet from version "2.0.0" to "2.1.0," and the task identifier "UPDATE_20250320_001." After the update agent within the baseboard management controller verifies the signature on the management terminal, it immediately initiates a security update session request to the trusted cryptographic module. See also... Figure 2 The trusted cryptography module internally creates a session context and selects the platform configuration register "Platform Configuration Register 15" as the dedicated update process register for this time. It clears the current value of the update process register from its initial state to zero. At the same time, the trusted cryptography module generates a session handle "0xSESSION_ABC" that is uniquely bound to this session and returns it to the update agent. This session handle "0xSESSION_ABC" will be used in all subsequent interactions.

[0064] The update agent begins executing a chained firmware update operation, first targeting the first component, "Motherboard Baseboard Management Controller Firmware". The update agent combines the component identifier "BMC", the target version number "2.1.0", and the incremental packet hash value "0xA1B2C3..." to form a pre-measurement data entry. "Updating the proxy must include the session handle." "Send this pre-measured data to the trusted cryptographic module. The trusted cryptographic module verifies the session handle." "After it becomes valid, the national cryptographic hash algorithm SM3 is called to calculate the message digest of the pre-measured data, assuming the digest value is obtained." The trusted cryptographic module writes this digest value into the update process register "Platform Configuration Register 15" through an expansion operation. If the original value of the register is 0, its value after expansion becomes a new value calculated based on the original value and the new digest. This operation forms the first layer of integrity measurement record for the "motherboard baseboard management controller firmware" update. In some embodiments, the update agent allocates an isolated temporary storage area in the baseboard management controller memory, and in this area calls the firmware application logic to restore the received incremental packet, generating a complete image file corresponding to the target version "2.1.0". The update agent then calls the national cryptographic hash algorithm SM3 again to calculate the message digest of this complete image file. Assuming the digest value is " The update agent compares this calculation result with the hash value recorded in the version certificate issued by the management terminal for version "2.1.0" carried in the security update instruction. If the two are completely consistent, the update agent writes the verified complete image file to the main storage area corresponding to the "motherboard baseboard management controller firmware" and writes this version certificate to the non-volatile storage area of ​​the trusted cryptographic module, thereby completing the submission and solidification of the "motherboard baseboard management controller firmware".

[0065] The update agent performs the same process sequentially on the second target component, "Hard Disk Backplane Firmware." Optionally, the incremental package for "Hard Disk Backplane Firmware" may differ, and its pre-metric data is constructed as follows: "Update proxy carries the same session handle" "Send this data. The trusted cryptographic module will calculate its digest after verifying the validity of the session handle." "and then extend it again to the update process register "Platform Configuration Register 15", assuming that the final value of the register after the extension becomes " This value accumulates the complete history of pre-measuring the two components during this update session. In some embodiments, the update agent restores a complete image of the "disk backplane firmware" in a temporary storage area, calculates its digest, and compares it with the hash value within the version certificate of version "1.5.0". If they match, a write and certificate storage operation is performed. It can be understood that the session handle " The use of `<measuring>` ensures that all measurement operations from the "motherboard baseboard management controller firmware" to the "hard drive backplane firmware" are strictly confined to the same session context and sequentially recorded in the same update process register, "Platform Configuration Register 15," physically preventing confusion with measurement data from other sessions. After all target components are updated, the final value stored in the update process register "Platform Configuration Register 15" is... This is a cryptographic digest of the integrity of the entire chain update process.

[0066] In one embodiment of the present invention, see [reference] Figure 3 When the update agent initiates a security update session request to the server's trusted cryptographic module, its request message explicitly carries a list of all components involved in this update, such as a list containing three component identifiers: Upon receiving the request and creating a session context, the trusted cryptographic module parses the component list and dynamically builds a component state tracking table within the session context. This table contains entries identical to the list, with each entry initially marked as "unmeasured," precisely recording the update progress of each target component: "BIOS," "BMC," and "CPLD." In some embodiments, when the update agent begins performing a pre-measurement operation on the first component, "BIOS," after the trusted cryptographic module successfully calculates the message digest of the pre-measurement data and extends it to the update process register, it immediately updates the component state tracking table synchronously, changing the state of "BIOS" from "unmeasured" to "measured." The update agent then processes the component "BMC," and after its pre-measurement operation is completed, the trusted cryptographic module updates the table again. The component state tracking table marks the "BMC" state as "measured". After all planned component update operations have cycled through, assuming the last component "CPLD" has also been processed and marked, before the update agent finally sends the session commit instruction to the trusted cryptographic module, the trusted cryptographic module's internal logic will first automatically check the component state tracking table to confirm that the state fields of all components in the list have changed from "unmeasured" to "measured". Only when this condition is met will the trusted cryptographic module continue processing the session commit instruction. It's understandable that if, for any unforeseen reason, component "CPLD" is not successfully measured, its state will remain "unmeasured" in the table. The trusted cryptographic module will find the state incomplete during its check and thus directly refuse to execute the final signature commit operation. This prevents a situation where some component updates are missed but the entire update process is mistakenly judged as successful.

[0067] In practice, when generating a security update command, the management terminal generates a cryptographically secure random number as a replay protection random number, such as a 128-bit value. This anti-replay random number is then embedded into the structure of the security update instruction. While creating the session context within the trusted cryptographic module, this anti-replay random number, parsed from the verified instruction, is... "It is stored in a specific field within the session context. When the update agent completes all component updates and is ready to initiate a session commit command, the update agent must obtain this anti-replay random number from the original security update command." This, along with the current session handle, is encapsulated in a session commit command and sent to the trusted cryptographic module. Upon receiving the session commit command, the trusted cryptographic module's first operation is to extract the claimed anti-replay random number from the command and compare it bit-by-bit with the original value stored in the session context during session initialization. Only when the two values ​​are completely identical, for example, both are "", will the commit command proceed. Only when the commit instruction is confirmed to be fresh and not a replay attack on a historical instruction will the trusted cryptographic module recognize it as fresh and proceed with the subsequent signing operation on the final value of the update process register. Optionally, if the anti-replay random number carried in the commit instruction does not match the value stored in the session context, the trusted cryptographic module will immediately terminate the session and return an error, refusing to generate the update completion credential. In some embodiments, the component state integrity check and the anti-replay check have a logical order. One optional implementation is that the trusted cryptographic module performs a check on the component state tracking table only after verifying the consistency of the anti-replay random number. It can be understood that the component state tracking table ensures the integrity of the update operation and prevents the component from being missed in the update; while the anti-replay random number mechanism ensures the freshness of the update session and prevents malicious replay of historical update instructions. The combination of the two is formally expressed through the following logical relationship:

[0068]

[0069] in: Indicates whether submission is allowed. It is a replay-prevention random number verification function. It is the random number claimed in the submission command. It is a random number stored in the session context. The function returns true when the two are equal. It is a component state check function. This represents the component state tracking table. The function returns true when the state of all target entries in the table is "measured". The commit operation is only allowed to execute when both of these conditions are met (logical AND).

[0070] In one embodiment of the present invention, an embodiment of a service chain firmware incremental update verification method based on a domestically developed root of trust describes the triggering and execution of the firmware rollback process. For example, a server fails to boot after attempting to load a newly updated "Power Control Unit Firmware" version "2.0.0". During the initialization self-test, the baseboard management controller detects an abnormal firmware running state. The baseboard management controller generates a rollback request according to a preset strategy. The rollback request explicitly indicates that the target historical version number to be rolled back to is "1.5.0", and sends this rollback request to the remote centralized management terminal via the network. In some embodiments, the detection party can also be the system's basic input / output system. When the basic input / output system detects a critical hardware initialization failure during the boot phase, the basic input / output system sends a rollback request to the management terminal through the baseboard management controller channel. The rollback request also needs to explicitly carry a working target historical version number, such as "1.3.2".

[0071] The management console evaluates the received rollback request. This evaluation includes verifying the legitimacy of the request source, confirming that the target historical version "1.5.0" is a valid version existing in the firmware repository, and checking whether the current server status allows for the rollback operation. Upon successful evaluation, the management console generates a secure rollback command. This command must contain the target historical version number "1.5.0" and the theoretical hash value of the reverse incremental packet used to restore the system from the current problematic version "2.0.0" to "1.5.0". The management console digitally signs the secure rollback command using its private key. Essentially, while generating the command, the management console extracts the pre-calculated reverse incremental packet from the firmware repository using a binary differential algorithm. This reverse incremental packet is specifically used to reverse engineer the complete firmware image of version "1.5.0" from version "2.0.0". In practice, the management console sends the signed secure rollback command file and the reverse incremental packet data file together to the baseboard management controller of the faulty server.

[0072] Upon receiving the signed secure rollback command and reverse incremental packet, the update agent within the baseboard management controller repeats the verification and execution process similar to that of the forward update. The update agent uses the management public key pre-installed in its local protected storage to verify the digital signature of the secure rollback command, confirming its integrity and authenticity. After successful signature verification, the update agent parses the secure rollback command to obtain the target historical version number "1.5.0" and the reverse incremental packet hash value. In some embodiments, the update agent immediately begins the rollback operation, sharing the same security framework as the forward update but targeting a different version. The update agent initiates a new rollback session request to the trusted cryptographic module and, in subsequent steps, performs operations including pre-measurement, incremental application, and post-verification for the components requiring rollback. Optionally, for the rollback operation, the pre-measurement data will include the target historical version number "1.5.0" and the reverse incremental packet hash value. The update agent invokes the firmware application logic, using reverse incremental packets to restore the complete image of the historical version "1.5.0" in the temporary storage area. It calculates the hash value and compares it with the hash value carried in the secure rollback command or newly obtained from the management terminal's version certificate for "1.5.0". In practice, only if the comparison matches will the update agent write the restored historical firmware image to the corresponding component's main firmware storage area, completing the reverse firmware update and restoring the system to a known normal working state.

[0073] In one embodiment of the present invention, an embodiment of a service chain firmware incremental update verification method based on a domestically developed root of trust describes the complete process of independent measurement and state recovery in the firmware rollback process. For example, after a server's "baseboard management controller firmware" and "network control card firmware" are updated to a new version, a compatibility issue arises. The system triggers a reverse update process to roll back to a historical stable version "1.5.0". When executing the firmware reverse update process, the trusted cryptographic module no longer reuses the platform configuration register "Platform Configuration Register 15" used in the previous forward update. Instead, it selects another platform configuration register "Platform Configuration Register 18" from the idle register pool as the dedicated rollback process register for this rollback operation. The trusted cryptographic module creates a completely new and independent session context for the rollback operation and resets the initial value of the rollback process register "Platform Configuration Register 18" to zero. In some embodiments, the selection of the rollback process register "Platform Configuration Register 18" is physically isolated from the registers used in the forward update. This ensures that the measurement logs of the rollback operation and the measurement logs of the update operation are completely separated in storage space, avoiding cross-contamination of data.

[0074] In each loop where the update agent executes the rollback operation according to the component order defined in the security rollback command issued by the management terminal, the update agent combines the component identifier of the current component, the target historical version number "1.5.0", and the hash value of the reverse incremental packet into rollback pre-measurement data. Taking the first rollback component, "Baseboard Management Controller Firmware", as an example, its rollback pre-measurement data is constructed as follows: The update agent sends this data to the trusted cryptographic module. The trusted cryptographic module calls the national cryptographic hash algorithm to calculate " The message digest, assuming the digest value is " The trusted cryptographic module writes this digest value to the rollback process register "Platform Configuration Register 18" via an expansion operation. In practice, the expansion operation follows specified cryptographic expansion rules, thereby generating an independent rollback measurement log for the rollback operation. It can be understood that the subsequent rollback operation on the second component, "Network Control Card Firmware," will generate its corresponding rollback pre-measurement data. After calculation and expansion, its summary value is " This is further extended to "Platform Configuration Register 18", and the accumulated value ultimately stored in "Platform Configuration Register 18" "The rollback session fully recorded the measurement history of all components. During the rollback, the expansion operation can be formally expressed as:"

[0075]

[0076] in: This represents the rollback process register value after the pre-metric expansion of the i-th component. This refers to the SM3 hash algorithm. This represents the rollback pre-metric data for the i-th component. The symbol "||" indicates data concatenation, and the initial value is... .

[0077] After the firmware reverse update process is completed, the trusted cryptographic module uses its internal identity key to digitally sign the final value "0xPCR18_Final" in the rollback process register "Platform Configuration Register 18", generating an unforgeable rollback completion certificate. The update agent sends this rollback completion certificate back to the management terminal as cryptographic proof that the rollback operation has been securely and completely executed. After receiving the rollback completion certificate and verifying its signature validity, the management terminal issues a global state reset command to the baseboard management controller. In some embodiments, the global state reset command is a separate management command. In response to this global state reset command, the baseboard management controller restores the runtime version information of all relevant components from the faulty version record to the version information recorded in the version certificate corresponding to the target historical version number "1.5.0". In specific implementations, this operation may involve updating the component version cache or configuration database inside the baseboard management controller. After restoring the runtime version information, the baseboard management controller performs a system restart operation. The server loads the rolled-back old firmware image of version "1.5.0", thereby restoring the system to a normal working state.

[0078] See Figure 4 This is a chart showing the pass rate of integrity verification at each stage of the firmware rollback process, illustrating the pass rate of five key verification steps. All steps have a pass rate above 98%, indicating that the firmware rollback verification method possesses extremely high stability and security. Signature verification performs best, achieving a pass rate of 99.8%. This is because signature verification relies on the identity key of the trusted cryptographic module, which has the highest cryptographic strength and is virtually impossible to forge or tamper with. State reset is relatively weak, with the lowest pass rate (98.0%). This is usually related to operations such as system reboots and version information recovery, and may be affected by factors such as hardware status and external environment, making it a key area for future optimization. Hash value comparison is the core bottleneck, with a pass rate of 98.5%, indicating that corrupted incremental packages or mismatched version certificates are one of the main reasons for rollback failures. By improving the reliability of incremental package distribution and optimizing the version certificate management mechanism, the failure rate of hash value comparison can be further reduced.

[0079] In one embodiment of the present invention, an embodiment of a service chain firmware incremental update verification method based on a domestically developed root of trust describes the persistent storage of version certificates and the state proof mechanism at system startup. A version certificate mapping table is maintained in the non-volatile storage area of ​​the trusted cryptographic module. The structure of the version certificate mapping table can be designed as a key-value store with the component identifier as the key and the managed digitally signed version certificate data block as the value. Whenever the firmware of a component completes an update or rollback operation, the update agent in the baseboard management controller sends a certificate update instruction to the trusted cryptographic module. The certificate update instruction contains the latest, verified version certificate of the component. For example, when the "baseboard management controller firmware" is successfully updated from version "1.5.0" to version "2.0.0", the update agent sends a certificate update instruction containing the component identifier "BMC" and the complete version certificate data corresponding to version "2.0.0". The trusted cryptographic module, upon receiving the certificate update instruction, searches for the corresponding component entry with the key "BMC" in the version certificate mapping table. It then replaces the old version certificate data (version "1.5.0") stored in the original entry with the new version certificate data (version "2.0.0"), thus updating the mapping table. In some embodiments, a rollback operation also triggers the same process. If the "Baseboard Management Controller Firmware" rolls back from version "2.0.0" to version "1.5.0", the update agent sends a certificate update instruction containing "BMC" and the version "1.5.0" certificate. The trusted cryptographic module then updates the value corresponding to "BMC" in the version certificate mapping table again with the rolled-back version certificate. It is understandable that each entry in the version certificate mapping table is bound to the metric log in its corresponding platform configuration register. For example, the current version certificate entry of component "BMC" is associated with the metric log in platform configuration register "Platform Configuration Register 15" or "Platform Configuration Register 18" that records its most recent update or rollback operation. The version certificate mapping table stores the static identity claims of each component, while the metric log in the platform configuration register records the dynamic operation history of achieving this state. Together, they constitute a complete and verifiable snapshot of the server's trusted firmware state.

[0080] During the initial phase of each system power-on startup, after completing basic initialization, the baseboard management controller sends a status verification request to the trusted cryptographic module. In response to the status verification request, the trusted cryptographic module performs the following operations: reads the register values ​​of all platform configuration registers currently used for firmware measurement, such as "Platform Configuration Register 15," "Platform Configuration Register 18," etc.; simultaneously, the trusted cryptographic module calculates the cryptographic digest of the version certificate mapping table stored in the non-volatile storage area. The digest generation process can be expressed in the following form:

[0081]

[0082] in: This represents the output summary of the version certificate mapping table. This refers to the SM3 hash algorithm. This represents the serialized byte data of the entire version certificate mapping table. The trusted cryptography module combines the collected register values ​​of all relevant platform configuration registers with the calculated version certificate mapping table digest. This is combined into a structured status report. In specific implementations, the status report includes fields such as platform configuration register index, register value, and version certificate mapping table digest. The trusted cryptographic module digitally signs this status report using its unique identity key, generating a cryptographically non-repudiable boot status credential. After obtaining the boot status credential, the baseboard management controller compares it with its own maintained, authorized, legitimate status whitelist. The legitimate status whitelist pre-stores a list of legitimate platform configuration register expected values ​​and version certificate mapping table digests approved by the management terminal. The baseboard management controller verifies the signature validity of the boot status credential and checks whether the actual platform configuration register value and mapping table digest match any record in the legitimate status whitelist. In some embodiments, the baseboard management controller only confirms the integrity and legitimacy of the current firmware chain if the signature is valid and the content is completely consistent with a legitimate status record in the whitelist, thereby deciding to allow the subsequent basic input / output system boot and operating system loading processes to continue.

[0083] See Figure 5 This is a time-consuming analysis chart of the system power-on startup state verification process. It shows the operation time of the eight key steps from initiating the state verification to the final decision to start the system, reflecting the performance bottlenecks of the root of trust verification process. Calculating the mapping table digest is the biggest bottleneck, taking the longest time (15 milliseconds). This is because this step requires calculating the version certificate mapping table using the national cryptographic hash algorithm, making it the most computationally intensive part of the entire process. Signing and reading operations are time-consuming, followed by "signature status report" (12 milliseconds) and "read PCR value" (10 milliseconds). Both of these operations involve hardware interaction with the Trusted Cryptographic Module (TPM), which is limited by the TPM's processing capacity. The overall process is controllable, with a total time of approximately 68 milliseconds, which is within an acceptable range for server startup processes and will not significantly impact system startup time. The decision-making stage is extremely time-efficient; "deciding to start" only takes 3 milliseconds, indicating that this step is a purely logical judgment and does not involve complex cryptographic operations or hardware interaction.

[0084] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention in any other way. Any person skilled in the art may make changes or modifications to the above-disclosed technical content to create equivalent embodiments that can be applied to other fields. However, any simple modifications, equivalent changes, and modifications made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the protection scope of the present invention.

Claims

1. A service chain firmware incremental update verification method based on a domestically developed root of trust, characterized in that, The method includes: The management terminal uses a binary differential algorithm to generate an incremental package from the current firmware version to the target firmware version, and generates a corresponding version certificate for the target firmware version. The management terminal encapsulates the update task into a secure update instruction and signs the secure update instruction using the management terminal's private key; The signed security update command and the incremental package are sent to the baseboard management controller of the server. The update agent built into the baseboard management controller uses a preset management public key to verify the signature of the security update command. After successful verification, the update agent initiates a security update session request to the trusted cryptographic module of the server. In response to the request, the trusted cryptographic module creates a session context internally, selects an idle platform configuration register as the update process register, and resets the current value of the update process register to zero. The update agent performs chained firmware update operations on each target component in the order of the target components defined in the security update instruction. After all target components have been updated, the update agent sends a session submission instruction to the trusted cryptographic module. The trusted cryptographic module digitally signs the final value recorded in the update process register and returns the update completion credential containing the digital signature to the update agent, which then sends it back to the management terminal.

2. The service chain firmware incremental update verification method based on domestically developed root of trust as described in claim 1, characterized in that, The update agent performs chained firmware update operations on each target component sequentially according to the target component order defined in the security update instruction, including: The security update instruction includes a list of target components, the target version number of each component, the hash value of the incremental package, and a task identifier; The update operation for each target component includes four stages: pre-measurement, incremental application, post-verification, and submission and consolidation. The update agent combines the component identifier of the current target component, the target version number of the target component, and the hash value of the incremental package into a pre-measurement data, and sends the pre-measurement data to the trusted cryptographic module. The trusted cryptographic module receives the pre-measured data, calls the national cryptographic hash algorithm to calculate the message digest of the pre-measured data, and writes the calculated message digest into the update process register in an extended manner to form a first-level integrity measurement record. The update agent calls the firmware application logic to restore the incremental package in a local isolated temporary storage area, generating a complete image file corresponding to the target firmware version; The update agent calls the national cryptographic hash algorithm again to calculate the message digest of the generated complete image file, and compares the calculation result with the hash value in the version certificate of the target firmware version carried in the security update instruction. If the comparison results are consistent, the update agent writes the verified complete image file to the firmware main storage area corresponding to the target component, and writes the version certificate to the non-volatile storage area of ​​the trusted cryptographic module, thus completing the submission and solidification of the target component firmware.

3. The service chain firmware incremental update verification method based on a domestically developed root of trust as described in claim 2, characterized in that, After the trusted cryptographic module responds to the request by internally creating a session context and selecting an idle platform configuration register as the update process register, the process further includes: The trusted cryptographic module generates a session handle that is uniquely bound to the security update session and returns the session handle to the update agent; In each subsequent pre-measurement operation, the update agent must send a measurement request to the trusted cryptographic module with the session handle to ensure that the measurement operation is performed in the correct session context. When processing the measurement request, the trusted cryptographic module verifies the validity of the session handle. Only after the verification is successful does it perform the operation of expanding the latest measurement value into the update process register, thereby preventing cross-session measurement data obfuscation at the physical level.

4. The service chain firmware incremental update verification method based on a domestically developed root of trust as described in claim 3, characterized in that, When the update agent initiates a security update session request to the trusted cryptographic module of the server, it carries a complete list of all components involved in this update. The trusted cryptography module establishes a component state tracking table in the session context based on the component list. The component state tracking table is used to record the update progress of each target component. When performing the pre-measurement operation for each target component, the trusted cryptographic module, after completing the expansion of the measurement value, synchronously updates the corresponding component's mark in the component state tracking table to the measured state; Before the update agent sends a session commit instruction to the trusted cryptographic module, the trusted cryptographic module first checks the component state tracking table to confirm that all components in the component list have been marked as measured; otherwise, it refuses to perform the session commit operation.

5. The service chain firmware incremental update verification method based on domestically developed root of trust as described in claim 4, characterized in that, The security update instruction also includes a replay-protected random number generated by the management terminal; While creating a session context within the trusted cryptographic module, the anti-replay random number is stored in the session context; When the update agent initiates a session submission command, it must send the anti-replay random number along with the current session handle to the trusted cryptographic module. Upon receiving a session submission instruction, the trusted cryptographic module first checks whether the anti-replay random number in the instruction is completely consistent with the value stored in the session context. Only if the consistency is confirmed will the module continue to sign and return the final value of the update process register.

6. The service chain firmware incremental update verification method based on domestically developed root of trust as described in claim 5, characterized in that, When a system startup failure or firmware runtime abnormality is detected, a firmware rollback process is triggered, which includes: The server's baseboard management controller or basic input / output system generates a rollback request, which explicitly specifies the target historical version number to which the rollback is expected, and sends the rollback request to the management terminal. The management terminal evaluates the received rollback request. If the evaluation is successful, a secure rollback instruction is generated. The secure rollback instruction contains the target historical version number and the corresponding reverse incremental packet hash value, and is signed using the management terminal's private key. The management terminal simultaneously extracts a reverse incremental package from the firmware repository for restoring from the current version to the target historical version; After receiving the signed secure rollback instruction and the reverse incremental packet, the update agent of the baseboard management controller repeats the verification and execution process to complete the reverse update of the firmware.

7. The service chain firmware incremental update verification method based on a domestically developed root of trust as described in claim 6, characterized in that, When performing the reverse update process of the firmware, the trusted cryptographic module no longer reuses the previous update process register, but instead selects another idle platform configuration register as the rollback process register. The trusted cryptographic module creates a new session context for the rollback operation and resets the initial value of the rollback process register to zero; In each loop of the update agent performing rollback operations in the order of components, the component identifier of the current component, the target historical version number, and the hash value of the reverse incremental packet are combined into rollback pre-measurement data and sent to the trusted cryptographic module. The trusted cryptographic module calculates the message digest of the rollback pre-metric data and extends it into the rollback process register, thereby generating an independent rollback metric log.

8. The service chain firmware incremental update verification method based on a domestically developed root of trust as described in claim 7, characterized in that, After the reverse update process of the firmware is completed, the trusted cryptographic module signs the final value in the rollback process register to generate a rollback completion certificate. The update agent sends the rollback completion certificate back to the management terminal; After receiving the rollback completion certificate, the management terminal sends a global state reset command to the baseboard management controller. In response to the global state reset command, the baseboard management controller restores the runtime version information of all components to the version information recorded in the version certificate corresponding to the target historical version number, and restarts the system to load the old firmware image.

9. The service chain firmware incremental update verification method based on a domestically developed root of trust as described in claim 8, characterized in that, A version certificate mapping table is maintained in the non-volatile storage area of ​​the trusted cryptographic module; Whenever the firmware of a component completes an update or rollback operation, the update agent sends a certificate update instruction to the trusted cryptographic module, which contains the latest version certificate of the component. The trusted cryptographic module searches for the corresponding component entry in the version certificate mapping table according to the certificate update instruction, and replaces the original entry content with the received new version certificate. Each entry in the version certificate mapping table is bound to the metric log in its corresponding platform configuration register, together forming a complete firmware trusted state snapshot.

10. The service chain firmware incremental update verification method based on a domestically developed root of trust as described in claim 9, characterized in that, During the initial phase of each system power-on startup, the baseboard management controller will send a status proof request to the trusted cryptographic module. The trusted cryptographic module combines the register values ​​of all current platform configuration registers and the digest information of the version certificate mapping table into a status report, and signs the status report using the identity key of the trusted cryptographic module to generate a startup status credential. After obtaining the boot status certificate, the baseboard management controller compares it with its own maintained list of legitimate statuses to confirm the integrity and legitimacy of the current firmware chain, thereby deciding whether to allow the subsequent boot process to continue.

Images