Database page integrity verification method and system based on national secret algorithm and medium

Abstract

This application discloses a database page integrity verification method, system, and medium based on Chinese national cryptographic algorithms, belonging to the field of database technology. It addresses the limitations of existing database page verification methods in effectively resisting malicious attacks and suffers from compatibility issues. The method includes: determining a verification value storage area within the data page; the verification value storage area is located at the end of the data page; invoking the SM3 cryptographic hash algorithm to perform continuous hash update calculations on the page content excluding the verification value storage area to obtain a first SM3 verification value; writing the first SM3 verification value into the verification value storage area; responding to a verification command, invoking the SM3 cryptographic hash algorithm to recalculate the page content excluding the verification value storage area to obtain a second SM3 verification value; and comparing the second SM3 verification value with the first SM3 verification value in the verification value storage area to determine the integrity of the data page based on the comparison result.

Description

Technical Field

[0001] This application relates to the field of database technology, and in particular to a database page integrity verification method, system, and medium based on Chinese national cryptographic algorithms. Background Technology

[0002] PostgreSQL, a widely used open-source relational database, uses data pages as the basic unit for data storage and access. Each data page contains a page header (PageHeaderData), data areas (ItemIds and Tuples), and a pd_special area at the footer.

[0003] PostgreSQL's native page integrity check mechanism uses a cyclic redundancy check (CRC) algorithm. Specifically, before a page is written to disk, the system calculates the CRC-32C checksum of the data page and stores it in the page header structure. After reading the page from disk, the CRC value is recalculated and compared with the stored value to detect data corruption caused by non-malicious reasons such as hardware failure or disk errors.

[0004] However, with increasingly stringent data security requirements, especially in critical information sectors such as finance, existing technical solutions have significant shortcomings. First, the CRC algorithm itself lacks cryptographic collision resistance. Its design is intended to detect random or accidental errors, and it cannot effectively defend against malicious attackers deliberately constructing forged pages with identical CRC values, thus allowing data tampering to go undetected. Second, with the promulgation of network security regulations, CRC verification mechanisms cannot meet the requirement of prioritizing the use of national cryptographic algorithms. Furthermore, directly modifying the fixed structure of the database header to support national cryptographic algorithms would change the physical storage format of the database. Data files created using older versions would then be difficult to migrate smoothly using standard upgrade tools, leading to compatibility issues and making project implementation challenging. Summary of the Invention

[0005] This application provides a database page integrity verification method, system, and medium based on national cryptographic algorithms to solve the following technical problems: existing database page verification methods are difficult to effectively resist malicious attacks, and if the fixed structure of the database page header is directly modified to support national cryptographic algorithms, the physical storage format of the database will be changed. At this time, data files created using old versions will be difficult to migrate smoothly through standard upgrade tools, resulting in compatibility issues and making project implementation difficult.

[0006] The embodiments of this application adopt the following technical solutions: This application provides a database page integrity verification method based on Chinese national cryptographic algorithms. The method includes: acquiring a data page from the database to be written to a storage device, and identifying a verification value storage area within the data page; wherein the verification value storage area is located at the end of the data page; invoking the SM3 cryptographic hash algorithm to perform continuous hash update calculations on the page content excluding the verification value storage area to obtain a first SM3 verification value; writing the first SM3 verification value to the verification value storage area, and then writing the data page to the storage device; responding to a verification command, reading the data page from the storage device, invoking the SM3 cryptographic hash algorithm again to recalculate the page content excluding the verification value storage area to obtain a second SM3 verification value; and comparing the second SM3 verification value with the first SM3 verification value in the verification value storage area to determine the integrity of the data page based on the comparison result.

[0007] In one implementation of this application, determining the check value storage area in the data page specifically includes: using the pd_special area of ​​the data page as a reference area; determining the page type of the data page; if the data page is a heap table page, expanding the reference area so that the expanded area is not less than the byte length of the SM3 check value to obtain the check value storage area; if the data page is an index page, keeping the original stored data corresponding to the reference area unchanged, and expanding the tail of the reference area so that the tail expansion area is not less than the byte length of the SM3 check value to obtain the check value storage area.

[0008] In one implementation of this application, before calling the SM3 cryptographic hash algorithm to perform continuous hash update calculations on the page content excluding the check value storage area in the data page, the method further includes: calling a first function to determine whether the page integrity verification function based on the national cryptographic algorithm is enabled; if enabled, calling a second function to determine whether the page type of the data page supports the national cryptographic algorithm verification; if not supported, calling the original cyclic redundancy check algorithm to calculate and verify the data page, and writing the check value to a specified position in the header of the data page; if supported, calling the SM3 cryptographic hash algorithm to perform the calculation.

[0009] In one implementation of this application, the SM3 cryptographic hash algorithm is invoked to continuously update the hash of the page content excluding the check value storage area in the data page to obtain the first SM3 check value. Specifically, this includes: adding the extended total length of the pd_special region to the read position and subtracting the byte length of the SM3 check value to obtain the read position of the check value storage area; dividing the page content of the data page into a first data block and a second data block with the check value storage area as the boundary; wherein the first data block is the data from the beginning of the page body to the read position, and the second data block is the data from the read position to the end of the page body; skipping the check value storage area, the contents of the first data block and the second data block are accumulated to generate the first SM3 check value.

[0010] In one implementation of this application, skipping the check value storage area and accumulating the contents of the first data block and the second data block to generate a first SM3 check value specifically includes: if a data page is detected to be marked as high security level, obtaining the read address corresponding to the data page, the end address of the page header area, and the read position of the check value storage area; performing national cryptographic hash calculation on the byte sequence of multiple addresses based on a preset order to obtain a key; determining a dynamic segmentation point based on the numerical characteristics of the header bytes corresponding to the intermediate hash digest obtained after accumulation calculation, and the offset of the start address of the check value storage area relative to the end of the page; dividing the intermediate hash digest into a front data segment and a rear data segment based on the dynamic segmentation point; performing a block cipher-based obfuscation operation on the front data segment and the rear data segment respectively based on the key to obtain a first obfuscated block and a second obfuscated block; performing a bitwise XOR operation on the first obfuscated block and the second obfuscated block to obtain a folding result; and calling the SM3 cryptographic hash algorithm to calculate the folding result to obtain the first SM3 check value.

