Method and system for firmware encrypted loading and rollback protection of a storage control chip

Abstract

The application relates to the technical field of storage control chips, and discloses a firmware encryption loading and rollback protection method and system of a storage control chip. The method comprises the following steps: obtaining a data packet of a control program to be loaded, extracting a program trusted inventory vector, and deriving a loading key of each program segment; obtaining a count state of a one-time programmable memory and physical state information of a nonvolatile storage medium, generating a candidate version state graph, and performing constraint arbitration to determine an allowed loading version set and a lowest trusted safe version; performing authentication decryption on the program segments in the allowed loading version set, generating an authenticated segment directed acyclic graph, and generating a control program startup topology sequence; after loading is completed, the lowest trusted safe version is checked; if the check is passed, a two-phase commit is performed; otherwise, rollback blocking or degraded startup is performed; and the application improves the firmware security protection capability and system startup reliability of the storage control chip in a complex physical environment.

Description

Technical Field

[0001] This application relates to the field of storage control chip technology, and in particular to a method and system for firmware encryption loading and rollback protection of storage control chips. Background Technology

[0002] As a core component of solid-state drives, embedded storage devices, and industrial control systems, the security and reliability of the firmware of storage control chips directly affect the stable operation of the entire system. With increasingly sophisticated attack methods, the security threats facing firmware have evolved from traditional tampering attacks to more covert version rollback attacks. Attackers gain control of the system by downgrading the firmware to an older version with known vulnerabilities, bypassing the security mechanisms patched in the new version.

[0003] Existing firmware protection schemes often focus on single-dimensional protection, such as verifying firmware integrity through digital signatures or relying on version number comparison to prevent rollback. However, these schemes reveal significant shortcomings in actual deployment: non-volatile storage media undergoes physical wear and tear after long-term write and erase operations, potentially rendering the storage area recording version information unreliable; during abnormal power outages, the firmware copy being updated may be incomplete, and existing schemes struggle to select a trustworthy and usable version from multiple inconsistent copies; firmware is typically stored in multiple copies to improve reliability, but different copies may have inconsistent versions due to differences in write times, and simple version number checks cannot distinguish which copy has truly undergone complete verification. A deeper problem is that the irreversible state recording medium upon which the rollback prevention mechanism relies may itself be worn out. When the storage unit recording the "highest loaded version" is damaged, attackers can exploit this physical defect to mislead the system into believing that a new version has never been loaded, thus accepting rollback requests for the old version. At the same time, the firmware encryption key needs to be deeply bound to the device hardware to prevent the firmware from being copied to other devices, but it must also adapt to physical changes in different storage locations on the same device, such as bad block remapping. Otherwise, backup firmware stored in other locations will not be able to be decrypted due to key mismatch.

[0004] Therefore, in a complex environment where storage media is constantly aging, power outages are always present, and multiple copies have inconsistent states, how to ensure that version upgrades cannot be downgraded, dynamically select the most reliable loading path based on the storage health status, and ensure that encryption keys are both bound to the device and adaptable to changes in storage location has become a pressing technical challenge in the field of secure firmware loading for storage control chips. Summary of the Invention

[0005] To address the aforementioned technical issues, this application provides a method and system for firmware encryption loading and rollback protection of a storage control chip. This method and system achieve one-way firmware version upgrade protection and intelligent loading path selection, effectively preventing firmware rollback attacks and improving the firmware security protection capability and system startup reliability of the storage control chip in complex physical environments.

[0006] In a first aspect, this application provides a firmware encryption loading and rollback protection method for a storage control chip, the method comprising: Step S1: Obtain the data packet of the control program to be loaded, extract the trusted manifest vector of the program, obtain the program security version number and physical block group information, and derive the loading key of each segment of the control program to be loaded by combining the hardware root key and device identifier. Step S2: Obtain the counting state of the one-time programmable memory and the physical state information of the non-volatile storage medium, construct a constraint tensor containing version wear and location information, generate a candidate version state diagram and perform constraint adjudication, and determine the set of allowed loading versions and the minimum trusted security version; Step S3: Use the loading key to perform authentication and decryption on program segments within the set of allowed loading versions, generate an authentication segmented directed acyclic graph, store the mapping initialization dependencies and channel reset order according to the authentication segmented directed acyclic graph, and generate a control program startup topology sequence; Step S4: After the topology sequence is loaded according to the control program, the lowest trusted security version is verified. If the verification passes, a two-phase commit of one-time programmable memory pre-commit and non-volatile storage medium mirror confirmation is performed; otherwise, a rollback blocking or downgrade startup is performed.

[0007] Secondly, this application provides a firmware encryption loading and rollback protection system for a storage control chip, the system comprising: The acquisition module is used to acquire the data packet of the control program to be loaded, extract the trusted manifest vector of the program, obtain the program security version number and physical block group information, and derive the loading key of each segment of the control program to be loaded by combining the hardware root key and device identifier. The determination module is used to obtain the counting state of the one-time programmable memory and the physical state information of the non-volatile storage medium, construct a constraint tensor containing version wear and location information, generate a candidate version state diagram and perform constraint adjudication, and determine the set of allowed loading versions and the minimum trusted security version; The generation module is used to perform authentication and decryption on program segments within the set of allowed loadable versions using the loading key, generate a directed acyclic graph of authentication segments, store mapping initialization dependencies and channel reset order based on the directed acyclic graph of authentication segments, and generate a control program startup topology sequence. The verification module is used to verify the lowest trusted security version after the topology sequence is loaded according to the control program. If the verification passes, a two-phase commit of one-time programmable memory pre-commit and non-volatile storage medium mirror confirmation is performed; otherwise, a rollback blocking or degraded startup is performed.

[0008] Compared with the prior art, the beneficial effects of the present invention are at least as follows: This application generates independent loading keys for each program segment by inputting the hardware root key, device identifier, program security version number, physical block group information, and error correction margin level into the key derivation function. This achieves deep binding between the key and device identity, physical location, and media health status, effectively resisting firmware cloning attacks and avoiding the predicament of backup firmware being unable to be decrypted due to bad block remapping.

[0009] This application determines the minimum allowed version number by reading the bit count of the one-time programmable memory, and constructs a constraint tensor to generate a candidate version state diagram by combining the mirror version copy, bad block table, block erase / write count, power failure log and error correction margin. The constraint decision is executed by comprehensively considering the version monotonic weight, multi-copy consistency weight and state transition weight. This ensures both the unidirectionality and non-reversibility of version upgrades, and can dynamically select the optimal loading path based on the actual physical health of the storage medium.

[0010] This application utilizes a two-phase commit mechanism—pre-commit of one-time programmable memory and mirror confirmation of non-volatile storage media—to ensure the irreversibility of version records by leveraging the physical unidirectional nature of the commit mechanism. Combined with differentiated handling strategies for security-related and media-related failures and dynamic updates to the bad block blacklist, it effectively prevents firmware rollback attacks and enhances the firmware security protection capabilities and system startup reliability of the storage control chip in complex physical environments. Attached Figure Description

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

[0012] Figure 1 This is a flowchart of the firmware encryption loading and rollback protection method for the storage control chip in this application embodiment; Figure 2 This is a flowchart illustrating the steps for determining the allowed set of versions to be loaded and the minimum trusted security version in an embodiment of this application. Figure 3 This is a flowchart illustrating the implementation of step S4 in an embodiment of this application; Figure 4This is a schematic diagram of the firmware encryption loading and rollback protection system for the storage control chip in an embodiment of this application. Detailed Implementation

[0013] This application provides a firmware encryption loading and rollback protection method and system for a storage control chip. The terms "first," "second," "third," "fourth," etc. (if present) in the specification, claims, and accompanying drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in a sequence other than that illustrated or described herein. Furthermore, the terms "comprising" or "having" and any variations thereof are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or device that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or devices.

[0014] For ease of understanding, the specific process of the embodiments of this application is described below. Please refer to [link / reference]. Figure 1 The firmware encryption loading and rollback protection method for a storage control chip in this application embodiment includes: Step S1: Obtain the data packet of the control program to be loaded, extract the trusted manifest vector of the program, obtain the program security version number and physical block group information, and derive the loading key of each segment of the control program to be loaded by combining the hardware root key and device identifier.

