Solid-state drive-based data partitioning storage and dynamic key management method

Abstract

This invention discloses a data partitioning storage and dynamic key management method based on solid-state drives (SSDs), specifically relating to the field of SSD data security storage technology. The method includes: after receiving a host write request, the security device reads the partition whose page number matches the write request, decodes the partition ownership code, retrieves the effective epoch code, increments the previous commit order of the FTL by one to generate the current order, and outputs the write acceptance value; based on the write acceptance value, the security device calls the page encryption key to perform page-level encryption on the data to form ciphertext, concatenates the partition ownership code, effective epoch code, and current order into a page ownership value, writes it to the NAND page sub-area, and generates a programmed page; by recursively hashing the partition ownership, key epoch, commit order, and ciphertext into a page chain record during the write phase, and controlling the FTL attachment entry based on the epoch sealing record, page chain head value recalculation result, and monotonic order alignment result during the key update, page migration, and power-off recovery phases.

Description

Technical Field

[0001] This invention relates to the field of solid-state drive (SSD) data security storage technology, and more specifically, to a method for data partitioning storage and dynamic key management based on solid-state drives (SSDs). Background Technology

[0002] In the data partitioning storage and security protection of solid-state drives, existing solutions are mostly based on partition encryption, full disk encryption, key rotation, anti-rollback counting, and FTL mapping log recovery, so that different business partitions can still maintain access isolation and data recoverability after normal read and write, abnormal restart and key update. Taking vehicle-mounted recording, power line inspection, rail transit monitoring and outdoor data acquisition terminals as examples, solid-state drives need to simultaneously store real-time data acquisition, event evidence, operation logs and upgrade cache. During equipment operation, there may be situations such as instantaneous power outages, remote upgrades, cache write-back and background page migration and overlap. On-site, it is not possible to shut down the machine for a long time for a single key change, nor can historical physical pages be eliminated by a full disk rewrite. In this scenario, the FTL recovery process attempts to restore the correspondence between logical addresses and physical pages based on mapping logs, checkpoints, and page states. Meanwhile, the key management process determines the current key epoch based on partition key records. When key switching, page migration, and mapping commit fall within the same power outage interval, there is a lack of common source determination criteria. After restarting, there may be instances where mapping records still point to old physical pages, page content can still be identified by the recovery process, but the key epoch to which the page belongs has already left the current partition's security state. This could lead to the risk that old pages that should have been invalidated may be reattached to the current partition's address space. The technical problem this application aims to solve is: how to prevent old physical pages that have exited the key epoch from being reattached to the current data partition due to FTL mapping reconstruction during the power loss recovery process of a solid-state drive. Summary of the Invention

[0003] To overcome the aforementioned deficiencies of the prior art, embodiments of the present invention provide a data partitioning storage and dynamic key management method based on solid-state drives. This method recursively constructs a page chain record by partition ownership, key epoch, commit order, and ciphertext hash during the write phase. Furthermore, it controls the FTL attachment entry based on the epoch sealing record, page chain head value recalculation result, and monotonic order alignment result during the key update, page migration, and power-off recovery phases, thereby solving the problems mentioned in the background art.

[0004] To achieve the above objectives, the present invention provides the following technical solution: a method for data partitioning storage and dynamic key management based on solid-state drives, comprising: S1. After obtaining the host write request, the security device reads the partition whose page number is matched, deciphers the partition ownership code, retrieves the effective epoch code, increments the previous commit order of the FTL by one to generate the current order, and outputs the write acceptance value. S2. Based on the written acceptance value, the security device calls the page encryption key to perform protection data page-level encryption to form ciphertext, and concatenates the partition ownership code, effective epoch code and current sequence number into the page ownership value, writes it into the NAND page sub-area, and generates a programmed page. S3. For a programmed page, the hash chain integrity verification algorithm reads the chain head value of the previous page, recursively calculates the chain head value of the current page by combining the chain head value of the previous page, the page ownership value, and the ciphertext hash value, and outputs the data security page chain record. S4. When the partition dynamic key is updated, the security device reads the page head value corresponding to the last sequential position of the original epoch code, and recursively constructs the epoch sealing record using the original epoch code, the last sequential position, and the page head value, and replaces the original epoch code with the new epoch code. When S5 and FTL move a programmed page, the security device reads the source NAND page ownership value and page chain head value, and after recursively verifying them using the hash chain integrity verification algorithm, it submits the target NAND page to the source page ownership value in the order of submission and outputs the target page chain head value.

[0005] In a preferred embodiment, it further includes: S6. After a power outage and restart, the security device scans the recovery candidate page sub-area. Starting from the recovery checkpoint sequence, it checks the candidate page sequence bit by bit using a monotonic sequence alignment algorithm. If the sequence is accepted and the epoch code is the same as the effective epoch code, it is written into the admission chain. If the sequence cannot be accepted or the epoch code is blocked, it is written into the rejection chain. The FTL mapping relationship is reconstructed based on the admission chain, the rejection chain service attachment entry is cut off, and the partition recovery mapping table is output.

[0006] In a preferred embodiment, S1 includes: S11. Obtain the write start page number in the host write request, read the partition boundary table through the security device set in the solid-state drive controller, and generate the start page difference value by subtracting the boundary start page number of each partition boundary entry from the write start page number. Then generate the end page difference value by subtracting the write start page number from the boundary end page number of each partition boundary entry. Take the partition boundary entry with both the start page difference value and the end page difference value as the hit boundary entry, and output the partition ownership code corresponding to the hit boundary entry. S12. Based on the partition ownership code index epoch succession chain, read the last record pointed to by the chain tail pointer, and connect the previous chain head value in the last record to the epoch code in the last record. Then connect the epoch code to the partition ownership code and perform hash recalculation to generate the recalculated chain head value. When the recalculated chain head value is the same as the epoch chain head value in the last record, output the epoch code in the last record as the effective epoch code. S13. Read the previous commit order from the FTL commit order register, perform a binary increment operation on the previous commit order to form the current order, write the partition ownership code into the first segment of the accepting cache, write the effective epoch code into the middle segment of the accepting cache, write the current order into the effective epoch code into the last segment of the accepting cache, and output the written accepting value.

[0007] In a preferred embodiment, S2 includes: S21. Based on the field length boundary of the accepted value, extract the partition ownership code from the first segment of the accepted cache, extract the effective epoch code from the fixed length of the last bit of the partition ownership code, extract the current sequence number from the remaining bits after the last bit of the effective epoch code, and reassemble the three segments into a page ownership check string in the original position order, and output the page ownership value. S22. Based on the page ownership value, read the epoch key material bound to the effective epoch code, connect the epoch key material to the partition ownership code, and then connect it to the current sequential execution of the same-order concatenation hash. Take the leftmost bit of the hash result that is the same as the page key length to generate the page encryption key, and use the page encryption key to perform page-level encryption on the written data, and output the written ciphertext. S23. Perform secondary area address mapping with the page ownership check string and the page write address of the ciphertext, write the ciphertext to the NAND page data area, write the page ownership check string to the record bit in the secondary area of ​​the NAND page bound to the data area address, and output the programmed page.

[0008] In a preferred embodiment, S3 includes: S31. Read the data area of ​​the programmed page segment by segment according to the page read bit width, so that the first segment of ciphertext enters the hash compressor to generate the first segment hash value, so that the next segment of ciphertext is connected to the previous segment hash value and enters the hash compressor again, until the unread length in the page is zero and the ciphertext hash value is output. S32. Read the previous page's chain head value using the hash chain integrity verification algorithm, first connect the previous page's chain head value to the page ownership value to generate the ownership successor value, then connect the ownership successor value to the ciphertext hash value to perform one-way hash recursion, and output the candidate page chain head value.

[0009] In a preferred embodiment, S3 further includes: S33. Read the current sequence number in the page ownership value and read the previous sequence number corresponding to the previous page head value. Perform an increment operation on the previous sequence number to obtain the verification sequence number. When the verification sequence number is the same as the current sequence number, confirm the candidate page head value as the current page head value. S34. Write the current page chain header value into the sub-area of ​​the programmed page, and use the current sequence as the page chain record index to write the current page chain header value, so that when power is lost and restored, the current page chain header value can be read back from the current sequence and the protection data can be verified to be unaltered, and the data security page chain record is output.