[0011] In one implementation of this application, after reading the data page from the storage device, the method further includes: calling a third function to determine whether the national cryptographic algorithm verification is enabled; if enabled, calling a fourth function to read the flag bit in the data page header to determine whether the data page already contains the national cryptographic verification value; if the data page already contains the national cryptographic verification value, then calling the SM3 cryptographic hash algorithm to recalculate the other data in the data page except for the verification value storage area to obtain the second SM3 verification value.

[0012] In one implementation of this application, when entering enhanced security mode in response to a security policy, the first SM3 checksum is written to the checksum storage area. Specifically, this includes: obtaining the salt value corresponding to the previous data page adjacent to the current data page's physical address, using it as the predecessor salt value; concatenating the predecessor salt value, the current data page's physical address, and the current database timestamp; and calling the SM3 cryptographic hash algorithm to calculate the concatenation result to generate a chained salt value corresponding to the current data page; wherein the chained salt value is stored in a specified field in the fixed-format header area of ​​the current data page; using the chained salt value as input to a verification delay function to generate a corresponding delayed credential and its verification proof; generating a context binding code through a preset mapping rule and the chained salt value; associating and combining the first SM3 checksum, the verification proof corresponding to the delayed credential, and the context binding code; calculating an SM3 cryptographic hash on the combination result to obtain a 32-byte enhanced integrity checksum, and writing the enhanced integrity checksum to the checksum storage area.

[0013] In one implementation of this application, after comparing the second SM3 checksum with the first SM3 checksum in the checksum storage area, the method further includes: if the second SM3 checksum is inconsistent with the first SM3 checksum in the checksum storage area, generating a cryptographic evidence digest based on the error state information, and digitally signing it using the private key of the database instance to form a corrupted credential; creating a buffer for the data page that failed the checksum verification, and mapping subsequent read requests for the data page to the buffer to maintain business continuity; initiating a repair transaction, replaying all relevant modification records in the repair transaction log from the moment the data page was marked as frozen back to its last known intact state, reconstructing the logically consistent correct page content in memory, and calculating its SM3 checksum; persistently storing the reconstructed correct page content and its SM3 checksum in a new physical location on the storage device, and updating the page mapping relationship of the database so that the original logical page number points to the new physical location.

[0014] This application provides a database page integrity verification system based on national cryptographic algorithms, comprising: a verification value storage area determination unit, which acquires a data page to be written to a storage device from the database and determines a verification value storage area within the data page; wherein the verification value storage area is located at the end of the data page; a hash calculation unit, which calls the SM3 cryptographic hash algorithm to perform continuous hash update calculations on the page content excluding the verification value storage area to obtain a first SM3 verification value; a data page writing unit, which writes the first SM3 verification value into the verification value storage area and then writes the data page into the storage device; a data page reading unit, which responds to a verification command, reads the data page from the storage device, calls the SM3 cryptographic hash algorithm to recalculate the page content excluding the verification value storage area to obtain a second SM3 verification value; and a verification unit, which compares the second SM3 verification value with the first SM3 verification value in the verification value storage area to determine the integrity of the data page based on the comparison result.

[0015] This application provides a non-volatile computer storage medium storing computer-executable instructions. These instructions are configured to: acquire a data page from a database to be written to a storage device, and determine a checksum storage area within the data page; wherein the checksum storage area is located at the end of the data page; invoke the SM3 cryptographic hash algorithm to perform continuous hash update calculations on the page content excluding the checksum storage area, to obtain a first SM3 checksum; write the first SM3 checksum to the checksum storage area, and then write the data page to the storage device; respond to a verification instruction, read the data page from the storage device, invoke the SM3 cryptographic hash algorithm to recalculate the page content excluding the checksum storage area, to obtain a second SM3 checksum; and compare the second SM3 checksum with the first SM3 checksum in the checksum storage area to determine the integrity of the data page based on the comparison result.

[0016] The above-mentioned technical solutions adopted in this application embodiment can achieve the following beneficial effects: Firstly, by determining the checksum storage area in the footer region of the data page, the physical storage format of the database core does not require any modification, thus achieving complete compatibility with older database versions and eliminating upgrade obstacles and engineering risks caused by format changes. Secondly, this application embodiment uses the SM3 cryptographic hash algorithm to calculate the page content outside the checksum storage area, enabling it to resist malicious collisions and tampering, solving the problem of insufficient security strength of the CRC algorithm. Thirdly, by writing the calculated SM3 checksum into the footer storage area, the original data layout is not destroyed, achieving zero-intrusive expansion. During reading, the SM3 checksum is recalculated and compared with the stored value, ensuring that every data page loaded from disk to memory undergoes rigorous integrity verification, providing a secure, compliant, and compatible protection scheme for the database system. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. In the drawings: Figure 1 This is an architecture diagram of a PostgreSQL database page integrity verification platform based on Chinese cryptographic algorithms. Figure 2 A flowchart of a database page integrity verification method based on national cryptographic algorithms is provided for embodiments of this application; Figure 3 This is a schematic diagram of the PostgreSQL page structure provided in an embodiment of this application; Figure 4 A flowchart illustrating a data page writing process provided in this application embodiment; Figure 5 A flowchart illustrating a data page reading process provided in this application embodiment; Figure 6 This is a schematic diagram of the structure of a database page integrity verification system based on the national cryptographic algorithm provided in an embodiment of this application. Detailed Implementation

[0018] This application provides a database page integrity verification method, system, and medium based on national cryptographic algorithms.

[0019] To enable those skilled in the art to better understand the technical solutions in this application, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this application.

[0020] Figure 1 This is an architecture diagram of a PostgreSQL database page integrity verification platform based on national cryptographic algorithms, such as... Figure 1 As shown, the architecture of the PostgreSQL database page integrity verification platform based on the national cryptographic algorithm consists of a user layer, a database kernel layer, a buffer management layer, a national cryptographic module layer, and a storage layer. The interaction relationships between each layer are as follows: User layer: Users or applications access the PostgreSQL database through SQL statements and initiate data read and write requests.

[0021] Database kernel layer: Receives user SQL requests, parses and executes corresponding query or update operations, involving reading and writing data pages. The kernel layer includes a page validation module, which provides two core functions: PageSetSM3Checksum and PageVerifySM3Checksum, used for validation processing in the write and read paths, respectively.

