Firmware upgrading system and method, electronic equipment, storage medium and program product

Abstract

The invention discloses a firmware upgrading system and method, electronic equipment, a storage medium and a program product, and relates to the technical field of server hardware management.The system comprises a firmware issuing end used for conducting block encryption processing on target upgrading firmware so as to generate a hash tree, conducting signature on a root hash value of the hash tree based on a root layer private key, generating first signature data and sending the first signature data to a server; storing a root layer private key; the firmware supervision end is used for generating second signature data by using the intermediate layer private key and storing the intermediate layer private key; the firmware use end is used for generating third signature data by using the leaf layer private key and storing the leaf layer private key; the firmware publishing end writes a data packet formed by the first signature data, the second signature data, the third signature data and the root hash value into the block chain; and the firmware using end verifies the data packet, and if the verification is passed, firmware upgrading is carried out. The technical problem of relatively low security of a firmware upgrading mode in related technologies is solved, and the technical effect of improving the firmware upgrading security is achieved.

Description

Technical Field

[0001] This application relates to the field of server hardware management technology, and in particular to firmware upgrade systems, methods, electronic devices, storage media and program products. Background Technology

[0002] The Board Management Controller (BMC) is an embedded system located on the server motherboard. It monitors and manages server hardware and system resources. The security and integrity of the BMC firmware directly determine the overall stability and data security of the server. Upgrading the BMC firmware fixes vulnerabilities and adapts to new hardware, ensuring stable system operation.

[0003] The BMC firmware upgrade method in related technologies involves the BMC firmware publisher encrypting the upgrade firmware using the RSA (Rivest-Shamir-Adleman) algorithm or Elliptic Curve Cryptography (ECC) before releasing it. The user then obtains the encrypted upgrade firmware, decrypts it, and performs the upgrade. However, in a quantum computing environment, Shor's algorithm can crack the RSA or ECC algorithms in just a few hours. Furthermore, this BMC firmware upgrade method relies on a centralized server storing the private key, posing a significant risk of private key leakage and resulting in low security for the upgrade process. Summary of the Invention

[0004] This application provides firmware upgrade systems, methods, electronic devices, storage media, and program products to at least address the problem of low firmware security during firmware upgrades in related technologies.

[0005] This application provides a firmware upgrade system, including a firmware release terminal, a firmware user terminal, and a firmware monitoring terminal; The firmware release terminal is used to obtain the target upgrade firmware of the controller; to perform block encryption processing on the target upgrade firmware to obtain multiple encrypted target upgrade firmware blocks; to generate a hash tree based on the multiple encrypted target upgrade firmware blocks; to sign the root hash value of the hash tree based on the root private key of the hash tree to generate the first signature data, and to store the root private key. The firmware monitoring terminal is used to sign the first signature data using the intermediate layer private key of the hash tree, generate the second signature data, and store the intermediate layer private key. The firmware user terminal is used to sign the second signature data using the leaf layer private key of the hash tree, generate the third signature data, and store the leaf layer private key; The firmware release client is also used to write data packets consisting of the first signature data, the second signature data, the third signature data, and the root hash value into the blockchain; The firmware user is also used to obtain data packets from the blockchain, verify the data packets, and if the verification is successful, obtain multiple encrypted target upgrade firmware blocks from the firmware publisher, and perform firmware upgrade of the controller based on the multiple encrypted target upgrade firmware blocks.

[0006] This application also provides a firmware upgrade method, including: Based on the firmware release terminal, obtain the target upgrade firmware of the controller; perform block encryption processing on the target upgrade firmware to obtain multiple encrypted target upgrade firmware blocks; generate a hash tree based on the multiple encrypted target upgrade firmware blocks; sign the root hash value of the hash tree based on the root private key of the hash tree to generate the first signature data, and store the root private key. Based on the firmware monitoring terminal, the first signature data is signed using the intermediate private key of the hash tree, the second signature data is generated, and the intermediate private key is stored. Based on the firmware user, the second signature data is signed using the private key of the leaf layer of the hash tree, the third signature data is generated, and the private key of the leaf layer is stored. Based on the firmware release client, a data packet consisting of the first signature data, the second signature data, the third signature data, and the root hash value is written into the blockchain; Based on the firmware user end, data packets are obtained from the blockchain and verified. If the verification passes, multiple encrypted target upgrade firmware blocks are obtained from the firmware publisher end, and the controller firmware is upgraded based on the multiple encrypted target upgrade firmware blocks.

[0007] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for executing the computer program to implement the steps of the firmware upgrade method described above.

[0008] This application also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of the above-described firmware upgrade method.

[0009] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the above-described firmware upgrade method.

[0010] This application describes a system where the firmware publisher obtains the target upgrade firmware for the controller; performs block encryption on the target upgrade firmware to obtain multiple encrypted target upgrade firmware blocks; generates a hash tree based on these blocks; signs the root hash value of the hash tree using the root private key to generate first signature data and stores the root private key; the firmware supervisor signs the first signature data using the intermediate private key of the hash tree to generate second signature data and stores the intermediate private key; the firmware user signs the second signature data using the leaf private key of the hash tree to generate third signature data and stores the leaf private key; the firmware publisher also writes a data packet consisting of the first, second, and third signature data and the root hash value into the blockchain; and the firmware user retrieves the data packet from the blockchain, verifies it, and if the verification passes, retrieves multiple encrypted target upgrade firmware blocks from the firmware publisher and performs firmware upgrades on the controller based on these blocks. By performing block encryption on the target upgrade firmware, the system's ability to resist quantum computing attacks can be improved. By storing the root private key, intermediate private key, and leaf private key on the firmware release end, firmware monitoring end, and firmware user end respectively, decentralized storage of private keys is achieved, reducing the risk of private key leakage. Therefore, it can solve the technical problem of low security in the BMC firmware upgrade method in related technologies and achieve the technical effect of improving the security of firmware upgrades. Attached Figure Description

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

[0012] Figure 1 This is a schematic diagram of the structure of a firmware upgrade system provided in an embodiment of this application; Figure 2 A schematic diagram illustrating the generation process of a multi-level signature chain provided in this application embodiment; Figure 3 A flowchart illustrating the smart contract verification data packet provided in an embodiment of this application; Figure 4 A flowchart illustrating a firmware upgrade method provided in an embodiment of this application; Figure 5 A flowchart illustrating yet another firmware upgrade method provided in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

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

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

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