[0010] In a preferred embodiment, S4 includes: S41. After the partition dynamic key update is triggered, the security device reads the epoch page chain index area with the original epoch code, obtains the end sequence pointer corresponding to the original epoch code, and reads the same-position record in the page chain record area with the end sequence pointer, and writes the page chain head value in the same-position record as the last page chain head value. S42. Write the original epoch code into the first segment of the sealing buffer, write the end sequence pointer into the middle segment of the sealing buffer, write the last page head value into the last segment of the sealing buffer, perform hash recursion on the sealing buffer, generate the epoch sealing value, and write the original epoch code, end sequence pointer and epoch sealing value into the epoch sealing record. S43. Using the epoch sealing value as the input for generating the new epoch, perform hash derivation to obtain the new epoch code. Write the new epoch code to the end of the epoch succession chain and write the original epoch code to the epoch failure bitmap so that subsequent protection data reading no longer calls the page encryption key corresponding to the original epoch code. Output the epoch succession record.

[0011] In a preferred embodiment, S5 includes: S51, after FTL generates the programmed page move instruction, it reads the source NAND page sub-area according to the source NAND page address in the move instruction, first reads back the source page ownership value from the sub-area ownership record bit, then reads back the source page chain head value from the chain head record bit after the end of the ownership record bit, and outputs the source page verification input. S52. Extract the source commit order from the source page ownership value, perform a decrement operation on the source commit order to obtain the previous commit order, and use the previous commit order to index the page chain record area to read back the previous page chain head value. Then, read the source NAND page data area segment by segment according to the page read bit width, so that the first segment of ciphertext generates the first segment hash value, the next segment of ciphertext is appended to the previous segment hash value and hashed again, until the unread length is zero, and output the source ciphertext hash value. S53. Using the hash chain integrity verification algorithm, the previous page chain head value is connected to the source page ownership value and then to the source ciphertext hash value. The source page recalculated chain head value is generated recursively. When the source page recalculated chain head value is the same as the source page chain head value, the FTL commit order register bit is incremented by one to obtain the target commit order. The target commit order is then used to replace the source commit order in the source page ownership value, and the target page chain head value is generated recursively.

[0012] In a preferred embodiment, S6 includes: S61. After power failure and restart, the security device uses the recovery checkpoint sequence as the current successor sequence, scans the recovery candidate page sub-area, reads the page ownership value page by page, extracts the candidate page sequence from the end of the page ownership value, extracts the candidate epoch code from the middle of the page ownership value, and outputs the recovery candidate sequence. S62. Using the recovered candidate sequence as input, the candidate page order is subtracted from the current acceptance order to generate an order difference through the monotonic sequence alignment algorithm. The number of times the order difference is not equal to one is used as the deviation cost. The order is incremented by one as the acceptance constraint. When the deviation cost is zero, the candidate page is connected to the acceptance path and the candidate page order is used to replace the current acceptance order. When the deviation cost is non-zero, the candidate page is connected to the deviation path. The acceptance path and the deviation path are output. S63. For candidate pages in the succession path, read the candidate epoch code and perform a bitwise XOR sum with the effective epoch code. If the XOR sum is zero and the candidate epoch code has no match in the epoch sealing record, write it into the pending link chain. If the XOR sum is non-zero or the candidate epoch code matches in the epoch sealing record, write it into the rejection pre-link chain. Output the pending link chain and the rejection pre-link chain.

[0013] In a preferred embodiment, S6 further includes: S64. Based on the chain to be attached, form a candidate group of the same page according to the logical page number. Re-execute the page chain head value recursive verification for the candidate pages in the candidate group of the same page. Delete the candidate pages whose recalculated page chain head value is different from the page chain head value of the page attached area. Then, take the first candidate page in the candidate page order from high to low and write it into the admission chain. Write the remaining candidate pages into the rejection pre-chain and output the admission chain. S65. Merge the off-path and the rejection pre-chain to form a rejection chain, reconstruct the FTL mapping relationship from the logical page number to the NAND page based on the admission chain, and cut off the protection data read access entry of the NAND page in the rejection chain through the security device, and output the partition recovery mapping table.

[0014] The technical effects and advantages of this invention are as follows: This solution restores candidate page order alignment and epoch-sealing retrieval, and old epoch pages do not generate FTL attachments, thus reducing the risk of reattaching after restart; The page ownership value is written to the partition ownership code, the effective epoch code, and the current sequence number, so that the written page has a basis for same-source recovery, and the partition misattachment is somewhat suppressed; The encrypted hash value is used to generate the current page's chain head value by attaching the previous page's chain head value. Replacing the page content will destroy the recursive result, thus relatively enhancing the data integrity verification capability. When the key is updated, an epoch sealing record is formed and written into the epoch invalidation bitmap. The original epoch code exits the reading path, and the probability of old key reuse is relatively reduced. The system maintains a secure handover by recalculating the source page header value before migration and writing back the target page header value, which improves the consistency of recovery after the migration of backend pages. The out-of-order pages, closed pages, and failed verification pages are written into the rejection chain and isolated. The restored mapping only takes the admitted pages, thus protecting the data read boundaries to be relatively clear. Attached Figure Description

[0015] Figure 1This is a flowchart outlining the method steps of the present invention. Detailed Implementation

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