[0022] Buffer Management Layer: Manages the shared buffer and coordinates the exchange of data pages between memory and disk. In the write path, the `FlushBuffer` function triggers the generation and storage of page checksums; in the read path, the `ReadBuffer_common` function triggers page checking. The buffer management layer determines whether SM3 checksums are enabled based on the GUC configuration parameter `enable_sm3_page_checksum`.

[0023] The national cryptographic module layer provides the SM3 cryptographic hash algorithm library, including three functions: SM3_Init, SM3_Update, and SM3_Final. SM3_Init initializes the hash calculation context, SM3_Update updates the hash state in blocks, and SM3_Final generates the final 32-byte hash digest. The page verification module calls the national cryptographic module's interface to calculate the value of the page content.

[0024] Storage layer: This includes a shared buffer and disk storage. The shared buffer caches data pages in memory, reducing disk I / O; disk storage persistently stores data page files. During writes, a checksum is stored in the pd_special area of ​​the data page; during reads, the checksum is read from the pd_special area for verification.

[0025] Data flow: In the write process, after the SQL request is processed by the kernel layer, the page verification module calls the SM3 cryptographic hash algorithm to calculate the verification value, which is stored in the pd_special area. The page is then flushed to the disk via the shared buffer. In the read process, the data page is loaded from the disk into the shared buffer. The page verification module calls the national cryptographic module to recalculate and compare the result with the stored value to verify the integrity of the page.

[0026] Figure 2 A flowchart of a database page integrity verification method based on national cryptographic algorithms is provided for embodiments of this application, as follows: Figure 2 As shown, the database page integrity verification method based on the national cryptographic algorithm includes the following steps: Step 101: Obtain the data page to be written to the storage device from the database, and determine the verification value storage area in the data page.

[0027] In one implementation of this application, a data page to be written to the storage device is obtained from the database. The pd_special area of ​​the data page is used as a reference area to determine the page type of the data page. If the data page is a heap table page, the reference area is extended to ensure that the extended area is not less than the byte length of the SM3 checksum, thus obtaining the checksum storage area. If the data page is an index page, the original stored data corresponding to the reference area is kept unchanged, and the tail of the reference area is extended to ensure that the tail extension area is not less than the byte length of the SM3 checksum, thus obtaining the checksum storage area. The checksum storage area is located in the tail area of ​​the data page.

[0028] Specifically, Figure 3 This is a schematic diagram of the PostgreSQL page structure provided in an embodiment of this application, as shown below. Figure 3 As shown, a PostgreSQL data page mainly consists of three parts: the page header (PageHeaderData), the data area, and the pd_special area. The data area stores the actual Heap Tuple or Index Tuple, while the pd_special area is located at the end of the page, and its size and purpose vary depending on the page type. In this embodiment, the SM3 checksum (32 bytes) is stored at the end of the pd_special area. For heap tables, the original pd_special size is usually 0, and the pd_special size is directly extended to 32 bytes to store the SM3 checksum. For index pages, the original pd_special is already used to store index-specific data (such as high key and leaf page linked list information). In this embodiment, a split storage strategy is adopted, dividing the pd_special area into two parts: the first half retains the original index data, and the second half is extended by an additional 32 bytes to store the SM3 checksum. The location of the checksum is obtained using the following formula: checksum_pos=PageGetSpecialPointer(page)+PageGetSpecialSize(page)-SM3_HASH_SIZE; Here, `checksum_pos` is a pointer to the checksum value; `PageGetSpecialPointer(page)` is a function that accepts a data page pointer `page` as a parameter and returns a pointer to the location of the `pd_special` region of that data page; `PageGetSpecialSize(page)` is also a function that accepts a data page pointer `page` as a parameter and returns the total size of the `pd_special` region. `SM3_HASH_SIZE` represents the hash value generated by the SM3 cryptographic hash algorithm, typically 32 bytes. When calculating the SM3 cryptographic hash value of the page content, the 32-byte region pointed to by `checksum_pos` needs to be excluded to avoid self-referencing logical errors.

[0029] Step 102: Call the SM3 cryptographic hash algorithm to perform continuous hash update calculations on the content of other pages in the data page, excluding the check value storage area, to obtain the first SM3 check value.

[0030] In one implementation of this application, a first function is called to determine whether page integrity verification based on Chinese cryptographic algorithms is enabled. If enabled, a second function is called to determine whether the page type of the data page supports Chinese cryptographic algorithm verification. If not supported, the original cyclic redundancy check algorithm is called to calculate and verify the data page, and the verification value is written to a specified position in the header of the data page. If supported, the SM3 cryptographic hash algorithm is called for calculation.

[0031] Specifically, Figure 4 A flowchart of a data page writing process is provided for an embodiment of this application, such as... Figure 4As shown: The database kernel calls the FlushBuffer function (a core low-level function in the PostgreSQL database kernel, mainly responsible for writing modified data pages in the shared buffer to the disk storage device) to prepare to write the data pages in the shared buffer to the disk; the FlushBuffer function checks whether the GUC configuration parameter enable_sm3_page_checksum is enabled. If it is not enabled, it calls the PageSetChecksumCopy function to calculate and store the CRC-32C checksum value; if it is enabled, it calls the PageSupportsSM3 function to check whether the current page type supports SM3 checksum. If it does not support it, it calls the PageSetChecksumCopy function to calculate and store the CRC-32C checksum value; if it supports it, it calls the newly added function PageSetSM3Checksum, passing in the data page pointer, block number, and branch number parameters. The `PageSetSM3Checksum` function uses the macros `PageGetSpecialPointer` (to get a pointer to the start position of the `pd_special` region in the data page) and `PageGetSpecialSize` (to get the total byte length of the `pd_special` region in the data page) to obtain the read position and size of the `pd_special` region. It then calculates the checksum value storage location `checksum_pos`, which is located at the end of the `pd_special` region. It initializes the SM3 cryptographic hash calculation context, preparing to calculate the hash value of the page content. Dividing the page content into two parts using `checkpoint_pos` as the boundary, it first calculates the data from the start of the page to `checksum_pos`. Then, it skips the 32-byte region pointed to by `checksum_pos` and calculates the data from `checksum_pos` to the end of the page. Finally, it calls the SM3 cryptographic hash algorithm to generate a 32-byte first SM3 checksum value.

[0032] This application implements national cryptographic verification without modifying the native PostgreSQL page header structure (PageHeaderData), ensuring backward compatibility of the database physical storage format and avoiding obstacles to version upgrades.