[0016] The BMC (Browser Controller) is a controller that provides intelligent management of the motherboard based on the Intelligent Platform Management Interface (IPMI) technical design specification. The security and integrity of the BMC firmware directly determine the overall operational stability and data security of the server. Upgrading the BMC firmware to fix vulnerabilities and adapt to new hardware ensures stable system operation.

[0017] The firmware upgrade method in related technologies is as follows: the BMC firmware publisher encrypts the BMC upgrade firmware using RSA or ECC algorithms before releasing it. The BMC firmware user obtains the encrypted upgrade firmware, decrypts it, and then performs the BMC firmware upgrade based on the decrypted firmware. In a quantum computing environment, Shor's algorithm can crack the RSA or ECC algorithms in just a few hours. For example, RSA-2048 can be cracked in just a few hours in a 4000-qubit environment. Furthermore, the BMC firmware upgrade method in related technologies relies on a centralized server to store the private key. Once the server is compromised or experiences a single point of failure, it will lead to private key leakage or service termination. Therefore, this method carries a high risk of private key leakage, resulting in low security for BMC firmware upgrades. RSA is an asymmetric encryption algorithm based on the mathematical problem of large integer factorization and is widely used in data encryption, digital signatures, and key exchange. ECC is an asymmetric encryption algorithm based on elliptic curve mathematics. It uses a shorter key than RSA at the same security strength, providing advantages in efficient computation and storage. Shor's algorithm is a quantum computing algorithm primarily used for efficiently factoring large integers and solving discrete logarithm problems. Leveraging the parallel computing power of quantum computers, through operations such as quantum Fourier transforms, it reduces problems that traditional computers require exponential time to solve (such as the large integer factorization relied upon by RSA encryption) to polynomial time, thus posing a potential threat to existing public-key cryptosystems.

[0018] Furthermore, the firmware upgrade methods in related technologies rely solely on simple hash verification of the entire firmware upgrade by the BMC, lacking block-level verification and location capabilities, and thus failing to accurately identify cases where parts of the firmware have been tampered with.

[0019] In multi-organizational collaboration scenarios (such as supply chain management), firmware upgrades require authorization from multiple parties. However, the firmware upgrade methods in related technologies lack decentralized verification mechanisms, resulting in cumbersome processes and low efficiency.

[0020] To address the aforementioned technical problems, embodiments of this application provide a firmware upgrade system, method, electronic device, storage medium, and program product. The firmware upgrade system includes a firmware publishing end, a firmware user end, and a firmware monitoring end. The firmware publishing end is used to obtain the target upgrade firmware for the controller; to perform block encryption processing on the target upgrade firmware to obtain multiple encrypted target upgrade firmware blocks; to generate a hash tree based on the multiple encrypted target upgrade firmware blocks; to sign the root hash value of the hash tree based on the root private key of the hash tree to generate first signature data, and to store the root private key; the firmware monitoring end is used to use the intermediate private key of the hash tree to... The first signature data is signed to generate the second signature data, and the intermediate layer private key is stored. The firmware user end uses the leaf layer private key of the hash tree to sign the second signature data, generating the third signature data, and stores the leaf layer private key. The firmware publisher end also writes the data packet composed of the first, second, and third signature data and the root hash value into the blockchain. The firmware user end also retrieves the data packet from the blockchain, verifies the data packet, and if the verification passes, retrieves multiple encrypted target upgrade firmware blocks from the firmware publisher end, and performs firmware upgrades on the controller based on these multiple encrypted target upgrade firmware blocks. The system provided by the above scheme improves the ability to resist quantum computing attacks by performing block-level encryption processing on the target upgrade firmware, provides block-level verification and location capabilities, and can accurately identify cases where some firmware has been tampered with. By implementing three-level signature through the root layer private key, intermediate layer private key, and leaf layer private key, and storing the root layer private key, intermediate layer private key, and leaf layer private key respectively on the firmware publisher end, firmware supervisor end, and firmware user end, decentralized storage of private keys is achieved, reducing the risk of private key leakage and improving firmware upgrade security and efficiency.

[0021] This application provides a firmware upgrade system. Figure 1 This is a schematic diagram of the firmware upgrade system provided in the embodiments of this application, as shown below. Figure 1 As shown, the firmware upgrade system includes a firmware release client, a firmware user client, and a firmware monitoring client. The firmware release client is the platform for firmware release by the firmware releaser, the firmware user client is the platform for firmware usage by the firmware user, and the firmware monitoring client is the platform for firmware monitoring by the firmware regulator. The firmware user can be an enterprise administrator.

[0022] The firmware release terminal is used to obtain the target upgrade firmware of the controller; to perform block encryption processing on the target upgrade firmware to obtain multiple encrypted target upgrade firmware blocks; to generate a hash tree based on the multiple encrypted target upgrade firmware blocks; to sign the root hash value of the hash tree based on the root private key of the hash tree to generate the first signature data, and to store the root private key.

[0023] The controller is BMC. The hash tree is a Merkle tree, a tree-like data structure based on a cryptographic hash algorithm. It recursively combines the hash values ​​of data blocks layer by layer to generate a root hash value, which is used to efficiently verify the integrity and consistency of large-scale data.

[0024] The root private key is generated based on a quantum-resistant digital signature algorithm and serves as the root trust anchor for the entire signature chain consisting of the first, second, and third signature data. This quantum-resistant digital signature algorithm can be the eXtended Merkle Signature Scheme (XMSS), a hash function-based quantum-resistant digital signature algorithm that uses a Merkle tree structure to efficiently extend and verify one-time signatures.

[0025] The firmware monitoring terminal is used to sign the first signature data using the intermediate layer private key of the hash tree, generate the second signature data, and store the intermediate layer private key.

[0026] The intermediate layer private key is derived from the root layer private key, that is, it is derived from the root layer key through key derivation, ensuring the inheritance relationship of permissions.

[0027] The firmware user terminal is used to sign the second signature data using the leaf layer private key of the hash tree, generate the third signature data, and store the leaf layer private key.

[0028] The leaf layer private key is derived from the intermediate layer private key and is used for final signature authorization.