[0017] Refer to the instruction manual appendix Figure 1 The present invention provides a data partitioning storage and dynamic key management method based on solid-state drives, comprising: S1. After obtaining the host write request, the security device reads the partition whose page number is matched, deciphers the partition ownership code, retrieves the effective epoch code, increments the previous commit order of the FTL by one to generate the current order, and outputs the write acceptance value. This implementation focuses on the process of generating the write acceptance value in S1. Its purpose is to first determine the data partition to which the starting page number belongs before the written data enters page-level encryption, then verify whether the current key epoch of the data partition has been truly accepted, and finally generate a current sequence number that can be read by subsequent page ownership values, page chain head values, and the power-down recovery process. Furthermore, this implementation uses the partition ownership code, the effective epoch code, and the current sequence number as hierarchical acceptance fields, and writes these three fields into the acceptance cache to form the write acceptance value, which is then used by S2 to perform page-level encryption and write the page ownership value. This implementation includes the following steps: S11 involves using boundary difference calculations to eliminate incorrect attribution caused by overlapping partition boundaries, partition holes, and out-of-bounds page number writes. During execution, the security device reads the start page number from the host write request and sequentially reads partition boundary entries from the partition boundary table stored by the solid-state drive controller. Each partition boundary entry includes a partition number, a boundary start page number, and a boundary end page number. For each partition boundary entry, the security device generates a start page difference by subtracting the boundary start page number from the start page number and generates an end page difference by subtracting the start page number from the boundary end page number. When the start page difference and the end page difference are... When all differences are non-negative, the security device writes the corresponding partition boundary entry into the hit boundary entry cache; when there is only one partition boundary entry in the hit boundary entry cache, the security device reads the partition number in the hit boundary entry and writes it as the partition ownership code for the S12 index epoch succession chain; when the hit boundary entry cache is empty, the security device stops writing the successor value generation and writes the partition miss record; when there are two or more partition boundary entries in the hit boundary entry cache, the security device stops writing the successor value generation and writes the partition boundary conflict record, thereby ensuring that the partition ownership code has a unique source; S12 prevents write requests from directly using an unverified key epoch, ensuring that when S2 calls the page encryption key, it can only use the epoch code of the currently established data partition. During execution, the security device indexes the epoch succession chain using the partition ownership code output by S11 and reads the end record pointed to by the tail pointer in the epoch succession chain. The end record includes the previous chain head value, the epoch code, and the epoch chain head value. The security device first connects the previous chain head value in the end record to the epoch code in the end record, and then connects the epoch code in the end record to the partition ownership code output by S11. The system performs hash recalculation on the access result to generate a recalculated chain head value. When the recalculated chain head value is the same as the epoch chain head value in the end record, it indicates that the end record has not left the epoch succession chain of the corresponding data partition. The security device reads the epoch code in the end record and writes it as the effective epoch code for S13 to write into the acceptance cache. When the recalculated chain head value is different from the epoch chain head value in the end record, the security device stops writing the acceptance value generation and writes the epoch chain abnormal record, thereby preventing invalid epoch codes or replaced epoch records from entering the subsequent protection data page-level encryption process. S13 establishes a commit order that can be read by subsequent page chain recursion and power-down recovery order alignment for this write operation. During execution, the security device reads the FTL commit order register of the corresponding data partition according to the partition ownership code output in S11. The FTL commit order register is written as a non-volatile record by the solid-state drive controller after each mapping commit, so that it can still be read back from the recovery checkpoint after a power failure and restart. The security device reads the previous commit order from the FTL commit order register and performs a binary increment operation on the previous commit order to form the current order. When the FTL commit order register is not... When a previous commit order exists, the security device uses the initial order in the data partition initialization record as the previous commit order and performs a binary increment operation. Subsequently, the security device reads the partition ownership code length, effective epoch code length, and current order length according to the field configuration area of ​​the accept cache. It writes the partition ownership code into the first segment of the accept cache, writes the effective epoch code into the middle segment of the accept cache, and writes the current order into the effective epoch code into the last segment of the accept cache, forming a write accept value and writing it into the accept record area. This allows S2 to extract the partition ownership code, effective epoch code, and current order to generate a page ownership value. Through the above implementation process, S1 no longer simply queries the partition by writing the page number or simply accumulates the commit order. Instead, it first calculates the unique partition ownership code by using the difference between the starting page and the ending page, then obtains the effective epoch code by hashing the epoch succession chain, and finally generates the current order by using the FTL commit order register and writes it to the succession cache. This allows S2, S3, and S6 to continue performing page-level encryption, hash chain recursion, and power-off recovery order verification along the same set of fields. In practical applications: When the vehicle-mounted recording terminal receives an event video write request while driving, the security device first uses the event video write start page number to match the event evidence partition. If the write start page number falls into both the cache partition and the event evidence partition, the write process stops directly and a partition boundary conflict record is formed. If the partition ownership code is unique, the security device then verifies the epoch succession chain tail record of the event evidence partition. After successful verification, the effective epoch code is read, and the current sequence is formed by adding one to the previous commit sequence of the event evidence partition's FTL. Finally, the write succession value is output so that subsequent written ciphertext, page ownership value, and page chain head value can all correspond to the same data partition and the same key epoch.

[0018] S2. Based on the written acceptance value, the security device calls the page encryption key to perform protection data page-level encryption to form ciphertext, and concatenates the partition ownership code, effective epoch code and current sequence number into the page ownership value, writes it into the NAND page sub-area, and generates a programmed page. This implementation focuses on the generation process of the programmed page in S2. Its purpose is to, after the write acceptance value is output in S1, restore the partition ownership code, effective epoch code, and current sequence number according to the field length boundaries, then derive the page encryption key based on these three and form the write ciphertext. Finally, the write ciphertext and the page ownership check string are written to the NAND page data area and NAND page supplementary area respectively, enabling S3 to read the same page ownership check string and write ciphertext to perform page chain head value recursion. The field length boundaries are provided by the page ownership field configuration area within the security device, which stores the partition ownership code length, effective epoch code length, and current sequence number length. The page encryption key is derived from the root key within the security device. This implementation process includes the following steps: S21 confirms that there are no misconnections in the partition ownership code, effective epoch code, and current sequence number written to the acceptor cache in S1, and provides definite input for the derived page encryption key in S22. During execution, the security device reads the write acceptor value and page ownership field configuration area, first truncating the partition ownership code from the first segment of the acceptor cache according to the partition ownership code length, then truncating the effective epoch code from the last bit of the partition ownership code according to the effective epoch code length, and finally truncating the current sequence number from the last bit of the effective epoch code according to the current sequence number length. The three truncated results are then re-continuing according to their original positions in the acceptor cache. The system generates a page ownership verification string and writes the partition ownership code, effective epoch code, current sequence number, and page ownership verification string together as a page ownership value for S22 to read. If the length of the written successor value is not equal to the sum of the lengths of the three fields in the page ownership field configuration area, or if the truncated partition ownership code cannot index the data partition, the security device stops outputting the page ownership value and generates a successor field exception record. If the effective epoch code cannot be verified in the record at the end of the epoch succession chain, the security device stops page encryption key derivation to prevent invalid epoch codes from entering the protected data page-level encryption process. S22 involves assigning different current sequence numbers within the same data partition to different page encryption keys, and ensuring that the written data enters the NAND page data area in ciphertext form. During execution, the security device reads the epoch key material bound to the effective epoch code based on the page ownership value output by S21. The epoch key material is derived by hashing the root key, effective epoch code, and partition ownership code within the security device, and is stored in the key derivation path of the security device, without being written to the NAND page sub-area. The security device connects the epoch key material to the partition ownership code, then connects it to the current sequence number to perform a sequential concatenation hash, obtains the derived hash result, and then... The page encryption key is generated by truncating the corresponding number of bits from the left side of the derived hash result according to the page key length; the page key length is given by the key length configuration bit of the security device; then, the security device performs page-level encryption on the written data with the page encryption key to generate the written ciphertext, which is then written to the NAND page data area by S23; if the epoch key material reading fails, the security device stops writing ciphertext generation and writes an epoch key missing record; if the length of the derived hash result is less than the page key length, the security device appends the hash derivation of the current sequence with the derived hash result until the corresponding number of bits of the page key length can be truncated before generating the page encryption key; The internal root key of the security device is a fixed key that is programmed and written into the security storage area once during the manufacturing stage of the security device, or it is the device root key generated after the device response value output by the Physical Unclonable Function (PUF) of the solid-state drive controller is processed by the key derivation function; the internal root key of the security device only participates in the generation of epoch key material within the key derivation path of the security device, and is not written to the NAND page data area, NAND page auxiliary area or FTL mapping log; S23 establishes a correspondence between the ciphertext written in the NAND page data area and the page ownership check string in the NAND page auxiliary area under the same page address, allowing S3 to calculate the ciphertext hash value and recursively deduce the current page chain head value. During execution, the security device reads the NAND page address allocated by the FTL for this write and obtains the page-in-page write address of the ciphertext in the NAND page data area. The NAND page auxiliary area sets an ownership record bit and a chain head record bit, and the ownership record bit is bound to the page-in-page write address through the same NAND page address. The security device first writes the ciphertext to the NAND page number. According to the data area, the page ownership check string generated in S21 is written into the ownership record bit bound to the page write address in the NAND page sub-area, and the NAND page status record bit is written to the programmed state, and the programmed page is output; if writing ciphertext to the NAND page data area fails, the security device does not write the page ownership check string and releases the current priority occupancy; if writing the page ownership check string to the ownership record bit fails, the security device writes the corresponding NAND page address to the rejection record and prevents the NAND page from entering the S3 page chain head value recursion process, so as to avoid reading the ciphertext page that is missing the page ownership check string in the future; Through the above implementation process, S2 transforms the write acceptance value formed by S1 into a page ownership verification string that can be written to the NAND page sub-area. It also incorporates the partition ownership code, effective epoch code, and current sequence number into the page encryption key derivation, binding the page-level encryption of protected data and the page-level ownership record to the same NAND page address. Thus, when S3 reads a programmed page, it can obtain the write ciphertext from the NAND page data area and the page ownership verification string from the NAND page sub-area, using both to generate the ciphertext hash value and the current page chain head value. During subsequent power-off recovery, the recovery candidate page can also read back the page ownership verification string from the NAND page sub-area to determine whether the key epoch and commit sequence number still qualify for attachment. In practical applications: When a power inspection terminal writes an inspection image into the event evidence partition, the security device first extracts the partition ownership code, effective epoch code, and current sequence number of the event evidence partition from the write acceptance value, and then reassembles them to form a page ownership verification string. Subsequently, based on the epoch key material of the event evidence partition, the current sequence number, and the internal root key of the security device, a page encryption key is derived, and the inspection image data is encrypted into write ciphertext using the page encryption key. Finally, the write ciphertext is written to the NAND page data area, and the page ownership verification string is written to the ownership record bit of the same NAND page sub-area, so that the inspection image can still be identified as a programmed page under the same data partition, the same key epoch, and the same current sequence number after power failure recovery or FTL relocation.