[0015] Step S1 includes: when the storage control chip starts up, acquiring the data packet of the control program to be loaded, parsing the program attributes and storage area information in the data packet, generating a trusted program manifest vector, which also contains the expected hash value of each program segment; extracting the program security version number and the physical block group information of the control program segment to be loaded from the trusted program manifest vector; acquiring the hardware root key generated by the physical non-cloning function, the device identifier of the storage controller, and the error correction margin level of the non-volatile storage medium; inputting the program security version number, physical block group information, hardware root key, device identifier, and error correction margin level into the key derivation function to calculate the loading key for each program segment of the control program to be loaded.

[0016] Specifically, when the storage control chip boots up, it first reads the data packet of the control program to be loaded from the predetermined firmware storage area of ​​the non-volatile storage medium. This data packet is stored in the flash array in segment form. The read data packet is parsed to extract program attributes and storage area information. The program attributes include the program version number, build timestamp, segment length, segment identifier, and expected hash value of each segment. The storage area information includes the starting physical block address, number of occupied blocks, channel number, and plane number of each segment in the flash memory. The so-called program trust list vector is a data set formed by structuring the above program attributes and storage area information according to segment indexes. Its function is to provide a benchmark reference value for subsequent hash value comparison, a physical location factor for key derivation, and a topological basis for dependency resolution. Each entry in this vector corresponds to a program segment and includes a segment identifier, type tag, expected hash value, physical block group identifier, erase count benchmark value, and dependency tag. The expected hash value is a digest value calculated using a secure hash algorithm on the plaintext segment during the firmware compilation stage. After subsequent decryption, the hash value will be recalculated and compared with the expected hash value to verify integrity.

[0017] After the program's trusted manifest vector is generated, the program security version number and the physical block group information corresponding to each program segment are extracted from it. The program security version number, also known as the aforementioned program version number, serves as the security adjudicator in this application. It is encoded using an incrementing integer sequence, increasing after each security update, and is used to identify the firmware's security iteration level and participate in anti-rollback decisions. The physical block group information consists of group numbers and block address ranges for physical blocks in flash memory with similar erase / write characteristics and access latency, divided by channel and plane combinations. Simultaneously, the hardware root key is obtained through a physically unclonable function circuit. A physically unclonable function is a hardware security primitive that uses random process deviations during chip manufacturing to generate a response value uniquely bound to the physical characteristics of each chip. This response value, stabilized by error correction and post-processing algorithms, serves as the hardware root key, possessing unclonability and unpredictability. This hardware root key is not stored in plaintext in any readable memory but is stored in a security key register inside the chip, accessible only by the cryptographic engine and not directly readable by external interfaces.

[0018] The device identifier is read from a dedicated identity register inside the chip. This identifier is a globally unique 64-bit or 128-bit code that cannot be modified after being written during chip manufacturing or initialization. The error correction margin level of the non-volatile storage medium also needs to be obtained. The error correction margin level is a quantitative assessment of the overall health of the flash memory. It is obtained by performing error correction decoding sampling on representative data pages distributed across different channels and planes, counting the actual number of error-corrected bits, comparing it with the maximum error correction capability of the error correction code, and classifying it to characterize the current data retention capability of the storage medium. The specific classification method is as follows: First, error correction decoding sampling is performed on representative data pages distributed in different channels and plane combinations. The actual number of corrected error bits for each sampled page is recorded, and the largest actual corrected error bit value among all sampled pages is taken as the actual error correction requirement value of the current storage medium. Then, the difference between this actual error correction requirement value and the maximum number of error correction bits of the error correction code is calculated to obtain the error correction margin bits. The error correction margin bits are divided by the maximum number of error correction bits to obtain the normalized margin ratio. The level is classified according to the range in which the normalized margin ratio falls. A normalized margin ratio greater than or equal to the first threshold is defined as high level, a normalized margin ratio less than the first threshold but greater than or equal to the second threshold is defined as medium level, and a normalized margin ratio less than the second threshold is defined as low level. The first and second thresholds are pre-configured by the chip manufacturer and embedded in the chip's one-time programmable memory according to the type of flash memory chip and its rated erase / write life. This level value is encoded as an enumerated integer during key derivation.

[0019] The key derivation function employs either a hash-based message authentication code or a block cipher-based key derivation function. Essentially a one-way function, it exhibits an avalanche effect. The hardware root key, device identifier, program security version number, physical block group information, and error correction margin level are encoded into derivation context information according to a predetermined format and then input into the key derivation function. In practice, the hardware root key is first loaded into the cryptographic engine's key register as the master key. Then, the encoded derivation context information is concatenated with a fixed-length derivation destination identifier and input into the key derivation function for multi-round iterative computation. The encoding of the derivation context information follows a fixed field position rule to avoid field confusion. For example, the device identifier occupies the first eight bytes, the program security version number occupies bytes nine to twelve, the physical block group number occupies bytes thirteen to sixteen, and the error correction margin level occupies the seventeenth byte.

[0020] It should be noted that the physical block group information extracted from the program's trusted manifest vector includes the group number and its corresponding channel, plane, and block address range. However, when inputting the key derivation function, only the physical block group number, which serves as a unique identifier, is encoded and used in the derivation calculation. This physical block group number is a numerical identifier assigned internally by the flash memory controller to each physical block group with the same channel and plane combination. There is a one-to-one mapping relationship between it and the specific block address range, which is maintained by the block group management table of the flash memory translation layer. The derivation factor used during encryption is this physical block group number. During decryption, the system queries the block group management table based on the current actual storage location to obtain the corresponding physical block group number. This ensures that even if the block address range changes due to bad block remapping, as long as the remapped physical blocks belong to the same channel and plane combination governed by the same physical block group number, the derivation key remains unchanged. If the remapping spans different physical block group numbers, the key changes accordingly, requiring firmware re-encryption and deployment.

[0021] The key derivation function internally employs multiple rounds of nonlinear transformation and diffusion operations. After a sufficient number of iterations, it outputs a fixed-length 256-bit derived value, which serves as the loading key for that program segment. Because each program segment has a different physical block group number, even if other input parameters are identical, the loading keys derived from different segments are independent. This mechanism ensures a deep binding between the loading key and the physical storage location. Even if an attacker obtains the loading key for a segment, it cannot be used to decrypt other segments stored in other physical block groups. Simultaneously, since the error correction margin level is incorporated into the derivation factor, when the storage medium health declines to a certain level, the derivation parameters change accordingly, triggering firmware redeployment or migration processes to prevent the continued use of critical firmware in areas nearing failure. Through this method, a one-to-one corresponding loading key is generated for each program segment within the loading version set. In practical implementation, if the physical block group of a program segment changes due to bad block remapping, the physical block group information is updated to the new block group number when deriving the loading key, thus ensuring that the remapped segment can still be correctly decrypted. After key derivation is completed, the resulting loaded keys are temporarily stored in a secure buffer for use in subsequent authentication and decryption steps.

[0022] Through the specific implementation of step S1 above, this application achieves triple security protection of device binding, location binding, and health status binding for firmware segment loading keys. The key is bound to the device identifier and the hardware root key, effectively resisting cloning attacks where the firmware is copied entirely to other devices for execution. The key is bound to physical block group information, ensuring that even if the firmware storage location is moved due to bad block remapping, the key derivation parameters are updated accordingly, avoiding the predicament of backup firmware being unable to decrypt due to address changes. Error correction margin levels are incorporated into the key derivation process, linking key distribution with media health. Through the comprehensive application of the above technical means, this application constructs a comprehensive key protection system for the firmware loading process, encompassing device identity, physical location, and media health status, significantly improving the firmware security protection capabilities of storage control chips in complex physical environments.

[0023] Step S2: Obtain the counting state of the one-time programmable memory and the physical state information of the non-volatile storage medium, construct a constraint tensor containing version wear and location information, generate a candidate version state diagram and perform constraint adjudication, and determine the set of allowed loading versions and the minimum trusted security version.