[0033] In one implementation of this application, skipping the checksum storage area and accumulating the contents of the first data block and the second data block to generate a first SM3 checksum, specifically includes: if a data page is detected to be marked as high security level, obtaining the read address corresponding to the data page, the end address of the page header area, and the read position of the checksum storage area; performing a national cryptographic hash calculation on the byte sequence of multiple addresses based on a preset order to obtain a key; determining a dynamic segmentation point based on the numerical characteristics of the header bytes corresponding to the intermediate hash digest obtained after accumulation calculation, and the offset of the start address of the checksum storage area relative to the end of the page; dividing the intermediate hash digest into a front data segment and a rear data segment based on the dynamic segmentation point; performing a block cipher-based obfuscation operation on the front data segment and the rear data segment based on the key to obtain a first obfuscated block and a second obfuscated block; performing a bitwise XOR operation on the first obfuscated block and the second obfuscated block to obtain a folding result; and calling the SM3 cryptographic hash algorithm to calculate the folding result to obtain the first SM3 checksum.

[0034] Specifically, when a data page is detected as being marked as high-security, an enhanced checksum generation process is initiated. First, the read address of the data page, the end address of the header region, and the read position of the checksum storage area are obtained. The byte sequences of these three addresses are concatenated in a preset order. The SM3 cryptographic hash algorithm is called to calculate the concatenated byte sequence, outputting a hash digest. Its length is then adapted to meet the key length requirements of the Chinese national cryptographic block cipher algorithm standard, thus obtaining a structured key. The intermediate state generated during the accumulation calculation process, i.e., the intermediate hash digest value, is obtained. Several consecutive preset bytes from the beginning of this intermediate hash digest value are extracted and interpreted as an integer value A. Simultaneously, the offset of the checksum storage area's starting address relative to the end address of the entire data page is calculated, yielding an integer value B. A modulo operation is performed between integer values ​​A and B, and the result is modulo the total length of the intermediate hash digest. Finally, the effective byte position within the digest is obtained; this position is the dynamic segmentation point. Based on the dynamic segmentation point, the intermediate hash digest is divided into two consecutive parts in memory: a front data segment and a back data segment. The key is initialized to a block cipher algorithm instance conforming to the national cryptographic standard, and configured to an operation mode suitable for generating keystreams. Using the initialized block cipher instance, a keystream of the same length as the preceding data segment is generated. This keystream is then XORed byte-by-byte with the preceding data segment to obtain the first obfuscation block. Next, using the same key and algorithm instance but with a different initialization vector, a keystream of the same length as the following data segment is generated, and this keystream is XORed byte-by-byte with the following data segment to obtain the second obfuscation block. The first obfuscation block and the second obfuscation block are then XORed, non-linearly mixing the information in the two obfuscation blocks, outputting a data block of the same length as the obfuscation blocks, which is the folding result. Finally, the SM3 cryptographic hash algorithm is called on the folding result to calculate the hash digest, which is a fixed-length 32-byte hash digest. This digest is the first SM3 checksum and is written to the checksum storage area at the end of the page.

[0035] Furthermore, after the system reads a data page from the storage device into the memory buffer, if the data page has a high-security-level marker, an enhanced verification process is initiated. Following the exact same rules as during the write operation, the read address, the end address of the page header region, and the start address of the checksum storage area for the data page are re-acquired. The byte sequences of these addresses are concatenated in a preset order to recover the same key as during the write operation. The system calls the SM3 cryptographic hash algorithm and, according to the partitioning rules during the write operation (skipping the checksum storage area), performs continuous hash update calculations on the contents of the first and second data blocks to obtain an intermediate hash digest. Simultaneously, the first SM3 checksum stored in the checksum storage area is read. Based on this checksum, the write operation process needs to be deduced in reverse. However, since the folding result to the final checksum is a one-way SM3 hash, the core of the verification becomes reproducing the enhanced calculation process during the write operation and comparing the result with the stored checksum. Therefore, this embodiment uses the key and the checksum offset read from the current page header, combined with several bytes of the header features of the recalculated intermediate hash digest, to recalculate the dynamic partitioning point using the same algorithm as during the write operation. Based on the newly determined dynamic segmentation points, the recalculated intermediate hash digest is divided into a front data segment and a rear data segment. Using the recovered key, a keystream is generated with the exact same block cipher algorithm and mode as when it was written, and the same obfuscation operation is performed on the front and rear data segments respectively, resulting in a first obfuscated block and a second obfuscated block. The two obfuscated blocks are XORed bitwise to obtain a folded result. Finally, the SM3 cryptographic hash algorithm is called on this folded result to calculate the SM3 checksum for verification. This SM3 checksum for verification is compared byte-by-byte with the first SM3 checksum read from the checksum storage area of ​​this data page. If the two are completely identical, it proves that the integrity verification of the high-security data page has passed.

[0036] In this application's embodiments, the position of the segmentation point is determined by the intermediate sequence features generated during the calculation process and the inherent offset. Therefore, any modification to the page content, even a very small one, has a high probability of causing an unpredictable shift in the segmentation point. This is equivalent to adjusting the data based on the modified content before the core encryption step, making it impossible for attackers to predict or control the precise path of subsequent encryption before modification. Therefore, for an attacker to construct a tampered page that can pass verification, they not only need to crack the hash but also precisely adapt to the entire cryptographic processing chain that changes due to content variations, making it computationally extremely difficult. This application's embodiments provide a more robust security enhancement scheme.

[0037] Step 103: Write the first SM3 check value to the check value storage area, and then write the data page to the storage device.

[0038] In one implementation of this application, the calculated 32-byte hash value is written to the tail position of pd_special pointed to by checksum_pos using the memcpy function. The flag PD_SM3_CHECKSUM is set in the pd_flags field of the page header to indicate that SM3 checksum is enabled for this data page. The FlushBuffer function is returned to continue subsequent page write operations. The data page is successfully written to disk, completing the entire write process. If SM3 checksum is not enabled or the page type is not supported, the original PageSetChecksumCopy function is called to calculate and store the CRC-32C checksum value, and then page integrity check is performed again.