[0019] S3. For a programmed page, the hash chain integrity verification algorithm reads the chain head value of the previous page, recursively calculates the chain head value of the current page by combining the chain head value of the previous page, the page ownership value, and the ciphertext hash value, and outputs the data security page chain record. This implementation focuses on the generation process of the data security page chain record in S3. Its purpose is to incorporate the written ciphertext in the NAND page data area, the page ownership value in the NAND page auxiliary area, and the previous page head value in the page chain record area into the same hash chain integrity verification process after the programmed page is formed in S2. This ensures that the current page head value is simultaneously bound to the written ciphertext content, the page ownership value, and the commit order. The page ownership value is the page ownership verification string written to the NAND page auxiliary area in S2. The page chain record area stores the page head value using the commit order as an index. The page readout bit width is provided by the readout bit width configuration bit of the security device, and the effective length of the written ciphertext is stored by the NAND page status record bit. This implementation process includes the following steps: In this step, the starting address of the NAND page data area does not refer to the physical page header address of the NAND page, but rather to the ciphertext start address identified by the page write address in S23. When the ciphertext is written in S23, the security device simultaneously writes the page write address and the effective length of the ciphertext to the NAND page status record bit. When generating the ciphertext hash value in S31, the page write address and the effective length of the ciphertext are first read from the NAND page status record bit. Then, the page write address is used as the starting point for reading the first segment of ciphertext, and the effective length of the ciphertext is used to limit the end point of each segment read. Therefore, when there is an intra-page offset in the ciphertext, the hash compressor only performs hashing on the ciphertext interval covered by the page write address to the effective length of the ciphertext, and does not read the blank area at the beginning of the page, the invalid padding area, or other data areas on the same page. S31 converts the written ciphertext in the NAND page data area into a fixed-length ciphertext hash value, which is then used by S32 in the current page chain head value recursion. During execution, the security device reads the NAND page status record bits of the programmed page to obtain the effective length of the written ciphertext, and reads the first segment of ciphertext from the starting address of the NAND page data area according to the read bit width configuration bits. After the first segment of ciphertext enters the hash compressor, a first segment hash value is generated. Subsequently, the security device deducts the length of the first segment of ciphertext from the unread length within the page, and continues to read the next segment of ciphertext, so that the next segment of ciphertext is appended to the previous segment hash value before being read again. The hash compressor is used for reading and hash compression. The above reading and hash compression are performed in ascending order of page address until the unread length in the page is zero. The last hash compression result is written as a ciphertext hash value for S32 to read. If the length of the last ciphertext to be read is less than the read bit width, the security device reads the last ciphertext according to the last ciphertext to be read and participates in hash compression. If the NAND page data area reading fails or the effective length of the written ciphertext is inconsistent with the actual read length, the security device stops the output of the ciphertext hash value and writes the programmed page into the page chain rejection record to prevent the missing ciphertext from entering the subsequent page chain recursion. S32 ensures that the current write operation cannot be independently established without the previous commit order through a hash chain integrity verification algorithm. During execution, the security device reads the page ownership value from the sub-area of ​​the programmed page and extracts the current order from the page ownership value. The security device decrements the current order by one to obtain the previous order, then uses the previous order to index the page chain record area to obtain the previous page head value. The previous page head value is first connected to the page ownership value to generate an ownership successor value, and then the ownership successor value is connected to the ciphertext hash value output by S31 to perform one-way hash recursion to obtain the candidate page head value. If the previous order index cannot find a record in the page chain record area, the security device reads the data partition initialization head value as the previous page head value. If the page ownership value is missing, the previous page head value is missing, and there is no data partition initialization head value, the security device stops generating the candidate page head value and writes the programmed page into the page chain rejection record. S33 ensures that the candidate page header value is not only generated by field hashing, but also forms a sequential relationship with the FTL commit order. During execution, the security device reads the current order from the page ownership value and reads the previous order corresponding to the previous page header value in the page chain record area. When the previous page header value is taken from the data partition initialization header value, the security device reads the initial order from the data partition initialization record as the previous order. The security device performs a binary increment operation on the previous order to obtain the verification order, and compares the verification order with the current order bit by bit. When the verification order is exactly the same as the current order, the security device confirms the candidate page header value output by S32 as the current page header value, which is then written to the programmed page sub-area and page chain record area by S34. If the verification order differs from the current order by any bit, the security device does not confirm the candidate page header value and writes the programmed page into the order disconnect record to avoid skipping the commit order into the data security page chain record. S34 enables the page chain header value to be read back during power failure recovery using the current sequence, and verifies the data protection against data replacement by using the page ownership value, written ciphertext, and page chain record. During execution, the security device writes the current page chain header value confirmed in S33 into the chain header record bit in the sub-area of ​​the programmed page, and uses the current sequence as the page chain record index to write the current page chain header value into the corresponding record bit in the page chain record area. At the same time, the index relationship between the page ownership value, the current sequence, and the current page chain header value is written into the page chain acceptance record. After writing, the security device updates the status record bit of the programmed page to the page chain accepted state, outputs the data security page chain record, and provides it for S4 to form the epoch sealing record and for S6 to read back during power failure recovery. If the current page chain header value fails to be written to the chain header record bit, or if a different page chain header value already exists in the page chain record area corresponding to the current sequence, the security device cancels the page chain accepted state and writes a page chain conflict record, so that the programmed page cannot be used as a recovery candidate page to enter the admission chain. Through the above implementation process, S3 advances the programmed page formed by S2 from the state of encrypted writing to the state of completed data security page chain acceptance: the written ciphertext is hashed segment by segment to form a ciphertext hash value, the page ownership value and the previous page chain head value form an ownership acceptance value, the candidate page chain head value becomes the current page chain head value after passing the current sequence verification, and finally it is written to the programmed page's auxiliary area and page chain record area; in this way, S4 can read the page chain head value corresponding to the last sequence of the original epoch code to form an epoch sealing record, and S6 can also read back the page chain head value through the current sequence and recalculate and verify after power failure and restart to determine whether the protected data has been impersonated by old pages, wrong pages or replacement pages; In practical applications: After the rail transit monitoring terminal writes a vibration event data into the NAND page data area, the safety device first reads and writes the encrypted text segment by segment according to the read bit width and generates the encrypted hash value. Then, it uses the previous page chain head value corresponding to the previous event to access the current page ownership value and the encrypted hash value to deduce the candidate page chain head value. If the current sequence happens to follow the previous sequence, the candidate page chain head value is confirmed as the current page chain head value and written into the NAND page sub-area. When power is lost and restored, as long as the recalculation result is inconsistent with the current page chain head value, the safety device will not allow the NAND page to enter the protection data reading path.