[0024] The process of generating a candidate version state diagram in step S2 includes: reading the bit count of the one-time programmable memory, determining the minimum allowed version number based on the bit count, and deriving a startup random variable through a physically non-cloning function; obtaining the mirror version copy, bad block table, block erase / write count, power-down log, and error correction margin in the non-volatile storage medium, and constructing a constraint tensor by combining the minimum allowed version number and the startup random variable; establishing program copy nodes at different physical locations based on the mirror version copy and bad block table in the constraint tensor, and marking nodes with version numbers lower than the minimum allowed version number as unloadable states in the constraint tensor; calculating erase / write degradation penalties based on the block erase / write count, calculating power-down write-off penalties based on the power-down log, assigning state transition probabilities to each program copy node, and adjusting the state transition probabilities using the startup random variable as a randomization factor to generate the candidate version state diagram.

[0025] Specifically, to select a legitimate and reliable loading target from multiple firmware copies stored separately on non-volatile storage media, the version information, physical location information, and health status information of each copy need to be integrated into a unified data structure. Based on this structure, a state diagram model reflecting the upgrade paths and priority relationships between copies is constructed, providing a quantifiable decision-making basis for subsequent constraint adjudication. The following detailed explanation of the candidate version state diagram generation process, combined with specific implementation methods, illustrates this process.

[0026] When generating the candidate version state diagram, the bit count of the one-time programmable memory (IPM) is read first. IPM is a storage device where each bit cell can only transition from the initial state to the programmed state once, and its state transition is irreversible. This physical characteristic is used to implement an anti-rollback counting function. The bit count is obtained by counting the number of programmed bits, and this count value is directly mapped to the lowest version number currently allowed to be loaded by the system. Any firmware copy with a version number lower than this lowest allowed version number is considered illegal and cannot be loaded. Simultaneously, a startup random value is derived through a physically non-cloning function. This startup random value is a randomized value obtained by debiasing and hashing the original response of the physically non-cloning function. Specifically, the physically non-cloning function generates an original response bit string based on the power-on state of the static random access memory (SRAM) cell. Since this original response may have bit bias, the von Neumann debiasing algorithm is first used to extract consecutive zero-one bit pairs as valid bits and discard zero-zero or one-one pairs. Then, the debiased bit string is input together with the current timestamp into a secure hash function for hashing, and a fixed-length hash value is output as the startup random value. This startup random variable is used to introduce a random factor in subsequent state transition probability calculations, preventing attackers from speculating on the priority of each replica by observing system loading behavior.

[0027] Subsequently, the mirror version copies, bad block table, block erase / write counts, power-loss logs, and error correction margins are obtained from the non-volatile storage medium. Mirror version copies refer to multiple backups of the same firmware version stored in different physical locations on the storage medium, each containing complete firmware content and its metadata. The bad block table records the addresses of all physical blocks marked as unreliable; these blocks cannot guarantee data reliability due to erase / write wear, read / write interference, or manufacturing defects. The block erase / write count reflects the total number of erase operations each physical block has undergone since its inception and is a key indicator for assessing the remaining lifespan of a physical block. The power-loss log records abnormal power-loss events that occurred during historical operation and the range of physical block addresses they affected. The error correction margin is the difference between the maximum error correction capability of the error correction code and the actual number of error bits corrected, reflecting the reliability margin of the data pages. This information, along with the minimum allowed version number and the startup random variable, is integrated into a constraint tensor. The constraint tensor is a multidimensional data structure with dimensions including version, replica, physical location, and state. The version dimension records the version number of each firmware replica. The replica dimension distinguishes different physical backups of the same version. The physical location dimension records the channel number, plane number, and physical block address range of the replica. The state dimension records the erase / write count statistics, error correction margin statistics, and power loss risk markers for each replica.

[0028] After the constraint tensor is constructed, program replica nodes at different physical locations are established based on the mirror version information within it. Each node corresponds to an accessible firmware backup copy. Simultaneously, nodes with version numbers lower than the minimum allowed version number are marked as unloadable in the constraint tensor. These nodes do not participate in subsequent adjudication processes, fundamentally preventing the possibility of versions below the safety threshold being loaded. Erasure degradation penalties are calculated based on the number of block erases / writes. These penalties quantify the negative impact of physical wear on firmware reliability. The calculation method involves obtaining the number of erases / writes for the physical blocks corresponding to each program replica node, performing normalization to obtain the erase / write ratio. The number of block erases / writes obtained here refers to the current cumulative number of erases for each physical block read in real-time from the flash memory conversion layer. The erase count baseline value included in the program trust list vector in step S1 is a snapshot of the initial erase count of each physical block recorded during firmware deployment. When calculating the erase / write degradation penalty in this step, the current cumulative erase count is subtracted from the corresponding erase count baseline value to obtain the net erase count increment experienced by the firmware copy since deployment. This net erase count increment is then normalized to obtain the erase / write ratio. Using the net erase count increment instead of the absolute cumulative count is to eliminate the interference of historical wear of the physical block before firmware deployment on the reliability assessment of the current firmware copy, ensuring that the erase / write degradation penalty truly reflects the degree of wear experienced by the current firmware copy during storage. If the erase count baseline value for a certain physical block is not recorded in the program trust list vector, the initial record value of that physical block at the time of its first write, stored in the flash memory conversion layer, is used as the baseline value. After obtaining the erase / write ratio, it is mapped to the erase / write degradation penalty value according to the range of the ratio. The mapping rule adopts a three-segment approach: when the write / erase ratio is less than or equal to the healthy period boundary threshold, the penalty is zero; when the write / erase ratio is greater than the healthy period boundary threshold but less than or equal to the high-risk period boundary threshold, the penalty increases linearly with the write / erase ratio; when the write / erase ratio is greater than the high-risk period boundary threshold, the penalty increases exponentially.

[0029] The power outage write penalty is calculated based on the power outage log. The power outage write penalty is used to quantify the potential risk to data integrity of historical abnormal power outage events. The calculation method is to query whether the physical block address of each program replica node is within the affected range recorded in the power outage log. If it is not affected, the penalty is zero. If it is affected, a base penalty value is assigned according to the type of operation being executed at the time of the power outage, and then multiplied by a time decay coefficient to obtain the final penalty value. The closer the time of the power outage event is to the present, the higher the penalty. The further away the time is and the more normal the replica is in subsequent startup, the more the penalty gradually decreases.

[0030] The state transition probability is assigned to each program replica node based on the erase / write degradation penalty and the power-loss write penalty. Specifically, the state transition probability refers to the priority of selecting the target replica when upgrading from the currently running firmware version to the firmware replica corresponding to another version node in the candidate version state diagram. The higher the probability value, the greater the possibility that the upgrade path will be selected.

[0031] When allocating state transition probabilities, firstly, a directed edge is established between any two nodes with different versions in the candidate version state graph, with the direction pointing from the node with the lower version number to the node with the higher version number, indicating that a one-way upgrade from a lower version to a higher version is allowed. Then, the comprehensive reliability score of the target node is calculated on each directed edge. This score is jointly determined by the erase / write degradation penalty and the power-loss / split write penalty of the target node. The lower the erase / write degradation penalty and the lower the power-loss / split write penalty, the higher the reliability score of the node. Subsequently, the reliability score is converted into a state transition probability. In the process of converting the reliability score into a state transition probability, the startup random variable is first obtained as a randomization seed to generate a random perturbation value that corresponds one-to-one with each target node. This random perturbation value is superimposed on the reliability score of each target node to obtain the perturbed score. Then, the natural exponent is taken for each perturbed score to obtain the corresponding positive weight value. Finally, the positive weight value of each target node is divided by the sum of the positive weight values ​​of all target nodes to obtain the adjusted state transition probability corresponding to each target node. Using the above method, target nodes with higher reliability scores still obtain a larger state transition probability. However, nodes with similar scores will have unpredictable probability differences due to the superposition of random disturbances, and the sum of all transition probabilities originating from the same source node will be automatically normalized to one.

[0032] After converting the reliability score into state transition probabilities, the calculated state transition probabilities are assigned to the corresponding directed edges. Each directed edge points from a source node with a lower version number to a target node with a higher version number, and the weight of this directed edge is the state transition probability of the target node relative to the source node. All directed edges in the candidate version state graph are traversed, and the state transition probabilities are assigned sequentially, ensuring that each node obtains a set of incoming edge probabilities from lower version nodes and a set of outgoing edge probabilities from higher version nodes. At this point, the candidate version state graph is complete. This graph contains a set of nodes, a set of directed edges, and a set of state transition probabilities on the edges. Each node represents a loadable firmware copy, and each directed edge represents a legitimate upgrade path from a lower version to a higher version. The probability values ​​on the edges quantify the priority of selecting that upgrade path. This candidate version state graph serves as input data for constraint adjudication, providing a basis for subsequent decisions regarding the set of allowed loadable versions and the minimum trusted security version.