[0029] It should be noted that the hash tree generation process is completed before firmware release. The signing operations are performed in a physically isolated signing server; that is, the processes of signing the root hash value, the first signature data, and the second signature data are all executed in a physically isolated signing server. Network interfaces and external storage devices are disabled to prevent private key leakage and ensure the offline security of the signature chain.

[0030] The XMSS signature engine employs the XMSS algorithm and a three-tiered hierarchical key structure. It generates independent public-private key pairs for the root, middle, and leaf layers of the hash tree, corresponding to the firmware publisher, firmware supervisor, and enterprise administrator, respectively, ensuring separation of permissions and quantum-resistant security. Understandably, quantum-resistant digital signature algorithms like XMSS require significant computing resources. Generating signatures locally on the BMC in real-time would prolong BMC firmware upgrade time and affect the continuity of server availability. This application's embodiment shortens BMC firmware upgrade time and ensures server availability continuity by performing the signature operation on a physically isolated signature server.

[0031] The firmware release client is also used to write data packets consisting of the first signature data, the second signature data, the third signature data, and the root hash value into the blockchain.

[0032] Blockchain is a decentralized distributed ledger technology that uses cryptographic methods to package transaction data into chronologically linked blocks, forming an immutable chain structure. It employs a consensus mechanism that allows all nodes to jointly maintain the ledger, ensuring data authenticity and security without a central authority. With its decentralized, transparent, and immutable characteristics, blockchain is widely used in smart contracts, supply chain management, and other fields, providing innovative solutions for digital information.

[0033] The blockchain in this application adopts a consortium blockchain architecture. A consortium blockchain architecture refers to a distributed ledger system jointly maintained by multiple pre-selected authoritative nodes, falling between public blockchains (completely open) and private blockchains (single control). Its core feature is a node access mechanism: nodes participating in ledger recording must be authorized and certified by consortium members (such as firmware publishers, firmware users, and enterprise administrators), rather than being completely open or under single control. The consortium blockchain architecture employs decentralized governance; specifically, consortium members jointly decide on on-chain affairs (such as upgrade rules, access standards, etc.) through democratic voting or protocol rules.

[0034] The firmware user is also used to obtain data packets from the blockchain, verify the data packets, and if the verification is successful, obtain multiple encrypted target upgrade firmware blocks from the firmware publisher, and perform firmware upgrade of the controller based on the multiple encrypted target upgrade firmware blocks.

[0035] The firmware upgrade system provided in this application improves the ability to resist quantum computing attacks by performing block encryption on the target firmware to be upgraded. By storing the root layer private key, intermediate layer private key, and leaf layer private key on the firmware release end, firmware monitoring end, and firmware user end respectively, decentralized storage of private keys is achieved, reducing the risk of private key leakage. Therefore, it can solve the technical problem of low security in the BMC firmware upgrade method in related technologies, and achieve the technical effect of improving the security of firmware upgrades.

[0036] In some alternative implementations, the firmware release client is specifically used for: The target upgrade firmware is divided into blocks to obtain multiple target upgrade firmware blocks.

[0037] Specifically, based on the flash memory page size of the BMC (usually 4KB), the target upgrade firmware of the BMC is divided into blocks of 1MB each, ensuring that each target upgrade firmware block occupies 256 consecutive storage pages, avoiding performance loss caused by cross-page writing, and ensuring that each target upgrade firmware block can be flashed independently.

[0038] Multiple target keys are generated using a hash-based message authentication code deterministic random bit generator.

[0039] Specifically, a Hash-based Message Authentication Code-Deterministic Random Bit Generator (HMAC-DRBG) is used to generate multiple 256-bit Advanced Encryption Standard (AES) keys. In other words, the target key is a 256-bit AES key. It should be noted that AES is a symmetric encryption algorithm that uses block cipher technology, supports key lengths of 128, 192, and 256 bits, and features fast encryption speed, high security, and low resource consumption.

[0040] Multiple target upgrade firmware blocks are encrypted using multiple sets of target keys to obtain multiple encrypted first upgrade firmware blocks. One set of target keys is used to encrypt one target upgrade firmware block.

[0041] Understandably, encrypting a target upgrade firmware block using a set of target keys ensures the unpredictability and uniqueness of the keys. Each target upgrade firmware block is encrypted using an independent key to prevent the leakage of a single key from exposing global data.

[0042] Obtain the initialization vector and authentication tag corresponding to the first upgrade firmware block. Append the initialization vector to the header of the first upgrade firmware block and append the authentication tag to the tail of the first upgrade firmware block to obtain the encrypted target upgrade firmware block. Note that the initialization vectors corresponding to multiple first upgrade firmware blocks are different.

[0043] In this embodiment, the target upgrade firmware block is encrypted using AES-Galois / Counter Mode (GCM)-256 encryption mode to obtain the encrypted target upgrade firmware block, supporting integrated encryption and authentication operations. First, the target upgrade firmware block is encrypted using a 256-bit AES key to obtain the encrypted first upgrade firmware block, i.e., the ciphertext. Simultaneously with the AES key encryption, the GCM mode generates an initialization vector and an authentication tag for the first upgrade firmware block. The initialization vector ensures that the same target upgrade firmware block generates different encrypted target upgrade firmware blocks, and the authentication tag is used to verify data integrity during decryption.

[0044] It should be noted that each first upgrade firmware block corresponds to a unique 12-byte initialization vector and a 16-byte authentication tag.

[0045] It should be further noted that a hardware acceleration engine can be used to encrypt multiple target upgrade firmware blocks in parallel to improve processing speed. This hardware acceleration engine can be Quick Assist Technology (QAT), which significantly improves encryption, decryption, and data compression performance by offloading computationally intensive tasks from the central processing unit to dedicated hardware.

[0046] The firmware upgrade system provided in this application uses an independently generated target key to encrypt each target upgrade firmware block. Even if one key is cracked, it will not affect the confidentiality of other target upgrade firmware blocks, thus improving firmware security. By generating target keys based on HMAC-DRBG, the attack resistance of the keys themselves is enhanced. By attaching an independent initialization vector and authentication tag to each first upgrade firmware block, integrated encryption and authentication protection is achieved, enhancing data integrity and security. By utilizing a hardware acceleration engine to encrypt multiple target upgrade firmware blocks in parallel, encryption efficiency is improved.

[0047] In some alternative implementations, the firmware release client is specifically used for: Using a secure hash algorithm, multiple target hash values ​​corresponding to multiple encrypted target upgrade firmware blocks are determined.