[0020] S4. When the partition dynamic key is updated, the security device reads the page head value corresponding to the last sequential position of the original epoch code, and recursively constructs the epoch sealing record using the original epoch code, the last sequential position, and the page head value, and replaces the original epoch code with the new epoch code. This implementation focuses on the epoch sealing and epoch succession process after the partition dynamic key update in S4. The purpose is to locate the last sequence number of pages already connected under the original epoch code before the original epoch code exits the protected data reading path. Then, an epoch sealing record is generated using the last sequence number pointer and the last page chain head value. Finally, a new epoch code is derived, and the original epoch code is written into the epoch failure bitmap. The epoch sealing record is not used for size comparison with the original epoch code, but rather to determine whether a candidate epoch code has expired during power-off recovery based on the original epoch code's hit relationship. The epoch failure bitmap is used to quickly block the page encryption key call corresponding to the original epoch code. This implementation process includes the following steps: S41 provides a definite sealing end for the epoch sealing record, preventing uncertainty during dynamic key updates about which commit order the original epoch code has been written to. During execution, the security device receives the partition dynamic key update command and reads the partition ownership code and the original epoch code from it. The original epoch code is the epoch code for which the corresponding partition ownership code was active before the partition dynamic key update command was triggered. The security device reads the epoch page chain index area using the original epoch code, obtains the end-order pointer corresponding to the original epoch code, and then uses the end-order pointer to index the corresponding record in the page chain record area, reading the corresponding record. The page chain head value is written as the last page chain head value, which is used by S42 to generate the epoch sealing value. If the epoch page chain index area does not have the end sequence pointer corresponding to the original epoch code, it means that no programmed page has been formed under the original epoch code. The security device uses the original epoch code to access the empty sequence identifier, and then accesses the data partition initialization chain head value to generate the empty epoch last page chain head value, and uses the empty sequence identifier as the end sequence pointer. If the end sequence pointer exists but the corresponding record is missing in the page chain record area, the security device stops the generation of the epoch sealing value and writes the epoch page chain index abnormal record to prevent the original epoch code with missing page chain head value from entering the succession process. S42 involves compressing the original epoch code, the end-of-order pointer, and the last-page-head value into a failure boundary that can be verified during the recovery phase. During execution, the security device writes the original epoch code obtained in S41 into the first segment of the sealing buffer, the end-of-order pointer into the middle segment of the sealing buffer, and the last-page-head value into the last segment of the sealing buffer. It then performs hash recursion on the first, middle, and last segments of the sealing buffer in the order they were written to generate the epoch sealing value. Subsequently, the security device uses the original epoch code, the end-of-order pointer, and the epoch sealing value as the same epoch sealing record. The epoch sealing record area is written for S6 to retrieve during power-off recovery. When S6 determines that the epoch code has been sealed, it searches the original epoch code field in the epoch sealing record using the candidate epoch code. If the original epoch code field is matched, it indicates that the candidate epoch code has exited the effective state, rather than sorting or comparing the candidate epoch code with the epoch sealing value. If the epoch sealing record area writing fails, the security device does not allow the generation of a new epoch code and writes the partition dynamic key update instruction to the unsealed record to prevent the generation of a new epoch code when the original epoch code is not sealed. S43 ensures that subsequent page-level encryption of protected data only calls the page encryption key corresponding to the new epoch code, and prevents the original epoch code from re-entering the protected data reading path. During execution, the security device uses the epoch sealing value generated in S42 as the input for generating the new epoch, and performs hash derivation by incorporating the internal hardware entropy value of the security device into the epoch sealing value to obtain the new epoch code. The security device reads the epoch head value from the epoch succession chain tail record, incorporates the epoch head value into the new epoch code, and then incorporates the partition ownership code to perform hash recursion, generating the new epoch head value. The new epoch code and the new epoch head value are written to the epoch succession chain tail, so that S12 can subsequently read the new epoch code as the effective epoch through the chain tail pointer. The security device also performs hashing on the original epoch code to obtain the epoch failure bitmap index and writes a failure flag at the epoch failure bitmap index. When the subsequent protection data reading process reads the original epoch code, it first hits the epoch failure bitmap index using the same hashing method, and then reads back the original epoch code field in the epoch sealing record to complete the confirmation. After confirmation, the page encryption key corresponding to the original epoch code is no longer called. If the new epoch code is the same as an existing epoch code in the epoch succession chain, the security device rereads the internal hardware entropy value and performs hash derivation again. If the epoch failure bitmap writing fails, the security device withdraws the new epoch code writing result at the end of the epoch succession chain and generates an epoch failure flag failure record. Through the above implementation process, S4 transforms the partition dynamic key update from simply replacing the key identifier into an epoch sealing and epoch succession process that can be read by subsequent writes, page chain recursion, and power-down recovery: S41 locates the last page chain head value under the original epoch code, S42 forms an epoch sealing record containing the original epoch code, the end sequence pointer, and the epoch sealing value, and S43 derives the new epoch code and writes the original epoch code into the epoch failure bitmap; thus, when S2 subsequently calls the page encryption key, it reads the new epoch code, and when S6 reads a candidate epoch code that hits the epoch sealing record or the epoch failure bitmap during power-down recovery, it can write the corresponding NAND page into the rejection chain instead of reattaching it to the current data partition; In practical applications: After completing a certain inspection cycle, the outdoor data acquisition terminal triggers a dynamic key update for the event evidence partition. The security device first finds the end-order pointer corresponding to the original epoch code from the epoch page chain index area, then uses the end-order pointer to read back the last page chain head value, and then hashes and recursively deduces the original epoch code, the end-order pointer, and the last page chain head value to form the epoch sealing value. After the new epoch code is generated and written to the end of the epoch succession chain, the original epoch code is synchronously written to the epoch failure bitmap. Even if the power is lost and the NAND page under the original epoch code is scanned, the security device will no longer call the page encryption key for the original epoch code, thereby preventing the data page corresponding to the original epoch code from participating in the protection data reading again.