[0033] In step S2, determining the allowed version set and the minimum trusted security version includes: assigning a version monotonic weight to each node based on the relationship between the version number of each node in the candidate version state graph and the minimum allowed version number determined by the bit count; assigning a multi-replica consistency weight to each node based on the consistency of the hash values ​​of the mirror version replicas corresponding to the same version in each replica node; assigning a state transition weight to each node based on the sum of the incoming edge probabilities of each node in the state transition probability; obtaining a positive score by weighted summing of the version monotonic weight, multi-replica consistency weight, and state transition weight; obtaining a negative penalty by adding the erase / write degradation penalty and the power-loss write / flash penalty; obtaining a comprehensive trust score for each node based on the positive score and the negative penalty; adding the version corresponding to the node whose comprehensive trust score is greater than a preset score threshold to the allowed version set, and determining the version with the smallest version number in the allowed version set as the minimum trusted security version.

[0034] Specifically, after generating the candidate version state diagram, in order to select a safe and reliable loading target from multiple firmware copies, it is necessary to perform multi-dimensional quantitative evaluation of each node in the state diagram, and to perform constraint adjudication by comprehensively considering factors such as version legality, copy consistency and physical health, so as to determine the range of versions allowed to be loaded and the minimum trusted and safe version.

[0035] like Figure 2 The flowchart shown illustrates the steps for determining the set of allowed loaded versions and the minimum trusted security version. During constraint adjudication, each node is first assigned a version monotonic weight based on the relationship between its version number in the candidate version state diagram and the minimum allowed version number determined by the one-time programmable memory bit count. This version monotonic weight quantifies the legality of each firmware version under anti-rollback constraints. The allocation principle is as follows: nodes with version numbers higher than the minimum allowed version number have their weight increased incrementally with the version number difference, reflecting the security gain from version upgrades; nodes with version numbers lower than the minimum allowed version number have a weight of zero and are directly excluded, ensuring that any version below the security threshold cannot pass the adjudication.

[0036] Meanwhile, based on the consistency of hash values ​​of the mirror version replicas corresponding to the same version on each replica node, a multi-replica consistency weight is assigned to each node. The multi-replica consistency weight is used to quantify the degree of content consistency between replicas of the same firmware version in different physical storage locations. The allocation principle is as follows: for multiple replicas of the same version, the hash values ​​in the metadata of each replica are extracted and cross-compared. If all are consistent, the multi-replica consistency weight is set to the highest value, indicating that all replicas of this version have been fully verified and have high credibility. If some replica hash values ​​are inconsistent with others, the weight value is linearly reduced according to the proportion of consistent replicas. The higher the proportion of inconsistency, the lower the weight, in order to reflect the risk of data corruption or tampering between replicas.

[0037] Furthermore, state transition weights are assigned to each node based on the sum of the incoming edge probabilities of each node in the candidate version state graph. The sum of incoming edge probabilities refers to the cumulative sum of the state transition probabilities of all directed edges from nodes with lower version numbers to that node in the candidate version state graph. This cumulative sum reflects the overall priority of upgrading from all lower version nodes to that node. A node with a higher sum of incoming edge probabilities means that the upgrade tendency from various lower version paths to that node is stronger, and the greater the possibility of being selected first in the upgrade path, thus obtaining a higher state transition weight.

[0038] After allocating the three positive weights, the version monotonicity weight, multi-replica consistency weight, and state transition weight are weighted and summed to obtain the positive score. Before the weighted summation, the version monotonicity weight, multi-replica consistency weight, and state transition weight are normalized to ensure that the data of each dimension are uniformly mapped to the same dimensional range, avoiding the dominance of a single dimension in the scoring result due to differences in the numerical range of different dimensions. The normalization process uses a linear mapping method, mapping the original value of each dimension to the range of zero to one. The mapped values ​​retain the relative magnitude relationship between the original data and have cross-dimensional comparability. After normalization, each dimension is multiplied by its corresponding weight coefficient. The version monotonicity weight coefficient is set to the highest to ensure that the anti-rollback constraint plays a dominant role in the adjudication; the multi-replica consistency weight coefficient is the second highest to ensure the reliability of version selection in multi-replica scenarios; the state transition weight coefficient is adjusted according to the actual application scenario. When the system has high requirements for the predictability and stability of the upgrade path, the coefficient is appropriately increased, and vice versa.

[0039] The negative penalty is obtained by weighted summation of the erase / write degradation penalty and the power-loss write-splitting penalty. Before calculating the negative penalty, both the erase / write degradation penalty and the power-loss write-splitting penalty are normalized to unify their dimensions before being multiplied by their respective penalty coefficients. The erase / write degradation penalty coefficient and the power-loss write-splitting penalty coefficient are dynamically adjusted according to the current health status of the storage medium. The more severe the medium wear, the larger the erase / write degradation penalty coefficient; the more recent the power-loss event, the larger the power-loss write-splitting penalty coefficient, in order to strengthen the influence of physical health on loading decisions.

[0040] The comprehensive trustworthiness score for each node is obtained by subtracting the normalized and weighted negative penalty from the normalized and weighted positive score. This score comprehensively reflects the node's overall performance across three positive dimensions (version legitimacy, replica consistency, and upgrade path priority) and two negative dimensions (physical wear and historical risk). Versions corresponding to nodes with a comprehensive trustworthiness score greater than a preset threshold are added to the allowed-load version set. Each version in this set must have at least one replica that has passed the comprehensive evaluation and meets all security constraints. Finally, the version with the lowest version number in the allowed-load version set is determined as the minimum trusted and secure version. This version serves as the baseline version for subsequent two-phase commits and also as the minimum version limit for rollback protection; any firmware version lower than this will be directly prohibited from loading during subsequent boots.

[0041] Through the aforementioned constraint adjudication process, this application achieves multi-dimensional quantitative screening and anti-rollback protection for firmware versions. By assigning the highest priority to the version monotonic weight in the comprehensive credibility score, the unidirectionality and irreversibility of version upgrades are ensured; by incorporating multi-replica consistency weights, the reliability of version selection in multi-replica scenarios is improved; by introducing the sum of incoming edge probabilities as state transition weights, the convergence priority of nodes in the upgrade path participates in the adjudication, enhancing the path rationality of loading decisions; by introducing erase / write degradation penalties and power-loss write penalties, loading decisions can be dynamically adjusted according to the actual physical health of the storage medium, thereby maximizing the system boot success rate while ensuring security.

[0042] Step S3: Use the loading key to perform authentication and decryption on program segments within the allowed loading version set, generate an authentication segmented directed acyclic graph, store the mapping initialization dependencies and channel reset sequence based on the authentication segmented directed acyclic graph, and generate the control program startup topology sequence.

[0043] In step S3, generating the authentication segmented directed acyclic graph includes: using the loading key to decrypt program segments within the allowed loading version set to obtain decrypted segments, and calculating the hash value of the decrypted segments; comparing the hash value with the expected hash value in the program trusted list vector, extracting the physical block number corresponding to the program segment when the comparison matches, and determining the loading order based on the dependency relationship between each program segment; and constructing the authentication segmented directed acyclic graph based on the hash value, physical block number, and loading order.

[0044] Specifically, after determining the allowed version range and the minimum trusted security version, in order to securely load these firmware segments into memory and ensure that each segment is initialized in the correct order, each segment within the allowed version set needs to be decrypted and verified. A unified loading and execution sequence is then arranged based on the dependencies between segments and hardware initialization constraints. The following detailed explanation of the authentication, decryption, and startup topology sequence generation process, in conjunction with specific implementation methods, provides a detailed description.

[0045] When generating the directed acyclic graph of authentication segments, the loading keys derived in step S1 are first used. These loading keys are decryption credentials independently derived by the storage control chip for each program segment in step S1. The loading keys are then used to perform decryption operations on each program segment within the allowed loading version set. Since each program segment is encrypted using an independent key bound to its physical block group information during storage, the loading key of the corresponding segment needs to be loaded into the cryptographic engine during decryption. The ciphertext data is then decrypted and transformed according to the same working mode as during encryption to obtain the decrypted segment.