[0039] In one implementation of this application, when entering enhanced security mode in response to a security policy, a first SM3 checksum is written to the checksum storage area. This includes: obtaining the salt value corresponding to the previous data page adjacent to the current data page's physical address, using it as the predecessor salt value; concatenating the predecessor salt value, the current data page's physical address, and the current database timestamp; and calling the SM3 cryptographic hash algorithm to calculate the concatenation result to generate a chained salt value corresponding to the current data page; wherein the chained salt value is stored in a specified field in the fixed-format header area of ​​the current data page. Using the chained salt value as input to the verification delay function, a corresponding delayed credential and its verification proof are generated. A context binding code is generated through a preset mapping rule and the chained salt value. The first SM3 checksum, the verification proof corresponding to the delayed credential, and the context binding code are associated and combined; an SM3 cryptographic hash is calculated on the combination result to obtain a 32-byte enhanced integrity checksum, which is then written to the checksum storage area.

[0040] Specifically, when the database system enters enhanced security mode according to a pre-configured security policy, a chained salt value generation process is initiated for each data page to be written. First, based on the physical address of the current data page, the preceding data page with an adjacent physical address on the storage medium is located. The pre-stored salt value is read from the fixed-format header area of ​​this preceding data page and used as the predecessor salt value for the current page. If the current page is the starting page of a contiguous storage area, a preset global initialization vector is used as its predecessor salt value. The physical block address of the current data page itself is obtained, along with the current timestamp of the database. The predecessor salt value, the byte representation of the current page's physical block address, and the byte representation of the current timestamp are concatenated to form a merged data block. The SM3 cryptographic hash algorithm is called to calculate a hash digest of a fixed length of 32 bytes, which is the unique chained salt value for the current data page. Finally, this chained salt value is written to a reserved special field in the fixed-format header area of ​​the current data page. Using a chained salt value as input, a pre-defined verifiable delay function calculation process is initiated. This process, starting with the chained salt value as the initial state, performs a preset number of consecutive iterative calculations, such as tens of thousands of consecutive SM3 hash calculations. This calculation process inevitably consumes a certain amount of computation time. Finally, after consuming the preset computational cost, a delayed credential is obtained. Simultaneously, a short, fast verification proof corresponding to this delayed credential is generated. This proof allows external verifiers to verify in a very short time that the delayed credential was indeed obtained from the chained salt value through a specified number of calculations, without needing to repeat time-consuming calculations.

[0041] One or more bytes from the end of the chained salt value are extracted, or a modulo operation is performed on the chained salt value to obtain the context binding code through a mapping rule. This context binding code is used to uniquely identify and bind the context information of the current page in subsequent synthesis steps. The first SM3 checksum, the fast verification proof of the delayed credential, and the context binding code are sequentially concatenated in memory according to a preset format to form a combined data block. The national cryptographic SM3 hash algorithm is called to calculate a 32-byte hash digest for this combined data block. This digest is the enhanced integrity checksum, which integrates content integrity proof, time cost proof, and page context identifier. Finally, the enhanced integrity checksum is written to a pre-determined checksum storage area at the end of the current data page, completing the checksum writing process in the enhanced security mode.

[0042] Furthermore, when reading a data page enhanced with chained salt values ​​and delayed credential verification, the chained salt value is first read from a fixed field in the page header. The previous page is located based on its physical address, and its stored salt value is retrieved as the predecessor salt value. This predecessor salt value, the physical address of the current page, and the timestamp of the corresponding write time recovered from the database context are concatenated. The national standard SM3 cryptographic hash algorithm is then called to perform calculations, and the result is compared with the chained salt value read from the current page. This step verifies the correctness of the chained association between the current page and its physical predecessor page, confirming that the physical storage sequence of the page has not been disrupted. If the verification passes, the read chained salt value is used to quickly verify the delayed credential verification certificate parsed from the current page's verification value storage area, confirming the validity of the certificate and proving that the enhanced verification value of the data page did indeed incur the necessary computational time cost during generation. Simultaneously, the second SM3 verification value corresponding to the page content is recalculated. Finally, based on the chained salt values ​​and preset rules, a new context binding code is generated. The second SM3 checksum, the verified delayed credential verification proof, and the regenerated context binding code are combined and calculated to obtain a new enhanced verification value. This calculated value is then compared with the enhanced integrity checksum read directly from the checksum storage area. If all values ​​match, the content integrity and physical storage timing verification of the data page are deemed successful.

[0043] Step 104: Respond to the verification command, read the data page from the storage device, call the SM3 cryptographic hash algorithm, and recalculate the contents of the other pages in the data page, excluding the verification value storage area, to obtain the second SM3 verification value.

[0044] In one implementation of this application, in response to a verification command, after reading the data page, a third function is called to determine whether the national cryptographic algorithm verification is enabled. If enabled, a fourth function is called to read the flag bit in the data page header to determine whether the data page already contains the national cryptographic verification value. If the data page already contains the national cryptographic verification value, the SM3 cryptographic hash algorithm is called to recalculate the other data in the data page except for the verification value storage area to obtain the second SM3 verification value.

[0045] Specifically, Figure 5 A flowchart of a data page reading process is provided for an embodiment of this application, such as... Figure 5As shown, the data page reading process is as follows: The database kernel calls the `ReadBuffer_common` function to read the data page from the disk into the shared buffer. `ReadBuffer_common` then calls the `PageIsVerified` function to perform page integrity verification. The `PageIsVerified` function checks whether the GUC configuration parameter `enable_sm3_page_checksum` is enabled. If not, it checks again; if enabled, it calls the `PageHasSM3Checksum` function, which reads the `pd_flags` flag in the page header to determine if SM3 verification is enabled for the data page. If not, it checks again; if enabled, it calls the newly added function `PageVerifySM3Checksum`, passing in the data page pointer and block number parameters. The `PageVerifySM3Checksum` function uses the macros `PageGetSpecialPointer` and `PageGetSpecialSize` to obtain the read position and size of the `pd_special` region, and calculates the checksum value storage location `checksum_pos`. It reads the stored 32-byte checksum value from the end of `pd_special` pointed to by `checksum_pos` and saves it as `stored_hash`. The SM3 cryptographic hash calculation context is initialized, and the hash value of the page content is recalculated. The page content is divided into two parts for hash calculation, with checkpoint_pos as the boundary. First, the data from the page read position to before checksum_pos is calculated. Then, the 32-byte area pointed to by checksum_pos is skipped, and the data from checksum_pos to the end of the page is calculated. Finally, SM3_Final is called to generate a new 32-byte hash digest.