[0048] Among them, the secure hash algorithm can be the Secure Hash Algorithm (SHA)-256, which uses complex bit operations to convert data of arbitrary length into a unique 256-bit (32-byte) hash value, and has collision resistance and irreversibility.

[0049] Multiple target hash values ​​are used as leaf nodes of the hash tree. This can be understood as follows: the target hash values ​​corresponding to the target upgrade firmware blocks are arranged from left to right according to their order, thus forming the leaf nodes of the hash tree.

[0050] Following the binary tree structure, the hash values ​​corresponding to two adjacent nodes are merged layer by layer until the root hash value is generated, thus obtaining the hash tree.

[0051] Understandably, following the binary tree structure, the target hash values ​​corresponding to two adjacent leaf nodes are merged from left to right to generate the hash value of the corresponding parent node. After obtaining the hash values ​​of multiple parent nodes, the process continues to merge the hash values ​​of two adjacent nodes layer by layer upwards until the root hash value is generated, thus obtaining the hash tree.

[0052] To make the generation process of a multi-level signature chain clearer, combined with Figure 2 The process of generating a multi-level signature chain is described. Figure 2 This is a schematic diagram of the multi-level signature chain generation process provided in the embodiments of this application, such as... Figure 2 As shown, the process includes: dividing the target upgrade firmware into 1MB blocks; encrypting multiple target upgrade firmware blocks using different target keys; using the multiple target hash values ​​corresponding to the encrypted target upgrade firmware blocks as leaf nodes of a hash tree; merging the hash values ​​corresponding to adjacent nodes layer by layer according to a binary tree structure until a root hash value is generated; the firmware publisher signing the root hash value using the root private key to generate the first signature data; the firmware supervisor signing the first signature data using the intermediate private key to generate the second signature data; the firmware user signing the second signature data using the leaf private key to generate the third signature data; and uploading the multi-level signature chain composed of the first, second, and third signature data with additional data to the blockchain. The additional data includes the root hash value, the storage address of the root public key, the storage address of the intermediate public key, and the storage address of the leaf public key.

[0053] The firmware upgrade system provided in this application embodiment supports block-level integrity verification by introducing a hash tree structure, making the location of tampering more accurate.

[0054] In some alternative implementations, the firmware release client is specifically used for: The root private key is split into multiple root private key fragments, where the root private key is generated based on a digital signature algorithm resistant to quantum computing attacks.

[0055] The splitting can be performed using the Shamir secret sharing algorithm. For example, the root private key is split into 5 root private key fragments, and the recovery threshold is 3 / 5, meaning that at least 3 root private key fragments are needed to jointly recover the root private key.

[0056] The first number of root private key fragments from the multiple root private key fragments are stored in multiple hardware security modules of the firmware release end.

[0057] For example, the first set of three private key fragments can be stored in three different hardware security modules (HSMs) on the firmware release end. Specifically, root private key fragment 1, root private key fragment 2, and root private key fragment 3 are stored in one hardware security module, root private key fragment 1 in one hardware security module, and root private key fragment 3 in one hardware security module. A hardware security module is a dedicated hardware device that protects the security of sensitive data such as keys through physical isolation and encryption technology. Its core function is to provide a highly secure execution environment for encryption operations.

[0058] The remaining root private key fragments, excluding the first number of root private key fragments, are encrypted and stored in the blockchain node.

[0059] For example, root private key fragment 4 and root private key fragment 5 are encrypted and stored on a blockchain node. It should be noted that this blockchain node is a high-security blockchain node. The algorithm used to encrypt root private key fragment 4 and root private key fragment 5 can be the AES-GCM-256 encryption algorithm. The AES-GCM-256 encryption algorithm key is stored in a trusted execution environment to prevent remote theft or tampering.

[0060] The firmware upgrade system provided in this application generates a root private key based on the XMSS algorithm, ensuring that the root private key can resist quantum computing attacks and guaranteeing its security. By splitting the root private key into multiple root private key fragments and storing these fragments separately in the hardware security module and blockchain node of the firmware release end, the risk of single-point leakage of root private key fragments is avoided, further improving the security of the root private key.

[0061] In some alternative implementations, the firmware monitoring terminal is specifically used for: The intermediate private key is split into multiple intermediate private key fragments, where the intermediate private key is derived from the root private key.

[0062] As mentioned earlier, the splitting can be performed using the Shamir secret sharing algorithm. For example, the intermediate private key is split into 5 intermediate private key fragments, with a recovery threshold of 3 / 5.

[0063] The second number of intermediate layer private key fragments are stored in multiple hardware security modules of the firmware monitoring terminal.

[0064] For example, the second quantity can be two, that is, intermediate layer private key fragment 1 and intermediate layer private key fragment 2 are stored in two different hardware security modules of the firmware monitoring terminal respectively.

[0065] The remaining intermediate layer private key fragments, excluding the second number of intermediate layer private key fragments, are encrypted and stored on cross-regional blockchain nodes.

[0066] For example, intermediate layer private key fragments 3, 4, and 5 are encrypted and stored on cross-regional blockchain nodes to achieve geographical redundancy. The encryption algorithm used for intermediate layer private key fragments 3, 4, and 5 can be the AES-GCM-256 encryption algorithm. The AES-GCM-256 encryption algorithm key is stored in a trusted execution environment to prevent remote theft or tampering.

[0067] In some alternative implementations, the firmware user is specifically used for: The leaf layer private key is split into multiple leaf layer private key fragments, where the leaf layer private key is derived from the intermediate layer private key.

[0068] As mentioned earlier, the splitting can be performed using the Shamir secret sharing algorithm. For example, the leaf layer private key is split into 5 leaf layer private key fragments, with a recovery threshold of 3 / 5.

[0069] The third number of leaf layer private key fragments from the multiple leaf layer private key fragments are stored in multiple hardware security modules of the firmware user.

[0070] For example, the third quantity can be three, that is, leaf private key fragment 1, leaf private key fragment 2 and leaf private key fragment 3 are stored in three different hardware security modules of the firmware user.

[0071] The remaining leaf layer private key fragments, excluding the third number of leaf layer private key fragments, are encrypted and stored in the blockchain node.