[0046] After obtaining the decrypted segment, the content of the segment is hashed using the same secure hash algorithm as during the compilation phase to obtain its hash value. This hash value is then compared with the expected hash value pre-stored in the program's trusted manifest vector. This expected hash value is a digest value calculated during firmware compilation from the original plaintext content of the segment and serves as a benchmark for integrity verification. If they match, it indicates that the segment's content has not been tampered with during storage and transmission and that decryption was successful, thus authentication is passed. If they do not match, it indicates that the segment may be corrupted or an incorrect loading key was used; this copy is not accepted, and the process can be retried using other copies of this version in the allowed loading version set, or the segment can be marked as authentication failed.

[0047] After authentication, the physical block number corresponding to the program segment is extracted. This physical block number records the actual storage location of the segment in non-volatile storage media, used to read the segment content from the correct physical address during subsequent loading and execution. Simultaneously, the loading order is determined based on the dependencies between program segments. These dependencies are recorded in the dependency markers of the program's trusted manifest vector, reflecting the functional calls and references between segments. For example, the bootloader segment must be loaded before the main controller segment, and the main controller segment must be loaded before the firmware runtime segment. The dependency markers are automatically generated by the development toolchain during the firmware compilation and linking phases. By parsing these markers, a dependency graph between segments can be constructed. The hash value of each segment is used as the authentication credential, the physical block number is used as the loading location, and the loading order is used as the timing constraint to jointly construct an authentication segmented directed acyclic graph. Each node in this directed acyclic graph corresponds to an authenticated program segment. The node attributes include the hash value, physical block number, and segment type identifier of the segment. The directed edges in the graph point from the dependent segment to the dependent segment, indicating that the dependent segment must be loaded before the dependent segment.

[0048] By decrypting each segment using an independently bound loading key and authenticating it by comparing hash values, the risk of a single segment key leak leading to the cracking of all segments is effectively prevented, while ensuring the integrity and authenticity of the loaded content. By constructing a directed acyclic graph of the authentication segments, the dependencies and loading order between segments are clarified, laying the foundation for generating a unified startup sequence based on the subsequent hardware initialization constraints, and avoiding startup failures caused by incorrect loading order.

[0049] In step S3, generating the control program startup topology sequence includes: parsing the authentication segmented directed acyclic graph to obtain the loading dependencies of each program segment; obtaining the initialization dependencies of the storage mapping table, the reset order of each channel of the non-volatile storage medium, the host interface mask table, and the data transmission permission table; constructing a comprehensive constraint graph based on the loading dependencies; performing topology sorting on the comprehensive constraint graph; and generating the control program startup topology sequence.

[0050] Specifically, after the authentication segmented directed acyclic graph is constructed, in order to transform the logical loading order in the graph into an actual startup process executable by the chip hardware, it is necessary to further obtain the hardware initialization constraints and channel resource configuration information of the storage controller, and integrate these hardware dependencies with the segmented loading dependencies into a unified constraint model, ultimately generating a startup sequence that can be directly executed.

[0051] When generating the control program startup topology sequence, the authentication segmented directed acyclic graph is first parsed. This graph, during its construction, records the dependencies between program segments as directed edges. Each directed edge points from the dependent segment to the dependent segment, explicitly indicating the loading order. Therefore, by traversing all directed edges in the graph, the loading dependencies of each program segment can be directly obtained without maintaining a separate dependency table. This loading dependency record records which predecessor segments each segment must wait for to complete loading before it can be loaded. For example, the bootloader segment must be loaded before the main controller segment, and the main controller segment must be loaded before the firmware runtime segment.

[0052] Simultaneously, the system retrieves the initialization dependencies of the storage mapping table. The storage mapping table is a data structure in the storage controller used to maintain the mapping relationship between logical addresses and physical addresses. Its initialization can only be executed after specific hardware modules are ready. This initialization dependency records the sequential constraints between the initialization of the storage mapping table and the readiness states of each hardware module. The system also retrieves the reset sequence of each channel of the non-volatile storage medium. Flash memory channels are the data transmission paths between the storage controller and flash memory chips. During system startup, each channel needs to perform a reset operation to restore it to its initial state. Since different channels may share certain hardware resources, the reset operations need to be executed sequentially in a specific order to avoid resource contention or signal conflicts. Finally, the system retrieves the host interface mask table. The host interface mask table records the host interface types and command types that need to be masked at different stages of firmware loading. When the storage controller does not yet have full command processing capabilities, masking host requests can prevent external interference from disrupting the loading process. This table specifies the start and end points of masking at each stage. The data transfer permission table is obtained. The data transfer permission table records the access permission level of each program segment to the data path and hardware register after loading. It is used to control the segment with different functional roles to only access resources within its authorized scope during execution, and to prevent low-privilege segments from overstepping their authority to operate sensitive hardware.

[0053] The initialization dependencies of the aforementioned storage mapping table, the reset order of each channel of the non-volatile storage medium, the host interface mask table, and the data transfer permission table are all pre-stored in the read-only configuration memory (ROM) of the storage controller chip. During the chip manufacturing stage, the chip manufacturer writes the corresponding configuration parameters into this ROM according to the hardware design specifications. When the storage controller chip starts executing step S3, the bootloader sequentially reads the aforementioned four types of hardware constraint information from a predetermined address offset in the ROM and loads them into the chip's internal cache for use in subsequent steps. If the chip supports online hardware configuration upgrades, the aforementioned information can also be stored in a reserved configuration area of ​​the non-volatile storage medium, and loaded into memory by the bootloader from this reserved configuration area during startup.

[0054] The aforementioned loading dependencies, storage mapping table initialization dependencies, channel reset order, host interface mask table, and data transmission permission table are combined into a comprehensive constraint graph. The comprehensive constraint graph is a directed graph containing various types of nodes, including program segmentation nodes, hardware initialization nodes, channel reset nodes, interface configuration nodes, and permission setting nodes. Directed edges represent the sequential constraints between nodes. The construction process of the comprehensive constraint graph involves overlaying constraints from various sources according to time order and resource dependencies. If there is a direct or indirect sequential constraint between two nodes, a corresponding directed edge is established; otherwise, they are considered to be able to execute in parallel.

[0055] When overlaying various constraint relationships to construct a comprehensive constraint graph, the following default timing constraint rules are used to determine the order of different types of nodes: The reset node for all non-volatile storage media channels must be executed before any program segment loading node to ensure that the storage medium is in an accessible state before performing firmware segment read operations; the initialization node for the storage mapping table must be executed before the program segment loading node that depends on the mapping table, but for bootloader segments that do not involve logical address to physical address translation, their loading node can be executed earlier without being constrained by the storage mapping table initialization completion state; the configuration and decompression nodes of the host interface mask table are inserted into the corresponding positions in the loading sequence according to the stage start and decompression points defined by the mask table itself. Specifically, the insertion method is to execute the corresponding mask start node before entering a certain loading stage and execute the corresponding mask decompression node after leaving the stage; the setting node for the data transfer permission table is executed immediately after the program segment corresponding to the permission is loaded to ensure that the segment obtains the necessary hardware access permissions before it can start running. For any two nodes whose order is not explicitly defined in the above default rules, if they do not compete for resources and have no logical dependency, no constraint edge is added to the comprehensive constraint graph, and they are considered to be able to execute in parallel. By supplementing the above default rules, we ensure that the constraint relationships in the comprehensive constraint graph are complete and unambiguous.

[0056] After the comprehensive constraint graph is constructed and the sequential constraints between all nodes are determined, a topological sort can be performed on the comprehensive constraint graph to generate the final startup sequence. Topological sorting is a sorting algorithm for directed acyclic graphs. Its core principle is to start from the node with an in-degree of zero, sequentially remove that node and all its outgoing edges, and repeat this process until all nodes have been removed. The order of the removed nodes is the execution sequence that satisfies all constraints. The node order obtained from the topological sort is output as the startup topological sequence of the control program. Each element in this sequence corresponds to a specific operation, including loading a program segment, initializing a storage mapping table, resetting a flash channel, configuring the host interface shielding state, or setting data transfer permissions. The operations in the sequence are executed sequentially according to their arrangement to ensure that all dependent constraints are satisfied.

