A system and method for implementing non-intrusive database integrity protection
By constructing a dual-chain cross-verification system of user operation chain and Binlog chain, combined with state hash tree and periodic verification blocks, the intrusiveness and credibility issues of database integrity protection in existing technologies are solved. This achieves non-intrusive anti-tampering and non-repudiation protection, improving the credibility and performance of database security auditing.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- SOUTH CHINA UNIV OF TECH
- Filing Date
- 2026-04-09
- Publication Date
- 2026-07-10
AI Technical Summary
Existing database integrity protection solutions require modifications to the database structure and business logic, resulting in strong intrusion, weak log reliability, inability to simultaneously represent user intent and execution facts, and a lack of independent third-party verification capabilities.
By constructing a user operation chain and a Binlog chain, and utilizing a state hash tree and periodic verification blocks, non-intrusive data capture and dual-chain cross-verification are achieved. Combined with incremental hash tree construction and periodic packaging, tamper-proof and non-repudiation protection is provided.
It enables non-intrusive deployment without modifying the database structure, provides a two-way, non-repudiable chain of evidence to prevent tampering, enhances the credibility of database security audits and judicial evidence collection, and reduces system transformation costs and performance bottlenecks.
Smart Images
Figure CN122365594A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the fields of data security and trusted computing technology, specifically to a system and method for achieving non-intrusive database integrity protection. Background Technology
[0002] As the scale and complexity of business systems continue to increase, relational databases have become the core state storage carrier in various information systems. Traditional security and auditing methods for databases mainly include trigger-based audit tables, middleware auditing based on proxy layers, and offline evidence collection based on system logs and backups. These methods have limitations in multiple aspects in practical applications.
[0003] On the one hand, many existing integrity and auditing solutions require modifications to database table structures, triggers, or business logic. For example, inserting records into the audit table with each write operation or rewriting SQL through a middleware layer. These solutions are often highly intrusive to the original business system, increasing the risks and costs of system upgrades and maintenance. They are also difficult to use for extended periods in production environments that are extremely sensitive to performance. On the other hand, although the logs generated by the database itself (such as MySQL's binlog and PostgreSQL's WAL) record data change events, these logs are usually located inside the database host. Administrators with high privileges can directly delete, modify, or replace log files, making these logs difficult to be accepted as strong audit evidence by independent third parties.
[0004] Traditional solutions also have significant shortcomings in mapping user behavior to database facts. Many systems only record the final data state or only the database execution log, making it difficult to clearly distinguish between user intent and the actual system execution result. Furthermore, they cannot establish a reliable correspondence between user signature operations and specific changes. Once an insider oversteps their authority, maliciously manipulates, or an attacker tamperes with the data, it is difficult to prove, afterward, through a complete and continuous chain of evidence who initiated the change, whether the system executed according to the original intent, and whether there were any bypass or forgery attempts during the process.
[0005] Based on the above problems, there is an urgent need for a new technical solution that can bypass database change information without altering the database structure and business logic, establish a dual-chain structure that simultaneously depicts user intent and execution facts, and combine a state hash tree and periodic verification blocks to achieve integrity protection of the database state, cross-chain consistency verification, and support for independent third-party verification and rapid recovery. This would enhance the credibility of the database in terms of security auditing and judicial evidence collection, and provide substantial anti-tampering capabilities for the database state and related logs. Summary of the Invention
[0006] To overcome the defects and shortcomings of existing technologies, this invention provides a system and method for achieving non-intrusive database integrity protection. Without interfering with the operation of existing business systems, this invention utilizes native incremental logs to achieve non-intrusive data capture, implements dual-chain cross-verification by constructing a user operation chain and a Binlog chain, and completes global state anchoring based on a state hash tree and periodic verification blocks. This solves problems in existing database auditing schemes such as strong invasiveness, weak log reliability, inability to simultaneously represent user intent and underlying execution facts, high consistency verification costs, and lack of independent third-party verification capabilities. It supports tamper-proof and non-repudiable non-intrusive database integrity protection.
[0007] To achieve the above objectives, the present invention adopts the following technical solution:
[0008] This invention provides a system for implementing non-intrusive database integrity protection, comprising: a main database module, a state verification engine module, a user operation chain module, a Binlog chain module, a verification block module, and a user client module;
[0009] The main database module is used to store business data and output database change information in the form of incremental logs;
[0010] The state verification engine module is used to subscribe to incremental logs, calculate the base hash value for the log after a single change, and update the temporary root value by incrementally building a hash tree.
[0011] The user operation chain module is used to receive user operation requests and their operation records.
[0012] The Binlog chain module is used to generate blocks from incremental logs in the main database module by incrementally building a hash tree.
[0013] The verification block module is used to trigger the verification block generation process when a preset time threshold or transaction threshold is reached. Before generation, the state baseline of the previous verification block is extracted, and the theoretical state is calculated by combining all newly generated Binlog records in the current period. This theoretical state is then compared with the current actual state of the main database. If the comparison does not match, the generation of the verification block is rejected and an alarm is issued. If the comparison matches, the hash of all real data in the main database is recalculated to obtain the latest full database state root. The state root, the current block hash of the user operation chain, and the current block hash of the Binlog chain are collected and encapsulated together with the hash of the previous verification block into a verification block and digitally signed, which serves as a periodic anchor point for solidification.
[0014] The user client module manages user private keys, signs business operation intentions and submits them to the server, obtains the state root and Merkle proof for the target record from the verification block, and completes independent verification.
[0015] As a preferred technical solution, the operation record includes the user's digital signature generated by the user client module and the server's signature receipt confirming that the operation has been received and executed.
[0016] As a preferred technical solution, the Binlog chain module is used to generate blocks from the incremental logs in the main database module by incrementally building a hash tree. Specifically, it includes:
[0017] For newly added logs, calculate their hash value and aggregate it with the temporary root value of the currently constructed block to obtain a new temporary root value;
[0018] Traverse the incremental logs and update the temporary root value, then package all logs within the period with the final solidified Merkle root to generate a block.
[0019] As a preferred technical solution, the hash value is calculated by concatenating the value before the incremental log change, the value after the change, and the transaction identifier in a predetermined order.
[0020] As a preferred technical solution, the verification block module uses the elliptic curve digital signature algorithm to sign the block header of the verification block, and calculates an independent signature for the final state root output by the state verification engine module, and writes the state root signature and the block header signature together into the verification block.
[0021] As a preferred technical solution, the user client module obtains the state root and the Merkle proof for the target record from the verification block to complete independent verification, specifically including:
[0022] The state root and the Merkle proof path for the target record are obtained from the verification block module. The target record content and the Merkle proof path are hashed locally and compared with the state root to complete the independent verification of whether the target record belongs to the consistent state at the corresponding time point.
[0023] The present invention also provides a method for implementing non-intrusive database integrity protection, comprising the above-mentioned system for implementing non-intrusive database integrity protection, including the following steps:
[0024] The state verification engine module constructs a state hash tree to obtain the genesis state root and writes it into the genesis verification block signature. The user operation chain module and the Binlog chain module operate in parallel.
[0025] The user client module submits a signed business operation intent, and the server executes it to generate a receipt with the server's signature.
[0026] The status verification engine module obtains incremental logs from the main database, parses out physical execution data, calculates the basic hash value of a single change, and sends it to the packaging pool.
[0027] The Binlog chain module generates blocks by incrementally building hash trees from the incremental logs in the main database module, and packages them into user operation chain blocks and Binlog chain blocks when the period is reached.
[0028] The verification block module triggers the verification block generation process when a preset time threshold or transaction threshold is reached. Before generation, the state baseline of the previous verification block is extracted, and the theoretical state is calculated by combining all newly generated Binlog records in the current period. This theoretical state is then compared with the current actual state of the main database. If the comparison does not match, the generation of the verification block is rejected and an alarm is issued. If the comparison matches, the hash of all real data in the main database is recalculated to obtain the latest full database state root. The state root, the current block hash of the user operation chain, and the current block hash of the Binlog chain are collected and encapsulated together with the hash of the previous verification block into a verification block and digitally signed, which serves as a periodic anchor point for solidification.
[0029] After signing the business operation intent, the user client module submits it to the server, obtains the state root and Merkle proof for the target record from the verification block, and completes independent verification.
[0030] As a preferred technical solution, the state verification engine module constructs a state hash tree to obtain the genesis state root and writes it into the genesis verification block signature, specifically including:
[0031] For each row of a full data snapshot of the main database, a hash value is calculated. The row-level hash is used as the leaf nodes to form the bottom layer of the state hash tree. The intermediate layer nodes are the hash values of the lower layer nodes combined in pairs. Finally, they converge to form the genesis state root, which is used to represent the global state of the database at the initial moment. Genesis verification blocks are generated based on the genesis state root and digitally signed.
[0032] As a preferred technical solution, the user client module also performs a state recovery step, specifically including:
[0033] When a failure occurs or a state rollback is required, the verification block closest to the time of the failure is selected as the starting point. The state root in the verification block and the corresponding snapshot are used to restore the basic state. Then, the Binlog chain blocks after the verification block are replayed sequentially until the latest block. After the recovery is completed, the state verification engine module calculates the state root of the restored state and compares it with the state root in the latest verification block to confirm the correctness of the recovery result.
[0034] As a preferred technical solution, the user client module also executes a proactive auditing and anti-tampering challenge process for the target record, specifically including:
[0035] The user client module saves the block header of the historical verification block as a time anchor, and saves the behavior record of its own initiated operation, the server signature receipt, and the Merkle proof of the operation in the user operation chain;
[0036] The module requests all block headers from a locally stored historical verification block to the latest verification block, verifies the validity of the digital signature in the block header and the continuity of the previous block hash, in order to detect whether there is historical rewriting or block breakage. If signature forgery or hash breakage is found, it is determined that the server attempted to rewrite the historical chain, which is a high-risk tampering behavior. The audit challenge ends here and an alarm is triggered.
[0037] Obtain the latest content of the target record and the corresponding Merkle proof path, and perform local Merkle verification using the state root in the latest verification block. If the verification fails, it is determined that the underlying database has been tampered with off-chain.
[0038] Obtain all Binlog fact records and their Merkle proofs that affect changes to the target record between the two verification blocks provided by the server. Cross-compare these with the locally stored evidence of user operation intent. If a modification to the record is detected in the Binlog chain but the corresponding legitimate user authorization is lacking in the user operation chain, or if no modification is recorded in either chain but the actual value has changed, it is determined that there is an internal unauthorized database modification or a shadow application writing to the database. If there is a receipt in the user operation chain but the corresponding change is not reflected in the Binlog chain, it is determined that a drop-based denial-of-service attack has occurred. If the facts of both chains match completely, the audit is deemed passed: the target record is true, complete, and has not been tampered with without authorization.
[0039] Compared with the prior art, the present invention has the following advantages and beneficial effects:
[0040] (1) This invention achieves bypass capture of data changes by subscribing to the native incremental log of the main database. It does not require modification of the underlying database table structure, storage engine, triggers or original business logic. This design completely decouples the business layer and the audit layer, reduces the complexity of deployment and maintenance, achieves non-intrusive deployment, greatly reduces the cost of system transformation, and is particularly suitable for production environments with extremely strict requirements for performance and stability.
[0041] (2) This invention achieves cross-verification of operational intent and execution facts through a two-way non-repudiation chain of evidence. The operation request with user signature and the change summary of the actual execution in the database are respectively fixed on two independent blockchains (user operation chain and Binlog chain). In case of dispute, it is possible to clearly trace who initiated the operation and whether the system actually executed it, thereby simultaneously satisfying the two-way non-repudiation of the user end and the server end.
[0042] (3) The present invention forces reconciliation before block generation, completely blocks physical tampering on the chain, and provides substantial anti-tampering protection. Before the verification block is generated, a strict comparison mechanism between the theoretical state and the actual physical state is introduced. Any administrator who attempts to bypass the system to directly rewrite the underlying data or modify the database offline will be directly detected in the comparison process, and the generation of the verification block will be refused and an alarm will be issued to prevent contaminated data from obtaining a legitimate signature and ensure the absolute purity of the global time anchor.
[0043] (4) This invention greatly improves the system's concurrency performance by using incremental hash aggregation to construct and periodically package blocks. Its dual-chain adopts the construction method of memory-level incremental hash aggregation tree, combined with periodic batch packaging of blocks, transforming high-frequency business concurrent write operations into lightweight memory hash operations. It abandons the frequent local updates of the global tree in the existing technology, completely solves the performance bottleneck caused by one event at a time, and ensures that the system maintains extremely low overhead in high-concurrency scenarios of millions.
[0044] (5) This invention achieves strong single-database self-verification and accurate responsibility definition through three-layer progressive auditing under zero trust. It not only supports conventional state verification, but also provides an active audit challenge process based on external anchors. Through the three-layer progressive mechanism of block continuity, state consistency and dual-chain fact matching, the client can independently penetrate and capture extreme internal malicious behaviors, including unauthorized database modification, discard denial of service, and even the erasure of dual-chain logs. While retaining the advantages of non-intrusiveness and rapid recovery, it achieves accurate evidence and responsibility definition for single-database anti-tampering. Attached Figure Description
[0045] Figure 1 This is a schematic diagram of the overall architecture of a system for implementing non-intrusive database integrity protection according to the present invention;
[0046] Figure 2 This is a schematic diagram of the implementation architecture of the dual-chain operation of the user operation chain module and the Binlog chain module of the present invention.
[0047] Figure 3 This is a schematic diagram illustrating the implementation process of the dual-chain incremental construction and packaging stage of this invention;
[0048] Figure 4 This is a flowchart illustrating the process of the user client module of this invention performing proactive auditing and anti-tampering challenges. Detailed Implementation
[0049] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.
[0050] Example 1
[0051] like Figure 1 As shown, this embodiment provides a system for implementing non-intrusive database integrity protection, including: a main database module, a state verification engine module, a user operation chain module, a Binlog chain module, a verification block module, and a user client module;
[0052] The main database module is used to store business data and output database change information in the form of incremental logs. The incremental logs are binlog, WAL or similar native database logs. The main database module is configured to maintain the independence of the original table structure, storage engine and business logic, and continuously provide incremental logs through a one-way output interface.
[0053] The state verification engine module is used to subscribe to incremental logs, calculate the basic hash value of the log after a single change, and continuously and dynamically update the temporary root value by incrementally building a hash tree, providing underlying data support for the subsequent generation of blocks;
[0054] The user operation chain module is used to receive user operation requests and their metadata submitted by the server side, and to receive operation records including user digital signatures, business operation intentions, timestamps and random numbers, as well as server signature receipts.
[0055] In this embodiment, each operation record recorded by the user operation chain module includes both the user's digital signature generated by the user client module and the server's signature receipt confirming that the operation has been received and executed. The user's digital signature is used to prove that the user cannot deny the intention to perform the operation, and the server's signature receipt is used to prove that the server cannot deny that the request has been processed according to the operation.
[0056] The Binlog chain module is used to perform normalized summaries on the incremental logs generated by the actual execution of the main database module. It uses incremental hash aggregation to construct log records containing the values before and after the change and the transaction identifier, and links them in blocks according to the hash of the previous block to form a time-ordered chain that describes the facts of database execution.
[0057] In this embodiment, a hash tree is built incrementally to generate blocks: when a new change arrives, its hash value is calculated and aggregated with the temporary root value of the block currently being built to obtain a new temporary root value; as new logs are written, the temporary root value is continuously and dynamically updated, and when a preset period is met, all logs within the period are packaged with the final solidified Merkle root to generate a block;
[0058] In this embodiment, the hash value of each incremental log leaf node in the Binlog chain module is calculated based on the concatenation of the pre-change value, the post-change value, and the transaction identifier in a predetermined order, and is defined as follows:
[0059] ;
[0060] Where H is the predefined cryptographic hash function, and txid is the transaction identifier;
[0061] The verification block module is used to trigger the verification block generation process when a preset time threshold or transaction threshold is reached. Before generation, the state baseline of the previous verification block is extracted, and the theoretical state is calculated by combining all newly generated Binlog records in the current period. This theoretical state is then strictly compared with the current actual state of the main database. If the comparison does not match, the generation of the verification block is rejected and an alarm is issued. If the comparison matches, the hash of all real data in the main database is recalculated to obtain the latest full database state root. The state root, the current block hash of the user operation chain, and the current block hash of the Binlog chain are collected, and together with the hash of the previous verification block, they are encapsulated into a verification block and digitally signed, which is then used as a periodic anchor point for solidification.
[0062] In this embodiment, the verification block module uses the elliptic curve digital signature algorithm to sign the block header of the verification block and calculates an independent signature for the final state root output by the state verification engine module. The state root signature and the block header signature are written into the verification block together to prevent man-in-the-middle attacks and off-chain forged state roots.
[0063] In this embodiment, the verification block module compares the theoretical state with the actual state of the main database to identify whether there is any unauthorized physical tampering or offline database modification that bypasses the system during the verification block generation cycle, thereby preventing the contaminated state data from obtaining the system's digital signature and being uploaded to the blockchain.
[0064] The user client module manages user private keys, signs business operation intentions and submits them to the server, and obtains the state root and Merkle proof for the target record from the verification block without accessing the main database module instance, thus completing independent verification.
[0065] In this embodiment, when the user client module or third-party verification terminal performs data authenticity verification, it only needs to obtain the state root in the target verification block and the Merkle proof path for the target record from the verification block module. It does not need to access the original data stored in the main database module. By performing local hash calculation on the content of the target record and the Merkle proof path and comparing it with the state root, it can complete the independent verification of whether the target record belongs to the consistent state at the corresponding time point.
[0066] In this embodiment, the user client module initiates operation requests with digital signatures and stores anti-tampering credentials for a long time. The server (business backend) is responsible for receiving requests and forwarding them to the underlying layer. The main database module is responsible for executing specific business logic and outputting native incremental logs (such as Binlog) in a bypass manner. The state verification engine module, as the core hub of the system, is responsible for subscribing to the aforementioned incremental logs, calculating hashes, and dynamically maintaining the state hash tree (Merkle Tree). The user operation chain module and the Binlog chain module operate in parallel, respectively responsible for solidifying the user's operation intentions and the underlying execution facts, forming two independent but mutually corroborating hash blockchains. When the set trigger conditions are met, the verification block module aggregates the latest hashes of the two chains with the global state root and signs them to generate a verification block as a time anchor. The modules are decoupled from each other and work together to jointly construct a high-strength non-intrusive anti-tampering system.
[0067] In this embodiment, when unrecorded or unauthorized modifications occur in the main database, the tampering behavior is exposed through state mismatch, block hash chain breakage, or intention inconsistent with the facts. When performing fault recovery or state rollback, the verification block closest to the target time is used as the recovery starting point. The basic state is restored by the state root in the verification block and the corresponding database snapshot. Then, the blocks recorded by the Binlog chain module after the verification block are replayed sequentially until the latest block. After the recovery is completed, the state verification engine module recalculates the current state root and performs consistency verification with the state root recorded in the latest verification block, thereby avoiding a full replay from the genesis block and shortening the recovery time.
[0068] Example 2
[0069] This embodiment provides a method for implementing non-intrusive database integrity protection, and includes the system for implementing non-intrusive database integrity protection as described in Embodiment 1, comprising the following steps:
[0070] System initialization phase: The state verification engine module obtains a full data snapshot of the main database through the database's standard read interface, constructs a state hash tree to obtain the genesis state root and writes it into the genesis verification block signature, and then starts the dual-chain recording of the user operation chain module and the Binlog chain module in parallel.
[0071] like Figure 2 As shown, a hash value is calculated for each row of the full data snapshot. The row-level hash is used as the leaf node to form the bottom layer of the state hash tree. The intermediate layer nodes are the hash values of the lower layer nodes after pairwise combination. Finally, they converge to form the genesis state root, which is used to represent the global state of the database at the initial moment. Genesis verification blocks are generated based on the genesis state root and digitally signed. After the genesis block is generated, the blockchain automatically forks and starts capturing user operation records and Binlog logs in parallel.
[0072] User operation and signature phase: The user client module submits the business operation intention with a signature, and the server generates a receipt with the server's signature after execution;
[0073] In this embodiment, when a user initiates a business operation, the user client organizes the business operation intent (such as the name of the business interface to be called, request parameters, operation type, and specific business load data) into a structured behavioral JSON, and digitally signs it using the client's private key. After the server verifies the signature, it transforms the business instruction into a specific database operation and executes it in the main database. At the same time, it generates a receipt with the server's own signature and delivers it directly to the system for recording. This step achieves the non-repudiation of the user's intent at the business logic level.
[0074] Incremental log capture and status update phase: The status verification engine module obtains the incremental logs from the main database, parses out the physical execution data, calculates the basic hash value of a single change, and sends it to the packaging pool.
[0075] In this embodiment, after the main database performs specific operations, it generates corresponding physical incremental logs (such as binlog). The state verification engine module captures these logs in real-time without intruding on the original business logic, parses the physical execution data before and after the change, and then calculates the basic hash value for the captured single change log (e.g., calculating the hash value for change A). This data is sent to the packaging pool to provide underlying data support for the subsequent construction of the block tree structure. This step achieves accurate capture of execution facts at the storage level.
[0076] Dual-chain incremental construction and packaging stage: such as Figure 3 As shown, the business operation intent record and the underlying physical log enter the construction process of two independent chains respectively. The aggregate hash value is dynamically calculated by incrementally building a hash tree, and the user operation chain block and the Binlog chain block are packaged and generated when the period is reached.
[0077] Taking the Binlog chain as an example, it uses an incremental hash tree construction method to generate blocks, specifically including:
[0078] After the genesis block is generated, when a new change A arrives, its hash value is... This serves as the temporary root value for the currently constructed block; when the new change B arrives, its hash value is calculated. and with Aggregate calculation yields a new temporary root value (i.e. When a subsequent change C occurs, the corresponding aggregate hash value will continue to be calculated according to the incremental hash tree construction method. In this way, as new logs are continuously written, the temporary root value will be continuously and dynamically updated. At the same time, the user operation chain will also perform similar incremental tree construction based on the captured behavior JSON.
[0079] According to a preset period (e.g., once per hour) or a specific threshold, all operation logs within that period are sealed with the final solidified Merkle root, formally packaged to generate user operation chain blocks and Binlog chain blocks, and signed with server-side certificates. Both blockchains contain hash references pointing to the previous block, thus continuously extending forward.
[0080] Verification block generation phase: When the preset threshold is met, the state of the previous verification block is extracted and the theoretical state is calculated in combination with the Binlog of the current period. The state is compared with the actual state of the main database. If the comparison does not match, the block is rejected. If the comparison matches, the real data of the entire database is recalculated and the latest state root of the entire database is obtained. The state root is aggregated with the latest block hash of the dual chain and encapsulated into a verification block and signed and uploaded to the chain.
[0081] Specifically, when a preset time or data volume threshold is reached, a verification block generation process with strict pre-verification and full recalculation mechanisms is triggered. Before generating a block, the database state of the previous verification block (or genesis verification block) is extracted first, and the theoretical database state of the on-chain records is calculated by combining all newly generated Binlog records in the current cycle. This theoretical state is then strictly compared with the actual state of the current main database. If the comparison result does not match, it indicates that the main database may have undergone unauthorized physical tampering that bypasses the system in the current cycle. In this case, the generation of the current verification block will be directly rejected, the subsequent process will be blocked, and a tampering alarm will be triggered.
[0082] Conversely, if the verification is completely successful, the hash of all real data in the current main database will be recalculated to construct a new global state hash tree and obtain the latest full database state root. Subsequently, the verification block will be uniformly written with three core digests: the hash of the latest block in the user operation chain, the hash of the latest block in the Binlog chain, and the recalculated full database state root. The verification block module will then use the system's digital signature algorithm to sign the block header and upload the block to the chain. After anchoring is completed, the system's main loop will point back up and continue to execute the daily log capture and dual-chain accounting process.
[0083] Before the verification block generation stage, this embodiment also includes anomaly detection and evidence collection steps. That is, the state verification engine periodically performs a full database recalculation on the main database in the background and generates a recalculated state root. The recalculated state root is compared with the state root of the most recently verified block record. If they are inconsistent, a warning is triggered.
[0084] Independent verification phase: Users or third parties extract the state root from the verification block, obtain the recorded Merkle proof through the interface, and compare it locally to achieve independent verification.
[0085] In this embodiment, the user client module can trigger independent verification and exception handling processes through bypass;
[0086] Independent Verification: When verifying the authenticity of a record, a third party or client can obtain the public state root from the verification block and request the Merkle proof of the record. The verifier recursively calculates the hash locally and compares it with the on-chain state root. If they match, it means that the record has not been tampered with. The entire process does not require a direct connection to the original database instance.
[0087] Rapid state recovery: When a disaster occurs and data needs to be recovered, the nearest trusted verification block is selected as the starting point, and the basic state is restored based on the snapshot corresponding to that point. Then, it is only necessary to replay the Binlog chain blocks generated after that block in sequence. After the recovery is completed, the current state root is recalculated and compared. This mechanism greatly shortens the disaster recovery time.
[0088] When a failure occurs or a state rollback is required, a state recovery step based on the verification block is executed. This involves selecting the verification block closest to the time of the failure as the starting point, using the state root in that verification block and the corresponding snapshot to restore the basic state, and then sequentially replaying the Binlog chain blocks after that verification block until the latest block. After the recovery is complete, the state verification engine module calculates the state root of the restored state and compares it with the state root in the latest verification block to confirm the correctness of the recovery result.
[0089] Beyond normal dual-chain ledger and block generation, such as Figure 4 As shown, under the zero-trust assumption, the user client module can initiate proactive auditing and anti-tampering challenges against target records. This process is initiated independently by the client using external anchors and evidence (including historical verification block headers with server signatures, JSON of client-initiated operations, and their corresponding server-signed receipts) that it has stored over time in daily interactions. Specifically, it includes:
[0090] (1) External anchor point storage: The user client module stores the block header of the historical verification block as the time anchor point for a long time, and stores the behavior record of its own operation, the server signature receipt, and the Merkle proof of the operation in the user operation chain.
[0091] (2) Validate block continuity: Request the block validation module to verify all block headers from a local historical validation block to the latest validation block, validate the legality of the digital signature in the block header and the continuity of the previous block hash, in order to detect whether there is historical rewriting or block breakage. If signature forgery or hash breakage is found, it is determined that the server attempted to rewrite the historical chain, and a high-risk tampering behavior has occurred. The audit challenge ends here and an alarm is triggered.
[0092] (3) State consistency verification: Obtain the latest content of the target record and the corresponding Merkle proof path, and use the state root in the latest verification block to perform local Merkle verification. If the verification fails, it is determined that the underlying database has been tampered with off-chain.
[0093] Specifically, the current real-time plaintext value of the target record is obtained, as well as the Merkle proof path corresponding to the value to the latest state root. The user client module performs hash recalculation locally and compares it with the full database state root locked in the latest verification block header. If the comparison fails, it proves that the real physical state of the underlying main database has been illegally tampered with outside the system monitoring.
[0094] (4) Dual-chain matching verification of intent and execution facts: The server is required to provide all Binlog fact records and their Merkle proofs that affect the changes to the target record between the two verification blocks. These are then cross-compared with the locally stored evidence of user operation intent. If a modification to the record is detected in the Binlog chain but the corresponding legitimate user authorization is lacking in the user operation chain, or if no modification is recorded in either chain but the actual value has changed, it is determined that there is an internal unauthorized database modification or a shadow application writing to the database. If there is a receipt in the user operation chain but the corresponding change is not reflected in the Binlog chain, it is determined that a drop-based denial-of-service attack has occurred. If the above dual-chain facts match completely, the final judgment of audit approval can be obtained: the target record is real, complete, and absolutely not tampered with without authorization.
[0095] Based on the aforementioned progressive challenge mechanism, as long as the client holds the historical verification block header and its own operation receipt, it can proactively and independently penetrate any malicious behavior that attempts to forge or cover up a single log. This achieves extremely high-strength single-database anti-tampering evidence and liability determination without the need for direct connection to the underlying database.
[0096] The above embodiments are preferred embodiments of the present invention, but the embodiments of the present invention are not limited to the above embodiments. Any changes, modifications, substitutions, combinations, or simplifications made without departing from the spirit and principle of the present invention shall be considered equivalent substitutions and shall be included within the protection scope of the present invention.
Claims
1. A system for implementing non-intrusive database integrity protection, characterized in that, include: The main database module, state verification engine module, user operation chain module, Binlog chain module, verification block module, and user client module are all included. The main database module is used to store business data and output database change information in the form of incremental logs; The state verification engine module is used to subscribe to incremental logs, calculate the base hash value for the log after a single change, and update the temporary root value by incrementally building a hash tree. The user operation chain module is used to receive user operation requests and their operation records. The Binlog chain module is used to generate blocks from incremental logs in the main database module by incrementally building a hash tree. The verification block module is used to trigger the verification block generation process when a preset time threshold or transaction threshold is reached. Before generation, the state baseline of the previous verification block is extracted, and the theoretical state is calculated by combining all newly generated Binlog records in the current period. This theoretical state is then compared with the current actual state of the main database. If the comparison does not match, the generation of the verification block is rejected and an alarm is issued. If the comparison matches, the hash of all real data in the main database is recalculated to obtain the latest full database state root. The state root, the current block hash of the user operation chain, and the current block hash of the Binlog chain are collected and encapsulated together with the hash of the previous verification block into a verification block and digitally signed, which serves as a periodic anchor point for solidification. The user client module manages user private keys, signs business operation intentions and submits them to the server, obtains the state root and Merkle proof for the target record from the verification block, and completes independent verification.
2. The system for implementing non-intrusive database integrity protection according to claim 1, characterized in that, The operation log includes the user's digital signature generated by the user client module and the server's signature receipt confirming that the operation has been received and executed.
3. The system for implementing non-intrusive database integrity protection according to claim 1, characterized in that, The Binlog chain module is used to generate blocks from the incremental logs in the main database module by incrementally building a hash tree. Specifically, it includes: For newly added logs, calculate their hash value and aggregate it with the temporary root value of the currently constructed block to obtain a new temporary root value; Traverse the incremental logs and update the temporary root value, then package all logs within the period with the final solidified Merkle root to generate a block.
4. The system for implementing non-intrusive database integrity protection according to claim 1, characterized in that, The hash value is calculated by concatenating the value before the incremental log change, the value after the change, and the transaction identifier in a predetermined order.
5. The system for implementing non-intrusive database integrity protection according to claim 1, characterized in that, The verification block module uses the elliptic curve digital signature algorithm to sign the block header of the verification block, and calculates an independent signature for the final state root output by the state verification engine module. The state root signature and the block header signature are then written into the verification block together.
6. The system for implementing non-intrusive database integrity protection according to claim 1, characterized in that, The user client module obtains the state root and the Merkle proof for the target record from the verification block, and completes independent verification, specifically including: The state root and the Merkle proof path for the target record are obtained from the verification block module. The target record content and the Merkle proof path are hashed locally and compared with the state root to complete the independent verification of whether the target record belongs to the consistent state at the corresponding time point.
7. A method for implementing non-intrusive database integrity protection, characterized in that, A system for implementing non-intrusive database integrity protection as described in any one of claims 1-6, comprising the following steps: The state verification engine module constructs a state hash tree to obtain the genesis state root and writes it into the genesis verification block signature. The user operation chain module and the Binlog chain module operate in parallel. The user client module submits a signed business operation intent, and the server executes it to generate a receipt with the server's signature. The status verification engine module obtains incremental logs from the main database, parses out physical execution data, calculates the basic hash value of a single change, and sends it to the packaging pool. The Binlog chain module generates blocks by incrementally building hash trees from the incremental logs in the main database module, and packages them into user operation chain blocks and Binlog chain blocks when the period is reached. The verification block module triggers the verification block generation process when a preset time threshold or transaction threshold is reached. Before generation, the state baseline of the previous verification block is extracted, and the theoretical state is calculated by combining all newly generated Binlog records in the current period. This theoretical state is then compared with the current actual state of the main database. If the comparison does not match, the generation of the verification block is rejected and an alarm is issued. If the comparison matches, the hash of all real data in the main database is recalculated to obtain the latest full database state root. The state root, the current block hash of the user operation chain, and the current block hash of the Binlog chain are collected and encapsulated together with the hash of the previous verification block into a verification block and digitally signed, which serves as a periodic anchor point for solidification. After signing the business operation intent, the user client module submits it to the server, obtains the state root and Merkle proof for the target record from the verification block, and completes independent verification.
8. The method for implementing non-intrusive database integrity protection according to claim 7, characterized in that, The state verification engine module constructs a state hash tree to obtain the genesis state root and writes it into the genesis verification block signature, specifically including: For each row of a full data snapshot of the main database, a hash value is calculated. The row-level hash is used as the leaf nodes to form the bottom layer of the state hash tree. The intermediate layer nodes are the hash values of the lower layer nodes combined in pairs. Finally, they converge to form the genesis state root, which is used to represent the global state of the database at the initial moment. Genesis verification blocks are generated based on the genesis state root and digitally signed.
9. The method for implementing non-intrusive database integrity protection according to claim 7, characterized in that, The user client module also performs state recovery steps, specifically including: When a failure occurs or a state rollback is required, the verification block closest to the time of the failure is selected as the starting point. The state root in the verification block and the corresponding snapshot are used to restore the basic state. Then, the Binlog chain blocks after the verification block are replayed sequentially until the latest block. After the recovery is completed, the state verification engine module calculates the state root of the restored state and compares it with the state root in the latest verification block to confirm the correctness of the recovery result.
10. The method for implementing non-intrusive database integrity protection according to claim 7, characterized in that, The user client module also executes a proactive auditing and tamper-proofing challenge process for the target records, specifically including: The user client module saves the block header of the historical verification block as a time anchor, and saves the behavior record of its own initiated operation, the server signature receipt, and the Merkle proof of the operation in the user operation chain; The module requests all block headers from a locally stored historical verification block to the latest verification block, verifies the validity of the digital signature in the block header and the continuity of the previous block hash, in order to detect whether there is historical rewriting or block breakage. If signature forgery or hash breakage is found, it is determined that the server attempted to rewrite the historical chain, which is a high-risk tampering behavior. The audit challenge ends here and an alarm is triggered. Obtain the latest content of the target record and the corresponding Merkle proof path, and perform local Merkle verification using the state root in the latest verification block. If the verification fails, it is determined that the underlying database has been tampered with off-chain. Obtain all Binlog fact records and their Merkle proofs that affect changes to the target record between the two verification blocks provided by the server. Cross-compare these with the locally stored evidence of user operation intent. If a modification to the record is detected in the Binlog chain but the corresponding legitimate user authorization is lacking in the user operation chain, or if no modification is recorded in either chain but the actual value has changed, it is determined that there is an internal unauthorized database modification or a shadow application writing to the database. If there is a receipt in the user operation chain but the corresponding change is not reflected in the Binlog chain, it is determined that a drop-based denial-of-service attack has occurred. If the facts of both chains match completely, the audit is deemed passed: the target record is true, complete, and has not been tampered with without authorization.