[0072] For example, leaf layer private key shard 4 and leaf layer private key shard 5 are encrypted and stored on a blockchain node. It should be noted that this blockchain node is a high-security blockchain node. The algorithm used to encrypt leaf layer private key shard 4 and leaf layer private key shard 5 can be the AES-GCM-256 encryption algorithm. The AES-GCM-256 encryption algorithm key is stored in a trusted execution environment to prevent remote theft or tampering.

[0073] In some optional implementations, the firmware publisher is also used to obtain the root public key corresponding to the root private key and store the root public key in the blockchain's smart contract.

[0074] Understandably, the root public key and root private key are paired to generate the initial signature data, which is then stored in plaintext in the blockchain's smart contract. A smart contract is an automatically executed, immutable digital protocol; essentially, it's a piece of program code deployed on the blockchain. When preset conditions are met, the contract automatically triggers the corresponding operation without human intervention.

[0075] The firmware monitoring terminal is also used to obtain the intermediate layer public key corresponding to the intermediate layer private key, encrypt the intermediate layer public key and store it in the hardware security module of the firmware monitoring terminal.

[0076] It is understandable that the intermediate layer public key is generated by pairing the intermediate layer private key.

[0077] The firmware is also used to obtain the leaf layer public key corresponding to the leaf layer private key and store the leaf layer public key in the blockchain smart contract.

[0078] Understandably, the leaf layer public key and leaf layer private key are paired and generated, and stored in plaintext in the blockchain's smart contract for global verification and access.

[0079] The firmware upgrade system provided in this application improves the overall anti-attack capability of the system by storing the root and leaf public keys in a smart contract on the blockchain and storing the intermediate public key in the hardware security module of the firmware monitoring terminal.

[0080] In some optional implementations, the firmware publisher is also used to verify the first signature data using the root public key after generating the first signature data, and obtain the first verification result.

[0081] The firmware monitoring terminal is also used to verify the second signature data using the intermediate layer public key after the second signature data is generated, and to obtain the second verification result.

[0082] The firmware user also uses the leaf layer public key to verify the third signature data after it is generated, and obtain the third verification result.

[0083] Understandably, after each level of signature operation is completed, the validity is verified using the corresponding public key to prevent erroneously signed data from being uploaded to the blockchain. It should be noted that the integrity and version history of the public key chain, consisting of the root public key, intermediate public keys, and leaf public keys, are stored on the blockchain. Any modification requires consensus from more than 50% of the nodes, ensuring tamper-proof protection.

[0084] Specifically, the firmware release client is used to write a data packet consisting of the first signature data, the second signature data, the third signature data, the root hash value, the storage address of the root public key, the storage address of the intermediate public key, and the storage address of the leaf public key into the blockchain when the first verification result, the second verification result, and the third verification result are all verified.

[0085] Specifically, the signature chain consisting of the first, second, and third signature data, along with the root hash value, is encapsulated into a JSON object. Version number, timestamp, firmware description, and public key index are added to form a data packet, facilitating subsequent traceability and verification. It should be noted that the public key index includes the storage addresses of the root public key, intermediate public keys, and leaf public keys.

[0086] Data packets are written to the blockchain through smart contracts, triggering the blockchain consensus mechanism to ensure that the data is immutable.

[0087] The firmware upgrade system provided in this application ensures the accuracy of the uploaded data by immediately verifying the validity of the signed data using the corresponding public key after each level of signing is completed, preventing erroneous signed data from being uploaded to the blockchain, thus ensuring the accuracy of the firmware upgrade process.

[0088] In some optional implementations, the firmware user includes a controller proxy module, i.e., a BMC proxy module, which is used for: The data packet is retrieved from the blockchain. Using a smart contract, the root public key is obtained based on the storage address of the root public key in the data packet. The first signature data in the data packet is verified based on the root public key to obtain the fourth verification result.

[0089] The BMC agent module integrates a lightweight blockchain client, supporting functions such as firmware download, signature verification, and on-chain interaction. The BMC agent module submits data packets to the smart contract verification interface, which triggers the smart contract to automatically complete the verification of the multi-level signature chain, i.e., the data packet verification.

[0090] Specifically, the root public key is read from the blockchain, parsed into an XMSS public key structure, and the XMSS verification function is called to verify the validity of the root private key's signature on the root hash value in the data packet. This verifies the first signature data in the data packet based on the root public key, yielding a fourth verification result. If the fourth verification result indicates a failure, the process terminates and an alarm is triggered.

[0091] Based on the storage address of the intermediate public key in the data packet, obtain the intermediate public key, verify the second signature data in the data packet based on the intermediate public key, and obtain the fifth verification result.

[0092] Specifically, the system dynamically requests decryption permission for the intermediate layer public key from the hardware security module of the firmware monitoring end to obtain the intermediate layer public key. It then calls the XMSS verification function to verify the validity of the intermediate layer private key's signature on the first signature data in the data packet, i.e., to verify the second signature data in the data packet based on the intermediate layer public key, thus obtaining the fifth verification result. If the fifth verification result indicates that the verification failed, the process terminates and an alarm is triggered.

[0093] Based on the storage address of the leaf layer public key in the data packet, obtain the leaf layer public key, verify the third signature data in the data packet based on the leaf layer public key, and obtain the sixth verification result.

[0094] Specifically, the leaf layer public key is read from the blockchain, and the XMSS verification function is called to verify the validity of the leaf layer private key's signature on the second signature data in the data packet. That is, the third signature data in the data packet is verified based on the leaf layer public key to obtain the sixth verification result. If the sixth verification result is that the verification fails, the process is terminated and an alarm is triggered.

[0095] If the fourth, fifth, and sixth verification results are all successful, then the data packet verification is considered successful.

[0096] It should be noted that once the data packet verification is successful, a smart contract event is triggered and recorded on the blockchain. The smart contract event includes key information such as a Coordinated Universal Time (UTC) timestamp, a unique BMC identifier, and the identity of the upgrade operator.

[0097] Related technologies rely on static rules (such as fixed-time-window upgrades) for firmware upgrades, which cannot dynamically adjust firmware upgrade strategies (such as key rotation or privilege revoke) based on real-time threats (such as quantum attack warnings), resulting in low firmware upgrade security. In this application's embodiment, if data packet verification fails, the firmware regulator is notified and the process is terminated.