[0057] Through the specific implementation of step S3 above, this application achieves unified orchestration of software segmentation dependencies and hardware initialization constraints during firmware loading. By integrating loading dependencies with storage mapping table initialization dependencies, channel reset order, host interface mask table, and permission configuration information into a comprehensive constraint graph and performing topology sorting, the generated startup topology sequence ensures that each operation only begins execution after all its preconditions are met. This effectively avoids startup failures caused by incorrect loading order or unprepared hardware, ensuring the timing correctness and execution reliability of the firmware loading process in complex hardware environments.

[0058] Step S4: After the topology sequence is loaded according to the control program, the lowest trusted security version is verified. If the verification passes, a two-phase commit of one-time programmable memory pre-commit and non-volatile storage medium mirror confirmation is performed; otherwise, a rollback blocking or downgrade startup is performed.

[0059] In step S4, the minimum trusted security version is verified, including: after loading is completed according to the control program startup topology sequence, the version number of the control program to be loaded is compared with the minimum trusted security version, and the legality of the program signature chain is verified, as well as whether the number of integrity corrections for each program segment exceeds the preset correction threshold, whether the current bad block table is consistent with the bad block table read at startup, and whether the remaining bits of the one-time programmable memory meet the requirements of this submission; if the version number comparison is consistent, the signature chain verification is legal, and all judgments pass, a pre-submission flag is written to the one-time programmable memory, and then a mirror confirmation flag is written to the non-volatile storage medium. After both the pre-submission flag and the mirror confirmation flag are successfully written, the two-phase submission is completed.

[0060] Specifically, after loading all program segments according to the topology sequence initiated by the control program, to ensure that the final loaded firmware version truly meets all security constraints and that the physical storage state supports version locking, a comprehensive verification of the minimum trusted security version is required. Upon successful verification, an irreversible version commit is performed atomically. For example... Figure 3 The diagram shown is a flowchart of the implementation of step S4.

[0061] After loading all program segments according to the control procedure's startup topology sequence, the version number of the control program to be loaded is first compared with the minimum trusted security version determined during the constraint adjudication phase. If the version number to be loaded is equal to or higher than the minimum trusted security version, the version validity check passes, indicating that the currently loaded firmware meets the minimum version threshold required for rollback protection; if the version number to be loaded is lower than the minimum trusted security version, it indicates that there is an anomaly in the loading process or that the data has been tampered with, and the check fails. Simultaneously, the validity of the program signature chain is verified. The program signature chain is a sequence of digital signatures that progressively sign the firmware content using the firmware developer's private key. It consists of signature data attached to the firmware image and the signer's certificate. The verification process is as follows: The signature data is extracted from the firmware image. The signer's certificate is read and verified through the certificate chain to the root certificate authority's public key pre-stored in the chip's secure area. After confirming the certificate's validity, the signature value is decrypted using the public key in the certificate to obtain the claimed hash value. This hash value is then compared with the hash value calculated in real time for the firmware content. If they match, the signature chain verification is successful, indicating that the firmware source is trustworthy and the content has not been tampered with. It is also necessary to determine whether the integrity error correction count for each program segment exceeds a preset error correction threshold. The integrity error correction count refers to the number of error bits actually corrected by the error correction code decoder during the reading and decryption of each program segment. This value reflects the degree of data degradation that occurs when the storage medium stores that segment. If the error correction count for a segment exceeds the preset error correction threshold, it indicates that the health of the physical area where that segment is located is approaching its error correction capability limit. Continuing to submit this version carries the risk of data irrecoverability during subsequent operation. The specific value of the preset error correction threshold is determined based on the error correction code type used by the storage controller chip and the specifications of the flash memory chips.

[0062] The system checks if the current bad block table matches the bad block table read during startup. The bad block table records the addresses of all physical blocks in the non-volatile storage medium that have been marked as unreliable. If a new bad block is detected during startup and it is located within the current firmware segment's occupied range, the bad block table consistency check fails, indicating that the storage state has changed during startup in a way that is detrimental to the stable operation of the firmware. The system also checks if the remaining bits of the one-time programmable memory meet the requirements of this commit. Each bit cell of the one-time programmable memory can only be unidirectionally converted from the initial state to the programmed state once. Each version commit requires programming a fixed number of bits to increment the bit count. If the remaining unprogrammed bits are less than the number of bits required for this commit, version locking cannot be completed, and the check fails.

[0063] If the version number matches, the signature chain is verified, and all the above checks pass, a two-phase commit operation is performed. First, a pre-commit flag is written to the one-time programmable memory (IPM). This flag indicates the location of the programmable bits calculated based on the version number to be committed. The IPM programmer applies programming voltages to these target bits, causing an irreversible state transition. After the pre-commit flag is successfully written, a mirror confirmation flag is written to the non-volatile storage medium. This flag contains structured data including a confirmation timestamp, confirmation version number, and pre-commit flag location information, and is written to the firmware image's metadata area or dedicated boot log area. Once both the pre-commit flag and the mirror confirmation flag are successfully written, the two-phase commit is complete. Afterward, the system will use this committed version as the minimum allowed version upon reboot, and any firmware version lower than this will be permanently prohibited from loading.

[0064] Through the aforementioned two-phase commit mechanism, this application achieves atomic and irreversible locking of firmware version upgrades. Utilizing the physical unidirectional nature of one-time programmable memory ensures that version records cannot be erased or rolled back. Simultaneously, the two-phase design of pre-commit and image confirmation avoids the problem of uncertain version states caused by abnormal power outages during the writing process. Even if the two-phase commit process fails midway, inconsistencies can be detected upon the next boot, and corresponding recovery measures can be taken, effectively preventing firmware rollback attacks.

[0065] In step S4, the rollback blocking or downgrade startup includes: if the verification fails, blocking the loading process of the current control program and determining the type of failure reason; selecting to load the preset backup control program or enter read-only maintenance mode according to the type of failure reason; extracting the block health during the current startup process, determining whether the block health is lower than the preset health threshold; if the block health is lower than the health threshold, adding the corresponding physical block to the bad block blacklist and updating the placement strategy of the subsequent control program.

[0066] Specifically, if verification fails, the loading process of the current control program is first blocked, preventing any firmware segments that fail verification from continuing execution and thus preventing untrusted code from damaging the system's security. After the blocking operation is completed, the type of failure is determined based on the specific triggering conditions of the verification failure. If the triggering condition for verification failure is an invalid program signature chain verification or a version number lower than the minimum trusted security version, it is determined to be a security-related failure. This type of failure indicates that the firmware source is untrusted or there is a clear rollback attack attempt, posing a high security risk. It directly enters read-only maintenance mode, providing only limited status query and log export functions, and refusing to perform any firmware updates or data write operations.

[0067] If the verification failure is triggered by the segment integrity error correction count exceeding the preset error correction threshold, bad block table inconsistency, or insufficient remaining bits in the one-time programmable memory, it is determined to be a media-related failure. This type of failure indicates that a change in the physical state of the storage medium renders the current firmware copy unusable, rather than a security issue with the firmware content itself. In this case, an attempt is made to load the backup control program pre-installed in the non-volatile storage medium. The backup control program is an independent firmware copy additionally stored in a reserved physical area during firmware deployment. The version number of this copy is not lower than the minimum allowed version number and has undergone full signature verification to ensure that it has legitimate downgrade boot qualifications when a media-related failure is triggered. If the backup program loads successfully, it runs to complete the boot process; if the backup program also fails to load, it enters read-only maintenance mode.

[0068] Regardless of whether the verification succeeds or fails, the block health information collected during the current startup process is extracted. Block health is a comprehensive quantitative assessment of the reliability of each physical block in a non-volatile storage medium. Its calculation is based on the error correction margin, erase / write cycles, and power-down flags of each physical block during this startup process. Error correction margin is the difference between the maximum error correction capability of the error correction code and the actual number of error bits corrected; a lower error correction margin indicates poorer data retention capability of the block. The erase / write cycles reflect the degree of wear accumulation on the physical block; a higher number of erase / write cycles indicates that the block is closer to the end of its lifespan. The power-down flag records whether the physical block has been affected by historical power-down events. The block health of each physical block is obtained by normalizing the values ​​of these three dimensions and then weighted and summing them.