[0021] When S5 and FTL move a programmed page, the security device reads the source NAND page ownership value and page chain head value, and after recursively verifying them through the hash chain integrity verification algorithm, it submits the target NAND page to the source page ownership value in the order of submission and outputs the target page chain head value. This implementation focuses on the page chain succession process during FTL relocation of programmed pages in S5. Its purpose is to first recalculate the page chain head value of the source NAND page to confirm that the source NAND page has not been replaced when a programmed page is moved from the source NAND page to the target NAND page due to garbage collection, wear leveling, or bad block replacement. Then, it generates the target commit order and ensures that the target page ownership value, source encrypted hash value, and source page chain head value all participate in the target page chain head value recursion. After the target page chain head value is generated, it is written to the target NAND page's subordinate area, and the old mapping entry of the source NAND page is written to an invalid state, ensuring that subsequent power-down recovery can only read the chain succession result of the target NAND page. This implementation process includes the following steps: S51 involves retrieving the source page ownership value and source page chain head value from the source NAND page specified by the migration instruction, forming the source page verification input required for subsequent recalculation and verification. During execution, after generating the programmed page migration instruction, the FTL sends the source NAND page address in the migration instruction to the security device. The security device reads the source NAND page supplementary area based on the source NAND page address. The source NAND page supplementary area is configured with an ownership record bit and a chain head record bit. The ownership record bit stores the source page ownership value, and the chain head record bit is located after the end of the ownership record bit and stores the source page chain head. The security device first reads the source page ownership value from the ownership record bit, then reads the source page chain head value from the chain head record bit, and writes the source page ownership value and the source page chain head value into the source page verification cache. It outputs the source page verification input for S52 to read the source commit order and calculate the source ciphertext hash value. If the ownership record bit is empty, the chain head record bit is empty, or the length of the source page ownership value field is inconsistent with the page ownership field configuration area, the security device stops the transfer acceptance and writes the source NAND page address into the transfer rejection record to prevent the source NAND page without page chain basis from entering the target page chain head value recursion. S52 involves obtaining the source commit order from the source page ownership value, reading back the previous page head value using the source commit order, and simultaneously converting the source ciphertext in the source NAND page data area into a source ciphertext hash value. During execution, the security device extracts the source commit order from the source page ownership value obtained in S51, performs a binary subtraction operation on the source commit order to obtain the previous commit order, and uses the previous commit order to index the page chain record area, reading back the previous page head value. When the previous commit order is the data partition initialization order, the security device reads the data partition initialization head value as the previous page head value. Subsequently, the security device reads the source page data segment by segment according to the page readout bit width. In the NAND page data area, the first ciphertext segment enters the hash compressor to generate the first hash value. The subsequent ciphertext segment is then appended to the previous hash value and enters the hash compressor again, until the unread length of the source NAND page data area reaches zero, at which point the source ciphertext hash value is output. If the length of the last ciphertext to be read is less than the read bit width within the page, the security device participates in hash compression according to the length of the last ciphertext to be read. If the previous commit order cannot index the page chain record area and there is no data partition initialization chain head value, or if the source NAND page data area read fails, the security device stops the output of the source ciphertext hash value and writes the source NAND page address into the move rejection record. S53 involves confirming that the source NAND page still follows the existing page chain, then incorporating the target commit order into the target page ownership value, and binding the target page chain head value to both the target page ownership value and the source ciphertext hash value. During execution, the security device uses a hash chain integrity verification algorithm to connect the previous page chain head value obtained in S52 to the source page ownership value obtained in S51, and then to the source ciphertext hash value obtained in S52, recursively generating the source page recalculated chain head value. When the source page recalculated chain head value is the same as the source page chain head value obtained in S51, the security device reads the target NAND page address and performs a binary increment operation on the FTL commit order register bit to obtain the target commit order. The security device replaces the source commit order in the source page ownership value with the target commit order to form the target page ownership value, and first connects the source page chain head value to the target page ownership value. The target page chain head value is generated by refactoring the hash value of the source ciphertext and then performing hash recursion on the source ciphertext hash value. If the source ciphertext is re-encrypted during the migration process to form the target ciphertext, the security device replaces the source ciphertext hash value with the target ciphertext hash value in the target page chain head value recursion. After the target page chain head value is generated, the security device writes the target page ownership value into the ownership record bit of the target NAND page subsidiary area, writes the target page chain head value into the chain head record bit of the target NAND page subsidiary area, and writes the target commit order and the target page chain head value into the page chain record area. At the same time, the old mapping entry of the source NAND page is written to the invalid state. If the recalculated chain head value of the source page is different from the source page chain head value, the security device does not generate the target commit order, does not write the target page ownership value and the target page chain head value, and writes the source NAND page address into the migration verification failure record. Through the above implementation process, S5 makes the FTL migration operation no longer just copy the programmed page from the source NAND page to the target NAND page. Instead, it first recalculates the source page chain head value using the source page ownership value, the previous page chain head value, and the source ciphertext hash value. Then, it adds the target commit order to the source page ownership value to form the target page ownership value. Finally, it generates and writes the target page chain head value. In this way, the source NAND page no longer retains a valid service attachment entry after the migration is completed. The target NAND page carries the new target page ownership value and target page chain head value, which are used by S6 to scan the target NAND page sub-area and perform monotonic sequence alignment when the power is off. In practical applications: When industrial gateway SSDs are undergoing background wear leveling, a programmed page from the log partition needs to be moved from a source NAND page with high wear to a target NAND page. The security device first reads back the source page ownership value and source page chain head value from the source NAND page's sub-area, then reads the source NAND page's data area to generate the source encrypted hash value. Only after the recalculation result matches the source page chain head value is the target commit order generated, and the target page ownership value and target page chain head value are written to the target NAND page's sub-area. If the recalculation result is inconsistent, the migration process stops immediately, and the source NAND page will not be written to the new FTL mapping relationship, thereby preventing replaced or damaged protection data from entering the subsequent recovery attachment path.

[0022] S6. After a power outage and restart, the security device scans the recovery candidate page sub-area. Starting from the recovery checkpoint sequence, it checks the candidate page sequence bit by bit using the monotonic sequence alignment algorithm. If the sequence is accepted and the epoch code is the same as the effective epoch code, it is written into the admission chain. If the sequence cannot be accepted or the epoch code is closed, it is written into the rejection chain. The FTL mapping relationship is reconstructed based on the admission chain, the rejection chain business attachment entry is cut off, and the partition recovery mapping table is output. This implementation focuses on the partition recovery mapping table generation process after a power failure and restart in S6. Its purpose is to not only retrieve NAND pages based on the FTL recovery log after an abnormal restart of the solid-state drive, but also to read the page ownership value, candidate page order, candidate epoch code, logical page number, and page chain head value from the supplementary area of ​​the recovery candidate page using a security device. Combined with the recovery checkpoint order, epoch sealing record, and monotonic sequence alignment algorithm, NAND pages with order rollback, order break, epoch failure, inconsistent page chain head values, or conflicts with the same logical page number are filtered out, preventing the protected data under the failed epoch code from regaining its service access point. Recovery candidate pages are NAND pages whose page ownership value and page chain head value can be read from the supplementary area and whose NAND page status record bit is not in an erased state. NAND pages whose supplementary area is unreadable, whose page ownership value field length is mismatched, or whose page chain head value is missing are directly written to the rejection chain. This implementation process includes the following steps: S61 transforms the NAND pages that can be scanned after a power failure and restart into a recovery candidate sequence with page ownership values, candidate page order, candidate epoch codes, and logical page numbers, for S62 to perform monotonic order alignment. During execution, the security device reads the recovery checkpoint order from the recovery checkpoint record and writes it as the current successor order. The recovery checkpoint order is written to a non-volatile record by the security device after the FTL mapping is committed. Subsequently, the security device scans the recovery candidate page sub-area, reads the page ownership value and page chain head value page by page, and aligns the results according to the page ownership field. The configuration area extracts the partition ownership code, candidate epoch code, candidate page order, and logical page number from the page ownership value. The logical page number is written to the NAND page sub-area by S2 and participates in the page chain head value recursion. After reading, the security device merges and restores candidate pages according to the partition ownership code, and arranges them in ascending order under the same partition ownership code, outputting the restored candidate sequence for S62 to check bit by bit. If the page ownership value cannot extract the candidate page order, candidate epoch code, or logical page number, the security device writes the corresponding restored candidate page into the rejection chain, and does not allow the restored candidate page to enter the acceptance path. S62 corresponds to the page-by-page continuation check process of the monotonic sequence alignment algorithm. Its function is to establish a sequentially increasing relationship between the candidate page order in the restored candidate sequence and the restored checkpoint order, eliminating residual pages from old checkpoints, skipped pages, and backtracked pages. During execution, the security device uses the restored candidate sequence output by S61 as input and the current continuation order as the alignment starting point. For each candidate page in the restored candidate sequence, the security device subtracts the current continuation order from the candidate page order to generate a sequence difference. When the sequence difference equals one, the candidate page order satisfies the sequentially increasing continuation constraint, and the security device writes the candidate page. The system takes the receiving path and replaces the current receiving order with the candidate page order for the next candidate page to continue calculation. When the order difference is less than one, the security device writes the candidate page into the back page record in the deviation path. When the order difference is greater than one, the security device writes the candidate page into the skip page record in the deviation path. The deviation cost is obtained by accumulating the number of candidate pages with order differences not equal to one during the page-by-page check. A deviation cost of zero indicates that no order deviation has occurred in the restored candidate sequence after the current checkpoint. A deviation cost of non-zero indicates that at least a back page or a skip page exists. Finally, the receiving path and the deviation path are output. When a candidate page is accessed through an off-path, the current acceptance order is not updated with the candidate page's order. The security device continues to check the order of subsequent candidate pages with the unupdated current acceptance order, so that candidate pages located after the off-path candidate pages within the same recovery check segment and unable to meet the bit-by-bit acceptance constraint are continuously written into the off-path until the next recovery checkpoint order is read and the current acceptance order is re-established. S63 further restricts the candidate pages that have already been accepted to the current effective epoch code, preventing old NAND pages under the original epoch code from entering the pending chain through sequential acceptance. During execution, the security device reads the candidate epoch codes page by page in the acceptance path and reads the effective epoch code that has been verified in S12. The bit lengths of the candidate epoch code and the effective epoch code are given by the page ownership field configuration area. After the two bit lengths are the same, the security device performs a bitwise XOR operation on the candidate epoch code and the effective epoch code, and adds all the XOR bits to form an XOR sum. An XOR sum of zero indicates a candidate epoch. The candidate epoch code is identical bit-by-bit to the effective epoch code. An XOR and non-zero result indicate that at least one bit of the candidate epoch code is different. When the XOR sum is zero, the security device continues to search the original epoch code field in the epoch sealing record using the candidate epoch code. If the candidate epoch code does not match the original epoch code field, it is written to the pending link; if the candidate epoch code matches the original epoch code field, it is written to the rejection pre-link. When the XOR and non-zero result are both zero, the security device writes the corresponding candidate page to the rejection pre-link. Thus, the epoch code is determined to be sealed by matching the original epoch code field in the epoch sealing record, without performing a size comparison between the candidate epoch code and the epoch sealing value. S64 involves selecting NAND pages from the chain to be attached that represent the current valid state of the same logical page number, excluding candidate pages with mismatched page header values, old version remnants, and same-order conflicts. During execution, the security device reads the logical page number of each candidate page based on the chain to be attached and forms a candidate group for the same page according to the logical page number. For each candidate page within the same candidate group, the security device reads the page ownership value and page header value from the candidate page's subordinate area, generates a ciphertext hash value according to S31, and re-executes the page header value recursion according to S32 to generate a recalculated page header value. When the chain head value differs from the chain head value of the candidate page's subordinate area page, the security device writes the corresponding candidate page into the rejection pre-chain; candidate pages with the same chain head value are retained in the same page candidate group; subsequently, the security device arranges the retained candidate pages in the same page candidate group from high to low according to the candidate page priority, writes the first candidate page into the admission chain, and writes the remaining candidate pages into the rejection pre-chain; if there are two candidate pages with the same candidate page priority in the same page candidate group, the security device writes both candidate pages into the rejection pre-chain and generates a priority conflict record to prevent two recovery entries from appearing for the same logical page number; S65 involves uniformly isolating the NAND pages excluded by S62 to S64, and generating the restored logical page number to NAND page mapping relationship based solely on the admission chain. During execution, the security device merges off-path, rejected pre-chain, page ownership value field anomaly records, page chain head value missing records, and same-order conflict records to form a rejection chain, and writes each NAND page address in the rejection chain into the isolation record area. For NAND pages in the admission chain, the security device reads the logical page number and NAND page address, generates an FTL mapping entry from logical page number to NAND page address, and sets the FTL to the correct FTL value. The L mapping entry is written to the partition recovery mapping table; for NAND pages in the rejection chain, the security device does not generate an FTL mapping entry, does not call the page encryption key corresponding to the candidate epoch code, and returns a read failure status when the host read request hits the NAND page address in the isolation record area, thereby cutting off the protected data read access point of the NAND page in the rejection chain; if a candidate page corresponding to a certain logical page number is missing in the admission chain, the security device writes a record of missing logical page number in the partition recovery mapping table and waits for the upper-layer file recovery process to process it, without retrieving the NAND page from the rejection chain; Through the above implementation process, S6 transforms power failure recovery from simply rebuilding the mapping based on FTL logs into a recovery control process that involves obtaining evidence based on page ownership value, aligning by commit sequence, verifying the effective status by candidate epoch code, recalculating and confirming that protected data has not been replaced by page chain head value, and resolving intra-page conflicts by logical page number. The recovery checkpoint sequence is used to limit the starting point of the recovery sequence, the epoch sealing record is used to identify the original epoch code that has been exited, the admission chain is used to form the partition recovery mapping table, and the rejection chain is used to block the service attachment entry of old epoch pages, out-of-order pages, and replacement pages. In practical applications: When a vehicle recording device suddenly loses power and restarts while driving, the security device first scans the recovery candidate page sub-area corresponding to the event evidence partition, reads the candidate page sequence, candidate epoch code, and logical page number from the page ownership value, and performs monotonic sequence alignment according to the candidate page sequence increasing. Candidate pages with reversed sequence are written to the off-path, candidate pages whose candidate epoch code matches the epoch sealing record are written to the rejection pre-chain, and candidate pages with inconsistent page chain head values ​​under the same logical page number are also written to the rejection pre-chain. Ultimately, only NAND pages with sequence succession, still valid epoch, consistent page chain head values, and valid sequence within the same logical page number enter the admission chain. The security device then rebuilds the partition recovery mapping table accordingly, preventing old event data that has exited the epoch code from re-entering the protected data reading path.