[0098] To make the process of automatic data packet verification in smart contracts clearer, combined with Figure 3 The process of automatically verifying data packets for smart contracts is described. Figure 3 This is a flowchart illustrating the smart contract verification data packet provided in an embodiment of this application, as shown below. Figure 3 As shown, the process includes: the controller agent module submits the data packet to the smart contract verification interface. The smart contract automatically begins the verification of the multi-level signature chain. The root public key is read from the blockchain, and the signature validity of the root private key on the root hash value is verified. If the signature validity verification of the root private key on the root hash value fails, the process terminates and an alarm is triggered. If the signature validity verification of the root private key on the root hash value passes, the intermediate public key is read from the hardware security module of the firmware monitoring end, and the signature validity of the intermediate private key on the first signature data is verified. If the signature validity verification of the intermediate private key on the first signature data passes, the leaf public key is read from the blockchain, and the signature validity of the leaf private key on the second signature data is verified. If the signature validity verification of the intermediate private key on the first signature data fails, the process terminates and an alarm is triggered. If the signature validity verification of the leaf private key on the second signature data fails, the process terminates and an alarm is triggered.

[0099] The firmware upgrade system provided in this application embodiment achieves decentralized collaborative management by automatically executing signature data verification, alarms, and policy adjustments through smart contracts.

[0100] In some alternative implementations, the firmware user side includes a controller agent module and a host side.

[0101] The controller agent module is used to obtain multiple encrypted target upgrade firmware blocks, multiple target keys, multiple initialization vectors and multiple authentication tags corresponding to the multiple encrypted target upgrade firmware blocks from the firmware release end when the data packet verification is successful, and send the multiple encrypted target upgrade firmware blocks, multiple target keys, multiple initialization vectors and multiple authentication tags to the host end.

[0102] The controller agent module obtains multiple encrypted target upgrade firmware blocks, corresponding target keys, initialization vectors, and authentication tags from the firmware release terminal via a secure encrypted channel. The controller agent module then sends these encrypted target upgrade firmware blocks, corresponding target keys, initialization vectors, and authentication tags to the host terminal via the Host-to-BMC (H2B) channel. The H2B channel is a core technology for efficient communication between the BMC and the host in the server, primarily used for out-of-band management, firmware upgrades, and hardware status monitoring.

[0103] The host receives multiple encrypted target upgrade firmware blocks, multiple target keys corresponding to the multiple encrypted target upgrade firmware blocks, multiple initialization vectors, and multiple authentication tags sent by the controller agent module. Based on the multiple encrypted target upgrade firmware blocks, it reconstructs the target hash tree to obtain the target root hash value in the target hash tree. Based on the multiple encrypted target upgrade firmware blocks, it decrypts the multiple encrypted target upgrade firmware blocks using the multiple target keys, multiple initialization vectors, and multiple authentication tags to obtain the decrypted target upgrade firmware blocks. Finally, it sends the target root hash value and the decrypted target upgrade firmware blocks to the controller agent module.

[0104] It should be noted that the host can utilize a hardware acceleration engine to decrypt multiple encrypted target upgrade firmware blocks in parallel. This means that, based on multiple encrypted target upgrade firmware blocks, the SHA-256 algorithm is used to determine multiple first hash values ​​corresponding to these blocks, and a target hash tree is reconstructed based on these first hash values.

[0105] The controller agent module is also used to receive the target root hash value and multiple decrypted target upgrade firmware blocks, compare the target root hash value with the root hash value in the data packet, and if the comparison is successful, perform the controller firmware upgrade based on the multiple decrypted target upgrade firmware blocks.

[0106] It should be noted that if the comparison passes, the decrypted target upgrade firmware blocks are written to the BMC flash memory using the Quad Serial Peripheral Interface (QSPI). After all blocks are written, the BMC is restarted to complete the firmware upgrade. QSPI is a high-speed serial communication interface primarily used to connect flash memory or peripherals. It transmits data in parallel via four data lines, offering higher bandwidth than standard SPI and making it suitable for scenarios requiring fast data read / write speeds.

[0107] In some optional implementations, the controller agent module is also used for: If the target root hash value fails to match the root hash value in the data packet, the firmware upgrade will be stopped and an alarm will be issued.

[0108] Understandably, if the target root hash value fails to match the root hash value in the data packet, it indicates that the target upgrade firmware has been tampered with, and the firmware upgrade will be stopped immediately and an alarm will be issued.

[0109] In some alternative implementations, the controller agent module is specifically used for: During the process of writing multiple decrypted target upgrade firmware blocks into the controller flash memory, after each preset amount of data is written, the target verification is performed on the currently written preset amount of data. If the target verification passes, the process of writing multiple decrypted target upgrade firmware blocks into the controller flash memory continues.

[0110] The target verification is a 32-bit Cyclic Redundancy Check (CRC). The preset data volume is set by technical personnel and is not specifically limited here.

[0111] If the target verification fails, return to the step of performing target verification on the currently written preset amount of data.

[0112] If the number of times the target verification step for the currently written preset amount of data is executed reaches a preset threshold, and the target verification still fails, the firmware upgrade will be stopped and an alarm will be issued. The preset threshold is set by technical personnel and is not specifically limited here.

[0113] The firmware upgrade system provided in this application improves the reliability of firmware writing by performing target verification immediately after each preset amount of data is written, thus promptly detecting write errors. An automatic retry mechanism enhances the system's fault tolerance. Setting a preset threshold for the number of attempts prevents infinite loops and ensures system controllability.

[0114] In some optional implementations, the controller agent module is also used for: If the firmware upgrade of the controller based on multiple encrypted target upgrade firmware blocks fails, the steps of upgrading the controller based on multiple encrypted target upgrade firmware blocks should be re-executed.

[0115] If the number of times the firmware upgrade step based on multiple encrypted target upgrade firmware blocks is re-executed reaches a preset threshold, and the firmware upgrade still fails, a firmware upgrade failure alarm will be issued.

[0116] The firmware upgrade system provided in this application enhances system fault tolerance by setting an automatic retry mechanism. By setting a preset retry threshold, infinite loops are prevented, ensuring system controllability.