[0069] The system determines whether the health status of each physical block is lower than a preset health threshold. This health threshold is a reliability threshold pre-configured based on the type of storage medium and its rated lifespan. If the health status of a physical block is lower than this threshold, it indicates that the block has entered a high-risk degradation state. Continuing to use it for storing firmware may lead to data loss or loading failure. The physical block is then added to a bad block blacklist. The bad block blacklist records the addresses of all physical blocks deemed unreliable. The storage controller will automatically skip blocks in the blacklist during subsequent firmware updates or data placement operations. Simultaneously, the placement strategy of subsequent control programs is updated. The placement strategy refers to the set of rules followed by the storage controller when allocating physical storage locations for firmware segments. The updated placement strategy will avoid writing new firmware copies to physical blocks in the blacklist, prioritizing the deployment of firmware to physical blocks with higher health status.

[0070] Through the aforementioned rollback blocking, downgrade startup, and dynamic update mechanisms, this application provides a hierarchical fault recovery path when firmware loading is abnormal. Security-related failures directly enter read-only mode to block attacks, while media-related failures maintain system availability through backup programs. At the same time, the application dynamically updates the bad block blacklist and placement strategy using block health information collected during each startup process, enabling subsequent firmware deployments to proactively avoid degraded physical areas. As runtime increases, the system's loading decisions and storage management strategies become increasingly aligned with the actual health status of the storage media, thereby continuously improving the long-term reliability of firmware loading.

[0071] The process involves selecting between loading a pre-set backup control program or entering read-only maintenance mode based on the type of failure. Specifically: if the failure is triggered by an invalid program signature chain or a version number lower than the minimum trusted security version, the failure type is classified as a security-related failure. If the failure is triggered by a segment integrity error correction count exceeding a preset error correction threshold, an inconsistent bad block table, or insufficient remaining bits in the one-time programmable memory, the failure type is classified as a media-related failure. If classified as a security-related failure, the system directly enters read-only maintenance mode. If classified as a media-related failure, the system attempts to load a pre-set backup control program from the non-volatile storage medium. If the backup control program loads successfully, it runs and completes the startup process. If the backup control program fails to load, the system enters read-only maintenance mode.

[0072] Specifically, if the verification fails, a differentiated processing strategy needs to be adopted according to the specific condition type that triggered the failure. The following describes in detail the determination of the failure cause type and the corresponding processing process in conjunction with specific implementation methods.

[0073] After blocking the loading process of the current control program, the failure reason type is first determined based on the specific triggering conditions of the verification failure. If the triggering condition for the verification failure is that the program signature chain verification is invalid, that is, the digital signature in the firmware image cannot be traced back to the root certificate authority built into the chip through the certificate chain, or the hash value obtained after designing with the certificate public key is inconsistent with the hash value calculated in real time on the firmware content, it indicates that the firmware source is untrusted or the content has been tampered with; or the version number of the control program to be loaded is lower than the minimum trusted security version determined in the constraint adjudication stage, indicating that there is a clear rollback attack attempt or the loading process is abnormal, then the failure reason type is determined to be a security failure. If the failure is triggered by the following conditions: the number of segment integrity correction attempts exceeds the preset correction threshold, meaning that the number of error bits actually corrected by the error correction code decoder during the reading and decryption of one or more program segments exceeds the preset reliability threshold, indicating that the health status of the physical area where the segment is located is close to the limit of its error correction capability; or the current bad block table is inconsistent with the bad block table read at startup and the newly added bad block is located within the current firmware segment's occupied range, indicating that the storage status has changed during startup in a way that is not conducive to the stable operation of the firmware; or the remaining unprogrammed bits of the one-time programmable memory are less than the number of bits required to be programmed in this submission, making it impossible to complete the version locking operation, then the failure reason type will be determined as a media-related failure.

[0074] After determining the type of failure, the corresponding processing operation is performed. If the failure is determined to be a security-related failure, since this type of failure indicates that the firmware source is untrusted or there is a clear rollback attack attempt, the security risk is high. Any attempt to load a backup program may introduce additional security risks. Therefore, it directly enters read-only maintenance mode. In read-only maintenance mode, the storage control chip only provides limited status query and log export functions, refuses to perform any firmware update or data write operations, and waits for maintenance personnel to diagnose and recover through the security interface.

[0075] If the failure is determined to be media-related, it indicates that the current firmware copy is unusable due to changes in the physical state of the storage medium, rather than a security issue with the firmware content itself. In this case, an attempt is made to load a pre-installed backup control program in a non-volatile storage medium. The backup control program is an independent firmware copy stored separately in a reserved physical area during firmware deployment. Its version number is usually lower than the version to be loaded, but it has undergone full signature verification and is stored in a different physical block group than the current firmware copy to avoid simultaneous impact from failures in the same physical area. Hash value verification and signature chain verification are also performed when loading the backup control program to ensure its integrity and authenticity. If the backup control program loads successfully, it runs to complete the startup, allowing the system to maintain basic operational capabilities even when the latest firmware cannot be loaded. If the backup control program fails to load, the system enters read-only maintenance mode.

[0076] Through the aforementioned failure cause type determination and differentiated processing mechanism, this application achieves hierarchical and categorized handling of firmware loading failures. Security-related failures directly enter read-only mode to block potential attacks, while media-related failures maintain basic system availability through backup programs. This avoids complete system unavailability due to physical degradation of the storage medium and prevents blind attempts to load untrusted code in security risk scenarios, thereby improving the security and recoverability of the storage control chip under various abnormal conditions.

[0077] The above describes a firmware encryption loading and rollback protection method for a storage control chip according to an embodiment of this application. The following describes a firmware encryption loading and rollback protection system for a storage control chip according to an embodiment of this application. Please refer to [link / reference]. Figure 4 A firmware encryption loading and rollback protection system for a storage control chip in this application embodiment includes: The acquisition module is used to acquire the data packet of the control program to be loaded, extract the trusted manifest vector of the program, obtain the program security version number and physical block group information, and derive the loading key of each segment of the control program to be loaded by combining the hardware root key and device identifier. The determination module is used to obtain the counting state of the one-time programmable memory and the physical state information of the non-volatile storage medium, construct a constraint tensor containing version wear and location information, generate a candidate version state diagram and perform constraint adjudication, and determine the set of allowed loading versions and the minimum trusted security version; The generation module is used to perform authentication and decryption on program segments within the allowed load version set using the loading key, generate a directed acyclic graph of authentication segments, store mapping initialization dependencies and channel reset order based on the directed acyclic graph of authentication segments, and generate a control program startup topology sequence. The verification module is used to verify the lowest trusted security version after the topology sequence is loaded according to the control program. If the verification passes, a two-phase commit of one-time programmable memory pre-commit and non-volatile storage medium mirror confirmation is performed; otherwise, a rollback blocking or degraded startup is performed.

[0078] In summary, this application generates independent loading keys for each program segment by inputting the hardware root key, device identifier, program security version number, physical block group information, and error correction margin level into the key derivation function. This achieves device binding, location binding, and health status binding of the keys, effectively resisting firmware cloning attacks and adapting to bad block remapping scenarios. A candidate version state graph is generated by constructing a constraint tensor containing version wear and location information. Constraint adjudication is performed by comprehensively considering version monotonicity weight, multi-replica consistency weight, and state transition weight. This filters out the allowed loading version set and the lowest trusted security version from multiple firmware replicas, ensuring both unidirectional version upgrades and physical health. An authentication segmented directed acyclic graph is generated through authentication and decryption. The segment loading dependencies, storage mapping initialization dependencies, channel reset order, host interface mask table, and data transmission permission table are integrated into a comprehensive constraint graph and topology sorted to generate a control program startup topology sequence, ensuring the timing synchronization of hardware and software states. This application employs a bi-phase commit mechanism to atomically lock versions, leveraging the unidirectional physical characteristics of one-time programmable memory to ensure irreversible version recording. It also implements tiered handling for verification failures based on security and media conditions, and dynamically updates the bad block blacklist and placement strategy based on block health. In complex environments characterized by continuous storage media aging, the risk of abnormal power loss, and inconsistent states among multiple replicas, this application achieves unidirectional firmware upgrade protection and intelligent loading path selection, effectively preventing firmware rollback attacks and significantly improving the firmware security protection capabilities and system startup reliability of the storage control chip in complex physical environments.