[0046] Step 105: Compare the second SM3 check value with the first SM3 check value in the check value storage area to determine the integrity of the data page based on the comparison result.

[0047] In one implementation of this application, such as Figure 5 As shown, during hash value comparison, the `memcmp` function is called to compare whether the newly calculated hash value matches the stored hash value. If the hash values ​​match, the page integrity check passes, `true` is returned, and the page is usable. If the hash values ​​do not match, the page integrity check fails, triggering an error or recovery process, and `false` is returned. If SM3 checksum is not enabled or the page flag indicates that SM3 is not used, the original `pg_checksum_page` function is called to perform CRC-32C checksum, and then `true` or `false` is returned based on the checksum result.

[0048] In one implementation of this application, after comparing the second SM3 checksum with the first SM3 checksum in the checksum storage area, the method further includes: if the second SM3 checksum is inconsistent with the first SM3 checksum in the checksum storage area, generating a cryptographic evidence digest based on the error state information, and digitally signing it using the private key of the database instance to form a corrupted credential. A buffer is created for the data page that failed verification, and subsequent read requests for that data page are mapped to the buffer to maintain business continuity. A repair transaction is initiated. In the repair transaction log, all relevant modification records from the moment the data page was marked as frozen back to its last known intact state are replayed. The logically consistent correct page content is reconstructed in memory, and its SM3 checksum is calculated. The reconstructed correct page content and its SM3 checksum are persistently stored in a new physical location on the storage device, and the page mapping relationship of the database is updated so that the original logical page number points to the new physical location.

[0049] Specifically, when the system detects a discrepancy between the recalculated second SM3 checksum and the first SM3 checksum read from the checksum storage area of ​​the data page during the data page integrity verification process, it immediately determines that the data page integrity verification has failed. The system aborts the read operation that triggered the verification and returns a specific response to the client indicating a data integrity error. Then, the system combines the original bytes of the erroneous page read from disk, the calculated second SM3 checksum, and the stored erroneous first SM3 checksum into a complete evidence data block in memory according to a predetermined format. The system calculates a national standard SM3 cryptographic hash on this evidence data block to generate a corrupted evidence digest. Finally, using the private key of the database instance, a digital signature operation is performed on the corrupted evidence digest and the current high-precision timestamp to generate an unforgeable and non-repudiable corrupted digital credential. Simultaneously with generating the corrupted credential, the system marks the buffer corresponding to the failed page in the memory's page management data structure as a circuit breaker, preventing subsequent normal read requests for that data page. The system dynamically allocates a new buffer in memory for the data page. Subsequently, all requests attempting to read this logical page will be mapped to this new buffer. Before reconstruction is complete, this new buffer is initially empty or in a loading state to maintain basic data access interfaces and business continuity during the repair process. After circuit breaking and mapping are completed, a content reconstruction task for the corrupted page is asynchronously started in the background. This task attempts to recover the correct content of the page from a reliable data source; for example, the reconstruction source could be the database's write-ahead log, reconstructing the page by replaying all modification records committed before the corruption occurred that are related to the data page. Once the background reconstruction task successfully generates candidate correct page content, a standard integrity verification process is immediately performed on that content. This involves calling the SM3 cryptographic hash algorithm to calculate the SM3 checksum corresponding to the reconstructed page content after excluding future checksum storage areas. This step ensures that the new page content to be replaced is complete and verifiable. Subsequently, the verified correct page content and its calculated SM3 checksum are loaded into the new buffer. At this point, all read requests mapped to this buffer will begin receiving correct data. To ensure eventual consistency during the repair process, this embodiment allocates a new physical block on the storage device and writes the correct page content loaded into the new buffer, along with its SM3 checksum, into this new physical block. Next, the database's page table or similar mapping structure is updated to establish a mapping relationship between the logical page number of the original corrupted page and the address of this newly allocated physical block storing the correct data. The mapping with the original corrupted physical block is then discarded. This avoids writing data back to a potentially unstable physical location, achieving a radical migration of the storage location.After the migration operation is successfully committed, the system records a repair completion event in the dedicated repair metadata area of ​​the database. This event record includes the logical page number of the corrupted page, the new physical block address, the repair completion timestamp, and is associated with the generated corruption digital certificate, forming a complete and auditable chain from problem discovery to problem resolution. Finally, the system clears the circuit breaker status flag of the data page in memory. From then on, all access requests to this logical page will directly access the repaired, correct page stored in the new physical location through the updated mapping relationship.

[0050] To ensure smooth upgrades and flexible deployment, this application's embodiments establish a robust compatibility mechanism: (1) GUC configuration switch: Provides the global configuration parameter enable_sm3_page_checksum. Users can dynamically enable or disable SM3 checksum by modifying the postgresql.conf file or using the SET command without restarting the database. When the configuration is turned off, the system automatically reverts to the original CRC-32C checksum mode.

[0051] (2) Page flag differentiation: The high-order bits of the pd_flags field in the PageHeaderData structure are reserved, and a new flag bit PD_SM3_CHECKSUM is defined. This flag bit indicates whether SM3 verification is enabled on the page. The system dynamically selects the verification algorithm based on the flag bit when reading, and supports the coexistence of the old and new formats.

[0052] (3) Page type support: Priority is given to supporting heap table pages and the most commonly used B-Tree index pages. Other index types (such as Hash, GiST, SP-GiST) can use native CRC verification. The scope of support will be gradually expanded to reduce the risk of one-time implementation.

[0053] (4) Backward compatibility and tool compatibility: Since the embodiments of this application do not modify the PageHeaderData structure, databases created using older versions of PostgreSQL can be directly upgraded to newer versions that support SM3 verification, and the pg_upgrade tool can work normally without modification.

[0054] This application also provides a plug-in design: To further reduce deployment invasiveness and improve adaptability to cloud-native and containerized environments, the national cryptographic verification function is designed as an independently loadable PostgreSQL extension plugin. The core idea of ​​the plugin implementation is to encapsulate all the logic of SM3 page verification (including GUC parameters, checksum calculation and writing, and checksum verification) in a dynamic shared library. Through the hook mechanism provided by PostgreSQL 18 (PG18), the page I / O path is dynamically taken over at runtime, thereby achieving decoupling from the kernel code.