[0117] The embodiments of this application provide a firmware upgrade method, applicable to the firmware upgrade system provided in any of the above embodiments. Figure 4 This is a flowchart illustrating the firmware upgrade method provided in an embodiment of this application, as shown below. Figure 4 As shown, the firmware upgrade method includes the following process: Step S401: Based on the firmware release terminal, obtain the target upgrade firmware of the controller; perform block encryption processing on the target upgrade firmware to obtain multiple encrypted target upgrade firmware blocks; generate a hash tree based on the multiple encrypted target upgrade firmware blocks; sign the root hash value of the hash tree based on the root private key of the hash tree to generate the first signature data, and store the root private key.

[0118] Step S402: Based on the firmware monitoring terminal, the first signature data is signed using the intermediate layer private key of the hash tree to generate the second signature data, and the intermediate layer private key is stored.

[0119] Step S403: Based on the firmware user, the second signature data is signed using the leaf layer private key of the hash tree to generate the third signature data, and the leaf layer private key is stored.

[0120] Step S404: Based on the firmware release terminal, write the data packet consisting of the first signature data, the second signature data, the third signature data, and the root hash value into the blockchain.

[0121] Step S405: Based on the firmware user end, obtain data packets from the blockchain, verify the data packets, and if the verification passes, obtain multiple encrypted target upgrade firmware blocks from the firmware publisher end, and perform firmware upgrade of the controller based on the multiple encrypted target upgrade firmware blocks.

[0122] For details, please refer to the corresponding description of the firmware upgrade system mentioned above, which will not be repeated here.

[0123] The firmware upgrade method provided in this application improves the ability to resist quantum computing attacks by performing block encryption on the target firmware to be upgraded. By storing the root layer private key, intermediate layer private key, and leaf layer private key on the firmware release end, firmware monitoring end, and firmware user end respectively, decentralized storage of private keys is achieved, reducing the risk of private key leakage. Therefore, it can solve the technical problem of low security in the BMC firmware upgrade method in related technologies, and achieve the technical effect of improving the security of firmware upgrades.

[0124] This application provides a firmware upgrade method. Figure 5This is a flowchart illustrating the firmware upgrade method provided in an embodiment of this application, as shown below. Figure 5 As shown, the process includes: Firmware block encryption. For details, please refer to the previous description of obtaining the target upgrade firmware of the controller based on the firmware release terminal; and performing block encryption processing on the target upgrade firmware to obtain multiple encrypted target upgrade firmware blocks. It will not be repeated here.

[0125] Construct a hash tree. For details, please refer to the aforementioned description of generating a hash tree based on multiple encrypted target upgrade firmware blocks; it will not be repeated here.

[0126] Multi-level signature chain generation. For details, please refer to the preceding description of signing the root hash value of the hash tree using the root private key to generate the first signature data and storing the root private key; signing the first signature data using the intermediate private key of the hash tree on the firmware monitoring end to generate the second signature data and storing the intermediate private key; and signing the second signature data using the leaf private key of the hash tree on the firmware user end to generate the third signature data and storing the leaf private key. These details will not be repeated here.

[0127] Blockchain collaborative verification. For details, please refer to the aforementioned description of retrieving data packets from the blockchain based on the firmware user end and verifying the data packets; it will not be repeated here.

[0128] Firmware upgrade and rollback. For details, please refer to the aforementioned description of firmware upgrades for the controller based on multiple encrypted target upgrade firmware blocks, which will not be repeated here.

[0129] The firmware upgrade method provided in this application achieves full lifecycle security management of BMC firmware upgrades through the deep integration of block encryption, multi-level signature chains, blockchain collaborative verification, and hardware acceleration. From firmware preprocessing to anomaly rollback, each step incorporates quantum-resistant, tamper-proof, and automated strategies to ensure the reliability of the solution in scenarios with high security requirements.

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

[0131] Embodiments of this application also provide an electronic device, such as... Figure 6 As shown, it includes a processor 601 and a memory 602, in which a computer program is stored. The processor 601 is configured to run the computer program to perform the steps in any of the firmware upgrade method embodiments described above.

[0132] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the firmware upgrade method embodiments described above when running.

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

[0134] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the firmware upgrade method embodiments described above.

[0135] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the firmware upgrade method embodiments described above.

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

[0137] The firmware upgrade system, method, electronic device, storage medium, and program product provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only intended to help understand the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A firmware upgrade system, characterized in that, This includes firmware release, firmware usage, and firmware monitoring. The firmware publishing terminal is used to obtain the target upgrade firmware for the controller; The target upgrade firmware is subjected to block encryption processing to obtain multiple encrypted target upgrade firmware blocks; A hash tree is generated based on multiple encrypted target upgrade firmware blocks; The root hash value of the hash tree is signed based on the root private key of the hash tree to generate first signature data, and the root private key is stored. The firmware monitoring terminal is used to sign the first signature data using the intermediate layer private key of the hash tree, generate the second signature data, and store the intermediate layer private key. The firmware client is used to sign the second signature data using the leaf layer private key of the hash tree, generate the third signature data, and store the leaf layer private key. The firmware publishing terminal is also used to write the data packet consisting of the first signature data, the second signature data, the third signature data, and the root hash value into the blockchain; The firmware user terminal is also used to obtain the data packet from the blockchain, verify the data packet, and if the verification is successful, obtain multiple encrypted target upgrade firmware blocks from the firmware publishing terminal, and perform firmware upgrade of the controller based on the multiple encrypted target upgrade firmware blocks.

2. The system according to claim 1, characterized in that, The firmware publishing client is specifically used for: The target upgrade firmware is divided into blocks to obtain multiple target upgrade firmware blocks; Multiple target keys are generated using a hash-based message authentication code deterministic random bit generator. Multiple target upgrade firmware blocks are encrypted using multiple sets of target keys to obtain multiple encrypted first upgrade firmware blocks, wherein one set of target keys is used to encrypt one target upgrade firmware block. Obtain the initialization vector and authentication tag corresponding to the first upgrade firmware block, append the initialization vector to the head of the first upgrade firmware block, and append the authentication tag to the tail of the first upgrade firmware block to obtain the encrypted target upgrade firmware block. Among them, the initialization vectors corresponding to multiple first upgrade firmware blocks are different.

3. The system according to claim 1, characterized in that, The firmware publishing client is specifically used for: Using a secure hash algorithm, multiple target hash values ​​corresponding to the multiple encrypted target upgrade firmware blocks are determined; The plurality of target hash values ​​are used as leaf nodes of the hash tree; Following the binary tree structure, the hash values ​​corresponding to two adjacent nodes are merged layer by layer until the root hash value is generated, thus obtaining the hash tree.