[0023] Working Principle: After receiving a write request from the solid-state drive (SSD), this solution first uses a security device to determine the partition to which the data belongs based on the page number to be written, obtains the active key epoch for that partition, and generates the write priority for this operation. Then, page ownership information is formed using the partition ownership, key epoch, and write priority. A page encryption key is derived from this key epoch, and the data is encrypted and written to the NAND page. The page ownership information is also written to the NAND page's secondary area. After the write operation is complete, the solution continues to recursively calculate the current page's chain head value using the previous page's chain head value, page ownership information, and ciphertext hash value, ensuring that each page of data... All of these methods can prove the partition's origin, key epoch, and write order. When changing the partition key, the scheme uses the last order of the original key epoch and the last page head value to form an epoch sealing record before enabling the new key epoch. When moving data pages in FTL, the source page head value is recalculated first, and the target page head value is generated only after it is confirmed to be correct. After a power failure and restart, the scheme checks the candidate page order according to the recovery checkpoint order, combines the epoch sealing record and the page head value recalculation results to screen out the admission pages, and isolates old epoch pages, out-of-order pages, and pages that failed verification. Finally, the partition recovery mapping table is rebuilt only based on the admission pages. For example, in vehicle recording devices, solid-state drives (SSDs) simultaneously store driving videos, accident event data, and system logs. If a vehicle experiences a sudden power outage and restarts while driving, traditional recovery processes may try to retrieve the old mappings, resulting in old event pages that have been invalidated due to key changes being re-attached to the partition. This solution, during recovery, first reads the partition ownership, key epoch, write order, and page chain head value from the sub-area of ​​each candidate NAND page to determine whether the page is a recovery checkpoint, whether it still belongs to the currently effective key epoch, and whether the page chain head value can be recalculated from the ciphertext and ownership information. Only NAND pages that pass all checks are entered into the recovery mapping table. Old pages with sealed original key epochs, residual pages with reversed order, and abnormal pages with inconsistent page chain recalculations are written into the rejection chain and the read entry is cut off, thus preventing power-down recovery from restoring invalidated data into readable data.

[0024] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A data partitioning storage and dynamic key management method based on solid-state drives, characterized in that, include: S1. After obtaining the host write request, the security device reads the partition whose page number is matched, deciphers the partition ownership code, retrieves the effective epoch code, increments the previous commit order of the FTL by one to generate the current order, and outputs the write acceptance value. S2. Based on the written acceptance value, the security device calls the page encryption key to perform protection data page-level encryption to form ciphertext, and concatenates the partition ownership code, effective epoch code and current sequence number into the page ownership value, writes it into the NAND page sub-area, and generates a programmed page. S3. For a programmed page, the hash chain integrity verification algorithm reads the chain head value of the previous page, recursively calculates the chain head value of the current page by combining the chain head value of the previous page, the page ownership value, and the ciphertext hash value, and outputs the data security page chain record. S4. When the partition dynamic key is updated, the security device reads the page head value corresponding to the last sequential position of the original epoch code, and recursively constructs the epoch sealing record using the original epoch code, the last sequential position, and the page head value, and replaces the original epoch code with the new epoch code. When S5 and FTL move a programmed page, the security device reads the source NAND page ownership value and page chain head value, and after recursively verifying them using the hash chain integrity verification algorithm, it submits the target NAND page to the source page ownership value in the order of submission and outputs the target page chain head value.

2. The data partitioning storage and dynamic key management method based on solid-state drives according to claim 1, characterized in that: Also includes: S6. After a power outage and restart, the security device scans the recovery candidate page sub-area. Starting from the recovery checkpoint sequence, it checks the candidate page sequence bit by bit using a monotonic sequence alignment algorithm. If the sequence is accepted and the epoch code is the same as the effective epoch code, it is written into the admission chain. If the sequence cannot be accepted or the epoch code is blocked, it is written into the rejection chain. The FTL mapping relationship is reconstructed based on the admission chain, the rejection chain service attachment entry is cut off, and the partition recovery mapping table is output.