[0055] (1) Plug-in definition of GUC parameters: The `enable_sm3_page_checksum` parameter is dynamically registered via the `DefineCustomBoolVariable` function, and its lifecycle is bound to the plugin. This parameter supports the `PGC_USERSET` level, allowing users to dynamically modify it at the session level without restarting the database.

[0056] (2) Plug-in registration of hook functions: PostgreSQL reserves hook points in critical I / O paths, allowing extensions to dynamically inject custom logic. When an extension is loaded, the original hook pointer is saved, and the custom function is registered to the hook point; when the extension is unloaded, the original hook is restored, ensuring system integrity.

[0057] Write hook: flush_buffer_hook is called before data pages are flushed to disk. In the plugin, this is implemented as PageSetSM3Checksum, which determines whether to calculate and write the SM3 checksum based on the GUC parameter.

[0058] The read hook, page_verify_hook, is invoked after the data page is loaded from disk. In the plugin, this is implemented as PageVerifySM3Checksum, which performs validation based on GUC parameters and page flags.

[0059] (3) Plugin encapsulation of verification functions: `PageSetSM3Checksum` and `PageVerifySM3Checksum` are implemented as static functions within the plugin. They directly manipulate the page buffer, using the `pd_special` area to store 32-byte SM3 hash values, and automatically excluding the area containing the checksum during calculation. These functions are implemented internally within the plugin, requiring no modification to the kernel source code.

[0060] (4) Hot loading and hot unloading: The plugin supports dynamic loading via the standard `CREATE EXTENSION` command. Once loaded, the hooks take effect immediately, and all subsequent page I / O operations automatically use SM3 checksum. To temporarily disable SM3 checksum, users can execute `SET enable_sm3_page_checksum = off` without uninstalling the extension. For complete uninstallation, executing the `DROP EXTENSION` command restores the original hooks via the `_PG_fini` function, and the system reverts to the native CRC checksum mode.

[0061] (5) Adaptation to cloud-native and containerized deployment: Because the plugin exists as an independent dynamic library, and PG18 supports loading extensions from any directory, the plugin binary can be stored in a separate layer of the container image. The startup script only needs to execute the command `CREATE EXTENSION IF NOTEXISTS pg_sm3_checksum` to enable national cryptographic verification; this solution requires no changes to the infrastructure.

[0062] Through the above plug-in design, the embodiments of this application achieve zero-intrusion, hot deployment, and cloud-native readiness of the national cryptographic page verification function, reducing the engineering cost of promoting national cryptographic algorithms in the production environment.

[0063] Figure 6 This is a schematic diagram illustrating the structure of a database page integrity verification system based on national cryptographic algorithms, provided as an embodiment of this application. Figure 6 As shown, the database page integrity verification system based on the national cryptographic algorithm includes: a verification value storage area determination unit, which obtains the data page to be written to the storage device from the database and determines the verification value storage area in the data page; wherein, the verification value storage area is located in the end area of ​​the data page; a hash calculation unit, which calls the SM3 cryptographic hash algorithm to perform continuous hash update calculation on the page content other than the verification value storage area in the data page to obtain the first SM3 verification value; a data page writing unit, which writes the first SM3 verification value into the verification value storage area and then writes the data page into the storage device; a data page reading unit, which responds to the verification command, reads the data page from the storage device, calls the SM3 cryptographic hash algorithm to recalculate the page content other than the verification value storage area in the data page to obtain the second SM3 verification value; and a verification unit, which compares the second SM3 verification value with the first SM3 verification value in the verification value storage area to determine the integrity of the data page based on the comparison result.

[0064] This application provides a non-volatile computer storage medium storing computer-executable instructions. These instructions are configured to: acquire a data page from a database to be written to a storage device, and determine a checksum storage area within the data page; wherein the checksum storage area is located at the end of the data page; invoke the SM3 cryptographic hash algorithm to perform continuous hash update calculations on the page content excluding the checksum storage area, to obtain a first SM3 checksum; write the first SM3 checksum to the checksum storage area, and then write the data page to the storage device; respond to a verification instruction, read the data page from the storage device, invoke the SM3 cryptographic hash algorithm to recalculate the page content excluding the checksum storage area, to obtain a second SM3 checksum; and compare the second SM3 checksum with the first SM3 checksum in the checksum storage area to determine the integrity of the data page based on the comparison result.

[0065] The various embodiments in this application are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments of apparatus, devices, and non-volatile computer storage media are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0066] The above descriptions are merely embodiments of this application and are not intended to limit the scope of this application. For those skilled in the art, various modifications and variations can be made to the embodiments of this application. These modifications or substitutions do not cause the essence of the corresponding technical solutions to depart from the spirit and scope of the technical solutions in the embodiments of this application.

Claims

1. A database page integrity verification method based on a national secret algorithm, characterized in that, The method includes: Obtain the data page to be written to the storage device from the database, and determine the verification value storage area in the data page; wherein, the verification value storage area is located in the footer area of ​​the data page; The SM3 cryptographic hash algorithm is invoked to continuously update the hash of the page content other than the check value storage area in the data page to obtain the first SM3 check value. Write the first SM3 check value into the check value storage area, and then write the data page into the storage device; In response to the verification command, the data page is read from the storage device, the SM3 cryptographic hash algorithm is invoked, and the content of other page bodies in the data page excluding the verification value storage area is recalculated to obtain the second SM3 verification value. The second SM3 checksum is compared with the first SM3 checksum in the checksum storage area to determine the integrity of the data page based on the comparison result. When entering enhanced security mode in response to a security policy, the first SM3 checksum is written to the checksum storage area, specifically including: Obtain the salt value corresponding to the previous data page adjacent to the current data page's physical address, and use it as the predecessor salt value. Concatenate the predecessor salt value, the current data page's physical address, and the current timestamp of the database, and call the SM3 cryptographic hash algorithm to calculate the concatenation result to generate the chained salt value corresponding to the current data page; wherein, the chained salt value is stored in a specified field in the fixed-format header area of ​​the current data page; Using the chained salt value as input to the verification delay function, the corresponding delayed certificate and its verification proof are generated; A context binding code is generated using preset mapping rules and the chained salt values; The first SM3 check value, the verification certificate corresponding to the delayed certificate, and the context binding code are associated and combined. The SM3 cryptographic hash is calculated on the combination result to obtain a 32-byte enhanced integrity check value, which is then written into the check value storage area.