4. The system according to claim 1, characterized in that, The firmware publishing client is specifically used for: The root private key is split into multiple root private key fragments, wherein the root private key is generated based on a digital signature algorithm resistant to quantum computing attacks; The first number of root layer private key fragments from the multiple root layer private key fragments are stored in multiple hardware security modules of the firmware release terminal respectively; The remaining root private key fragments, excluding the first number of root private key fragments, are encrypted and stored in the blockchain node.

5. The system according to claim 1, characterized in that, The firmware monitoring terminal is specifically used for: The intermediate layer private key is split into multiple intermediate layer private key fragments, wherein the intermediate layer private key is derived from the root layer private key; The second number of intermediate layer private key fragments are stored in multiple hardware security modules of the firmware monitoring terminal. The remaining intermediate layer private key fragments, excluding the second number of intermediate layer private key fragments, are encrypted and stored in a cross-regional blockchain node.

6. The system according to claim 1, characterized in that, The firmware user terminal is specifically used for: The leaf layer private key is split into multiple leaf layer private key fragments, wherein the leaf layer private key is derived from the intermediate layer private key; The third number of leaf layer private key fragments from the multiple leaf layer private key fragments are stored in multiple hardware security modules of the firmware user terminal respectively; The remaining leaf layer private key fragments, excluding the third number of leaf layer private key fragments, are encrypted and stored in the blockchain node.

7. The system according to claim 1, characterized in that, The firmware publishing terminal is also used to obtain the root public key corresponding to the root private key and store the root public key in the smart contract of the blockchain; The firmware monitoring terminal is also used to obtain the intermediate layer public key corresponding to the intermediate layer private key, encrypt the intermediate layer public key and store it in the hardware security module of the firmware monitoring terminal; The firmware client is also used to obtain the leaf layer public key corresponding to the leaf layer private key and store the leaf layer public key in the smart contract of the blockchain.

8. The system according to claim 7, characterized in that, The firmware publishing terminal is also used to verify the first signature data using the root public key after generating the first signature data, and obtain a first verification result; The firmware monitoring terminal is also used to verify the second signature data using the intermediate layer public key after the second signature data is generated, and to obtain a second verification result; The firmware user terminal is also used to verify the third signature data using the leaf layer public key after the third signature data is generated, and to obtain a third verification result; Specifically, the firmware publishing terminal is used to write a data packet consisting of the first signature data, the second signature data, the third signature data, the root hash value, the storage address of the root public key, the storage address of the intermediate public key, and the storage address of the leaf public key into the blockchain when the first verification result, the second verification result, and the third verification result are all verified.

9. The system according to claim 8, characterized in that, The firmware user includes a controller proxy module, which is used for: The data packet is obtained from the blockchain. Using a smart contract, the root public key is obtained based on the storage address of the root public key in the data packet. The first signature data in the data packet is verified based on the root public key to obtain a fourth verification result. Based on the storage address of the intermediate layer public key in the data packet, the intermediate layer public key is obtained, and the second signature data in the data packet is verified based on the intermediate layer public key to obtain the fifth verification result; Based on the storage address of the leaf layer public key in the data packet, the leaf layer public key is obtained, and the third signature data in the data packet is verified based on the leaf layer public key to obtain the sixth verification result; If the fourth verification result, the fifth verification result, and the sixth verification result are all verified as passed, then the data packet verification is determined to be successful.

10. The system according to claim 1, characterized in that, The firmware user end includes a controller agent module and a host end; The controller proxy module is used to obtain multiple encrypted target upgrade firmware blocks, multiple target keys, multiple initialization vectors and multiple authentication tags corresponding to the multiple encrypted target upgrade firmware blocks from the firmware publishing end when the data packet verification is successful, and send the multiple encrypted target upgrade firmware blocks, multiple target keys, multiple initialization vectors and multiple authentication tags to the host end. The host terminal is used to receive the multiple encrypted target upgrade firmware blocks, multiple target keys corresponding to the multiple encrypted target upgrade firmware blocks, multiple initialization vectors and multiple authentication tags sent by the controller agent module, and reconstruct the target hash tree based on the multiple encrypted target upgrade firmware blocks to obtain the target root hash value in the target hash tree. Based on the multiple target keys, multiple initialization vectors and multiple authentication tags corresponding to the multiple encrypted target upgrade firmware blocks, the multiple encrypted target upgrade firmware blocks are decrypted to obtain multiple decrypted target upgrade firmware blocks; the target root hash value and the multiple decrypted target upgrade firmware blocks are sent to the controller agent module; The controller agent module is also used to receive the target root hash value and the decrypted multiple target upgrade firmware blocks, compare the target root hash value with the root hash value in the data packet, and if the comparison is successful, perform a firmware upgrade of the controller based on the decrypted multiple target upgrade firmware blocks.

11. The system according to claim 10, characterized in that, The controller agent module is also used for: If the target root hash value and the root hash value in the data packet fail to match, the firmware upgrade will be stopped and an alarm will be issued.

12. A firmware upgrade method, characterized in that, The method includes: Based on the firmware release terminal, the target upgrade firmware of the controller is obtained; the target upgrade firmware is divided into blocks for encryption to obtain multiple encrypted target upgrade firmware blocks; a hash tree is generated based on the multiple encrypted target upgrade firmware blocks; the root hash value of the hash tree is signed based on the root private key of the hash tree to generate first signature data, and the root private key is stored. Based on the firmware monitoring terminal, the first signature data is signed using the intermediate layer private key of the hash tree to generate the second signature data, and the intermediate layer private key is stored. Based on the firmware user end, the second signature data is signed using the leaf layer private key of the hash tree to generate the third signature data, and the leaf layer private key is stored. Based on the firmware release terminal, the data packet consisting of the first signature data, the second signature data, the third signature data, and the root hash value is written into the blockchain; Based on the firmware user end, the data packet is obtained from the blockchain and verified. If the verification passes, multiple encrypted target upgrade firmware blocks are obtained from the firmware publishing end, and the controller firmware is upgraded based on the multiple encrypted target upgrade firmware blocks.

13. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the firmware upgrade method as described in claim 12 when executing the computer program.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the firmware upgrade method as described in claim 12.

15. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the firmware upgrade method as described in claim 12.

Images