3. The data partitioning storage and dynamic key management method based on solid-state drives according to claim 2, characterized in that: S1 includes: S11. Obtain the write start page number in the host write request, read the partition boundary table through the security device set in the solid-state drive controller, and generate the start page difference value by subtracting the boundary start page number of each partition boundary entry from the write start page number. Then generate the end page difference value by subtracting the write start page number from the boundary end page number of each partition boundary entry. Take the partition boundary entry with both the start page difference value and the end page difference value as the hit boundary entry, and output the partition ownership code corresponding to the hit boundary entry. S12. Based on the partition ownership code index epoch succession chain, read the last record pointed to by the chain tail pointer, and connect the previous chain head value in the last record to the epoch code in the last record. Then connect the epoch code to the partition ownership code and perform hash recalculation to generate the recalculated chain head value. When the recalculated chain head value is the same as the epoch chain head value in the last record, output the epoch code in the last record as the effective epoch code. S13. Read the previous commit order from the FTL commit order register, perform a binary increment operation on the previous commit order to form the current order, write the partition ownership code into the first segment of the accepting cache, write the effective epoch code into the middle segment of the accepting cache, write the current order into the effective epoch code into the last segment of the accepting cache, and output the written accepting value.

4. The data partitioning storage and dynamic key management method based on solid-state drives according to claim 3, characterized in that: S2 includes: S21. Based on the field length boundary of the accepted value, extract the partition ownership code from the first segment of the accepted cache, extract the effective epoch code from the fixed length of the last bit of the partition ownership code, extract the current sequence number from the remaining bits after the last bit of the effective epoch code, and reassemble the three segments into a page ownership check string in the original position order, and output the page ownership value. S22. Based on the page ownership value, read the epoch key material bound to the effective epoch code, connect the epoch key material to the partition ownership code, and then connect it to the current sequential execution of the same-order concatenation hash. Take the leftmost bit of the hash result that is the same as the page key length to generate the page encryption key, and use the page encryption key to perform page-level encryption on the written data, and output the written ciphertext. S23. Perform secondary area address mapping with the page ownership check string and the page write address of the ciphertext, write the ciphertext to the NAND page data area, write the page ownership check string to the record bit in the secondary area of ​​the NAND page bound to the data area address, and output the programmed page.

5. The data partitioning storage and dynamic key management method based on solid-state drives according to claim 4, characterized in that: S3 includes: S31. Read the data area of ​​the programmed page segment by segment according to the page read bit width, so that the first segment of ciphertext enters the hash compressor to generate the first segment hash value, so that the next segment of ciphertext is connected to the previous segment hash value and enters the hash compressor again, until the unread length in the page is zero and the ciphertext hash value is output. S32. Read the previous page's chain head value using the hash chain integrity verification algorithm, first connect the previous page's chain head value to the page ownership value to generate the ownership successor value, then connect the ownership successor value to the ciphertext hash value to perform one-way hash recursion, and output the candidate page chain head value.

6. The data partitioning storage and dynamic key management method based on solid-state drives according to claim 5, characterized in that: S3 also includes: S33. Read the current sequence number in the page ownership value and read the previous sequence number corresponding to the previous page head value. Perform an increment operation on the previous sequence number to obtain the verification sequence number. When the verification sequence number is the same as the current sequence number, confirm the candidate page head value as the current page head value. S34. Write the current page chain header value into the sub-area of ​​the programmed page, and use the current sequence as the page chain record index to write the current page chain header value, so that when power is lost and restored, the current page chain header value can be read back from the current sequence and the protection data can be verified to be unaltered, and the data security page chain record is output.

7. The data partitioning storage and dynamic key management method based on solid-state drives according to claim 6, characterized in that: S4 includes: S41. After the partition dynamic key update is triggered, the security device reads the epoch page chain index area with the original epoch code, obtains the end sequence pointer corresponding to the original epoch code, and reads the same-position record in the page chain record area with the end sequence pointer, and writes the page chain head value in the same-position record as the last page chain head value. S42. Write the original epoch code into the first segment of the sealing buffer, write the end sequence pointer into the middle segment of the sealing buffer, write the last page head value into the last segment of the sealing buffer, perform hash recursion on the sealing buffer, generate the epoch sealing value, and write the original epoch code, end sequence pointer and epoch sealing value into the epoch sealing record. S43. Using the epoch sealing value as the input for generating the new epoch, perform hash derivation to obtain the new epoch code. Write the new epoch code to the end of the epoch succession chain and write the original epoch code to the epoch failure bitmap so that subsequent protection data reading no longer calls the page encryption key corresponding to the original epoch code. Output the epoch succession record.

8. The data partitioning storage and dynamic key management method based on solid-state drives according to claim 7, characterized in that: S5 includes: S51, after FTL generates the programmed page move instruction, it reads the source NAND page sub-area according to the source NAND page address in the move instruction, first reads back the source page ownership value from the sub-area ownership record bit, then reads back the source page chain head value from the chain head record bit after the end of the ownership record bit, and outputs the source page verification input. S52. Extract the source commit order from the source page ownership value, perform a decrement operation on the source commit order to obtain the previous commit order, and use the previous commit order to index the page chain record area to read back the previous page chain head value. Then, read the source NAND page data area segment by segment according to the page read bit width, so that the first segment of ciphertext generates the first segment hash value, the next segment of ciphertext is appended to the previous segment hash value and hashed again, until the unread length is zero, and output the source ciphertext hash value. S53. Using the hash chain integrity verification algorithm, the previous page chain head value is connected to the source page ownership value and then to the source ciphertext hash value. The source page recalculated chain head value is generated recursively. When the source page recalculated chain head value is the same as the source page chain head value, the FTL commit order register bit is incremented by one to obtain the target commit order. The target commit order is then used to replace the source commit order in the source page ownership value, and the target page chain head value is generated recursively.

9. The data partitioning storage and dynamic key management method based on solid-state drives according to claim 8, characterized in that: S6 includes: S61. After power failure and restart, the security device uses the recovery checkpoint sequence as the current successor sequence, scans the recovery candidate page sub-area, reads the page ownership value page by page, extracts the candidate page sequence from the end of the page ownership value, extracts the candidate epoch code from the middle of the page ownership value, and outputs the recovery candidate sequence. S62. Using the recovered candidate sequence as input, the candidate page order is subtracted from the current acceptance order to generate an order difference through the monotonic sequence alignment algorithm. The number of times the order difference is not equal to one is used as the deviation cost. The order is incremented by one as the acceptance constraint. When the deviation cost is zero, the candidate page is connected to the acceptance path and the candidate page order is used to replace the current acceptance order. When the deviation cost is non-zero, the candidate page is connected to the deviation path. The acceptance path and the deviation path are output. S63. For candidate pages in the succession path, read the candidate epoch code and perform a bitwise XOR sum with the effective epoch code. If the XOR sum is zero and the candidate epoch code has no match in the epoch sealing record, write it into the pending link chain. If the XOR sum is non-zero or the candidate epoch code matches in the epoch sealing record, write it into the rejection pre-link chain. Output the pending link chain and the rejection pre-link chain.

10. The data partitioning storage and dynamic key management method based on solid-state drives according to claim 9, characterized in that: S6 also includes: S64. Based on the chain to be attached, form a candidate group of the same page according to the logical page number. Re-execute the page chain head value recursive verification for the candidate pages in the candidate group of the same page. Delete the candidate pages whose recalculated page chain head value is different from the page chain head value of the page attached area. Then, take the first candidate page in the candidate page order from high to low and write it into the admission chain. Write the remaining candidate pages into the rejection pre-chain and output the admission chain. S65. Merge the off-path and the rejection pre-chain to form a rejection chain, reconstruct the FTL mapping relationship from the logical page number to the NAND page based on the admission chain, and cut off the protection data read access entry of the NAND page in the rejection chain through the security device, and output the partition recovery mapping table.

Images