2. The database page integrity verification method based on the SM algorithm according to claim 1, characterized in that, The step of determining the verification value storage area in the data page specifically includes: Use the pd_special region of the data page as the reference region; Determine the page type of the data page; If the data page is a heap table page, the reference area is expanded so that the expanded area is not less than the byte length of the SM3 check value, so as to obtain the check value storage area; If the data page is an index page, the original stored data corresponding to the reference area remains unchanged, and the tail of the reference area is extended so that the extended tail area is not less than the byte length of the SM3 check value, so as to obtain the check value storage area.

3. The database page integrity verification method based on the SM algorithm according to claim 1, characterized in that, Before invoking the SM3 cryptographic hash algorithm to perform continuous hash update calculations on the page content excluding the check value storage area in the data page, the method further includes: Call the first function to determine whether the page integrity verification function based on the national cryptographic algorithm is enabled; If enabled, the second function is called to determine whether the page type of the data page supports the national cryptographic algorithm verification. If not supported, the original cyclic redundancy check algorithm is invoked to calculate and check the data page, and the check value is written to the specified position in the header of the data page. If supported, the SM3 cryptographic hash algorithm will be invoked for calculation.

4. The database page integrity verification method based on the SM algorithm according to claim 2, characterized in that, The step of invoking the SM3 cryptographic hash algorithm to continuously update the hash of the page content excluding the checksum storage area in the data page to obtain the first SM3 checksum specifically includes: Add the total length of the pd_special region to the read position of the pd_special region, and subtract the byte length of the SM3 check value to obtain the read position of the check value storage area. Using the verification value storage area as a boundary, the page body content of the data page is divided into a first data block and a second data block; wherein, the first data block is the data from the beginning of the page body to the reading position, and the second data block is the data from after the verification value storage area to the end of the page body; Skip the check value storage area and accumulate the contents of the first data block and the second data block to generate the first SM3 check value.

5. The database page integrity verification method based on the national cryptographic algorithm according to claim 4, characterized in that, After skipping the verification value storage area and performing cumulative calculation on the contents of the first data block and the second data block, the method further includes: If the data page is detected to be marked as high security level, the read address corresponding to the data page, the end address of the page header area, and the read position of the verification value storage area are obtained. Based on a preset order, the byte sequence of multiple addresses is hashed to obtain the key. The dynamic segmentation point is determined by the numerical characteristics of the header bytes corresponding to the intermediate hash digest obtained after cumulative calculation, and the offset of the starting address of the check value storage area relative to the end of the page. Based on the dynamic segmentation point, the intermediate hash digest is divided into a front data segment and a back data segment; Based on the key, a block cipher-based obfuscation operation is performed on the front data segment and the back data segment respectively to obtain a first obfuscated block and a second obfuscated block; Perform a bitwise XOR operation between the first obfuscation block and the second obfuscation block to obtain the folding result; The SM3 cryptographic hash algorithm is invoked to calculate the folded result, and the first SM3 check value is obtained.

6. The database page integrity verification method based on the national cryptographic algorithm according to claim 1, characterized in that, After reading the data page from the storage device, the method further includes: Call the third function to determine whether the national cryptographic algorithm verification is enabled; If enabled, the fourth function is called to read the flag bit in the header of the data page to determine whether the data page contains the national cryptographic verification value; If the data page already contains the national cryptographic verification value, then the SM3 cryptographic hash algorithm is invoked to recalculate the other data in the data page, excluding the verification value storage area, to obtain the second SM3 verification value.

7. The database page integrity verification method based on the national cryptographic algorithm according to claim 1, characterized in that, After comparing the second SM3 checksum with the first SM3 checksum in the checksum storage area, the method further includes: If the second SM3 checksum is inconsistent with the first SM3 checksum in the checksum storage area, a cryptographic evidence digest is generated based on the error status information, and digitally signed using the private key of the database instance to form a corrupted credential. A buffer is created for the data page that failed the verification, and subsequent read requests for that data page are mapped to the buffer to maintain business continuity; Initiate a repair transaction. In the repair transaction log, replay all relevant modification records from the moment the data page was marked as frozen back to its last known intact state. Reconstruct the logically consistent and correct page content in memory and calculate its SM3 checksum. The reconstructed correct page content and its SM3 checksum are persistently stored in a new physical location on the storage device, and the page mapping relationship in the database is updated so that the original logical page number points to the new physical location.

8. A database page integrity verification system based on a national secret algorithm, characterized in that, The system includes: The verification value storage area determination unit obtains a data page from the database to be written to the storage device, and determines a verification value storage area in the data page; wherein, the verification value storage area is located in the end area of ​​the data page; The hash calculation unit calls the SM3 cryptographic hash algorithm to continuously perform hash update calculations on the page content of the data page excluding the check value storage area, and obtains the first SM3 check value. The data page writing unit writes the first SM3 checksum into the checksum storage area and then writes the data page into the storage device. When entering enhanced security mode in response to a security policy, the first SM3 checksum is written into the checksum storage area. Specifically, this includes: obtaining the salt value corresponding to the previous data page adjacent to the current data page's physical address as the predecessor salt value; concatenating the predecessor salt value, the current data page's physical address, and the current database timestamp; and calling the SM3 cryptographic hash algorithm to calculate the concatenation result to generate a chained salt value corresponding to the current data page; wherein the chained salt value is stored in a specified field in the fixed-format header area of ​​the current data page; using the chained salt value as input to the verification delay function to generate the corresponding delayed credential and its verification proof; generating a context binding code through a preset mapping rule and the chained salt value; associating and combining the first SM3 checksum, the verification proof corresponding to the delayed credential, and the context binding code; calculating the SM3 cryptographic hash on the combination result to obtain a 32-byte enhanced integrity checksum, and writing the enhanced integrity checksum into the checksum storage area. The data page reading unit responds to the verification command, reads the data page from the storage device, calls the SM3 cryptographic hash algorithm, and recalculates the page contents of the data page excluding the verification value storage area to obtain the second SM3 verification value. The verification unit compares the second SM3 check value with the first SM3 check value in the check value storage area to determine the integrity of the data page based on the comparison result.

9. A non-volatile computer storage medium storing computer-executable instructions, characterized in that, The computer-executable instructions are capable of performing the method described in any one of claims 1-7.

Images