[0079] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0080] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0081] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method for firmware encryption loading and rollback protection of a storage control chip, characterized in that, The method includes: Step S1: Obtain the data packet of the control program to be loaded, extract the trusted manifest vector of the program, obtain the program security version number and physical block group information, and derive the loading key of each segment of the control program to be loaded by combining the hardware root key and device identifier. Step S2: Obtain the counting state of the one-time programmable memory and the physical state information of the non-volatile storage medium, construct a constraint tensor containing version wear and location information, generate a candidate version state diagram and perform constraint adjudication, and determine the set of allowed loading versions and the minimum trusted security version; Step S3: Use the loading key to perform authentication and decryption on program segments within the set of allowed loading versions, generate an authentication segmented directed acyclic graph, store the mapping initialization dependencies and channel reset order according to the authentication segmented directed acyclic graph, and generate a control program startup topology sequence; Step S4: After the topology sequence is loaded according to the control program, the lowest trusted security version is verified. If the verification passes, a two-phase commit of one-time programmable memory pre-commit and non-volatile storage medium mirror confirmation is performed; otherwise, a rollback blocking or downgrade startup is performed.

2. The firmware encryption loading and rollback protection method for the storage control chip according to claim 1, characterized in that, Step S1 includes: When the storage control chip starts up, it acquires the data packet of the control program to be loaded, parses the program attributes and storage area information in the data packet, and generates a program trust list vector. The program trust list vector also contains the expected hash value of each program segment. Extract the program security version number and the physical block group information of the control program segment to be loaded from the program trusted manifest vector; Obtain the hardware root key generated by the physically unclonable function, the device identifier of the storage controller, and the error correction margin level of the non-volatile storage medium; The program security version number, the physical block group information, the hardware root key, the device identifier, and the error correction margin level are input into the key derivation function to calculate the loading key for each program segment of the control program to be loaded.

3. The firmware encryption loading and rollback protection method for the storage control chip according to claim 1, characterized in that, Step S2 generates a candidate version state diagram, including: Read the bit count of the one-time programmable memory, determine the minimum allowed version number based on the bit count, and derive the start random number through a physically non-clonable function; Obtain the mirror version copy, bad block table, block erase / write count, power failure log, and error correction margin in the non-volatile storage medium, and construct a constraint tensor by combining the minimum allowed version number and the startup randomness; Based on the mirror version copy in the constraint tensor and the bad block table, program copy nodes with different physical locations are established, and nodes with version numbers lower than the minimum allowed version number are marked as unloadable in the constraint tensor. The erase / write degradation penalty is calculated based on the number of times the block is erased and written, and the power failure write penalty is calculated based on the power failure log. State transition probabilities are assigned to each of the program replica nodes, and the state transition probabilities are adjusted using the startup random variable as a randomization factor to generate a candidate version state diagram.

4. The firmware encryption loading and rollback protection method for the storage control chip according to claim 3, characterized in that, Step S2 determines the allowed set of versions to be loaded and the minimum trusted security version, including: Based on the relationship between the version number of each node in the candidate version state diagram and the minimum allowed version number determined by the bit count, a version monotonic weight is assigned to each node. Based on the consistency of the hash values ​​of the mirror version replicas corresponding to the same version on each replica node, assign multi-replica consistency weights to each node. Based on the sum of the incoming edge probabilities of each node in the state transition probability in the candidate version state graph, state transition weights are assigned to each node. The positive score is obtained by weighted summation of the version monotonic weight, the multi-replica consistency weight, and the state transition weight. The negative penalty is obtained by adding the erase / write degradation penalty and the power-down write penalty. The comprehensive credibility score of each node is obtained based on the positive score and the negative penalty. The versions corresponding to nodes whose overall trustworthiness scores are greater than a preset score threshold are added to the set of allowed-load versions, and the version with the smallest version number in the set of allowed-load versions is determined as the lowest trusted and secure version.

5. The firmware encryption loading and rollback protection method for a storage control chip according to claim 1, characterized in that, Step S3 generates a directed acyclic graph of authentication segments, including: The program segments within the set of allowed loadable versions are decrypted using the loading key to obtain decrypted segments, and the hash value of the decrypted segments is calculated. The hash value is compared with the expected hash value in the program trust list vector. If the comparison is consistent, the physical block number corresponding to the program segment is extracted, and the loading order is determined according to the dependency relationship between the program segments. An authentication segmented directed acyclic graph is constructed based on the hash value, the physical block number, and the loading order.

6. The firmware encryption loading and rollback protection method for a storage control chip according to claim 1, characterized in that, Step S3 generates the control program to start the topology sequence, including: The directed acyclic graph of the authentication segments is parsed to obtain the loading dependencies of each program segment; The system obtains the initialization dependencies of the storage mapping table, the reset order of each channel of the non-volatile storage medium, the host interface mask table, and the data transmission permission table. It then constructs a comprehensive constraint graph based on the loading dependencies, performs topology sorting on the comprehensive constraint graph, and generates the control program startup topology sequence.

7. The firmware encryption loading and rollback protection method for a storage control chip according to claim 1, characterized in that, Step S4 verifies the lowest trusted security version, including: After the topology sequence is loaded according to the control program, the version number of the control program to be loaded is compared with the lowest trusted security version, and the legality of the program signature chain is verified. It is also determined whether the number of integrity corrections for each program segment exceeds the preset correction threshold, whether the current bad block table is consistent with the bad block table read at startup, and whether the remaining bits of the one-time programmable memory meet the requirements of this submission. If the version number matches, the signature chain is verified as valid, and all judgments pass, a pre-commit flag is written to the one-time programmable memory, and a mirror confirmation flag is written to the non-volatile storage medium. The two-phase commit is completed after both the pre-commit flag and the mirror confirmation flag are successfully written.

8. The firmware encryption loading and rollback protection method for a storage control chip according to claim 1, characterized in that, Step S4 involves performing a rollback blocking or downgrade startup, including: If the verification fails, the loading process of the current control program is blocked, and the type of failure reason is determined. Based on the type of failure reason, the preset backup control program is loaded or the read-only maintenance mode is entered. Extract the block health status during the current startup process, determine whether the block health status is lower than a preset health status threshold, and if the block health status is lower than the health status threshold, add the corresponding physical block to the bad block blacklist and update the placement strategy of the subsequent control program.

9. The firmware encryption loading and rollback protection method for a storage control chip according to claim 8, characterized in that, Depending on the type of failure, you can choose to load the preset backup control program or enter read-only maintenance mode, including: If the verification failure is triggered by an invalid program signature chain or a version number lower than the minimum trusted security version, then the failure reason type will be determined as a security failure. If the triggering condition for verification failure is that the number of segment integrity correction errors exceeds the preset error correction threshold, the bad block table is inconsistent, or the remaining bits of the one-time programmable memory are insufficient, then the failure reason type will be determined as media type failure. If the failure is determined to be a security-related one, it will directly enter read-only maintenance mode; If the failure is determined to be due to a media-related issue, an attempt is made to load the pre-installed backup control program in the non-volatile storage medium. If the backup control program is successfully loaded, the startup is completed by running the backup control program. If the backup control program fails to load, the system enters read-only maintenance mode.

10. A firmware encryption loading and rollback protection system for a storage control chip, used to implement the firmware encryption loading and rollback protection method for a storage control chip as described in any one of claims 1-9, characterized in that, The system includes: The acquisition module is used to acquire the data packet of the control program to be loaded, extract the trusted manifest vector of the program, obtain the program security version number and physical block group information, and derive the loading key of each segment of the control program to be loaded by combining the hardware root key and device identifier. The determination module is used to obtain the counting state of the one-time programmable memory and the physical state information of the non-volatile storage medium, construct a constraint tensor containing version wear and location information, generate a candidate version state diagram and perform constraint adjudication, and determine the set of allowed loading versions and the minimum trusted security version; The generation module is used to perform authentication and decryption on program segments within the set of allowed loadable versions using the loading key, generate a directed acyclic graph of authentication segments, store mapping initialization dependencies and channel reset order based on the directed acyclic graph of authentication segments, and generate a control program startup topology sequence. The verification module is used to verify the lowest trusted security version after the topology sequence is loaded according to the control program. If the verification passes, a two-phase commit of one-time programmable memory pre-commit and non-volatile storage medium mirror confirmation is performed; otherwise, a rollback blocking or degraded startup is performed.

Images