A data tamper-proofing method, device, equipment, medium and product

Abstract

This application provides a data anti-tampering method, apparatus, device, medium, and product. The method includes: acquiring primary database ledger data stored in a primary database and backup database ledger data stored in a backup database; performing joint data verification on the primary database and the backup database based on the primary database ledger data, the backup database ledger data, a primary database historical record copy stored in the backup database, and a backup database historical record copy stored in the primary database, to obtain a verification result; determining the trustworthiness of the primary database ledger data and the trustworthiness of the backup database ledger data based on the verification result, the primary database ledger data, the primary database historical record copy, the backup database ledger data, and the backup database historical record copy, to obtain a trustworthiness judgment result; and performing data repair on untrusted ledger data based on the trustworthiness judgment result, wherein the ledger data includes: primary database ledger data and / or backup database ledger data.

Description

Technical Field

[0001] This application relates to the field of database technology, and in particular to a data anti-tampering method, apparatus, device, medium and product. Background Technology

[0002] Currently, data tamper protection is a core aspect of ensuring database security. To address tampering risks, the industry typically employs access control, encryption, and audit logs. Among these, the cryptographically based "ledger database" has become the preferred architecture for tamper protection due to its immutability and verifiability. Ledger databases maintain user table history and global operation history using hash chain technology while recording user data, ensuring that any malicious modifications to historical data can be independently verified and traced. Although existing ledger databases, combined with master-slave replication architectures, raise the attack threshold through data redundancy, in centralized deployments or master-slave environments, attackers can still covertly tamper with historical data files by rewriting them if they gain write access to the file system. More critically, existing technologies lack reliable arbitration mechanisms; once data anomalies occur, the system cannot determine which data in the master or slave nodes is authentic and trustworthy, resulting in data that is detectable but unrecoverable.

[0003] In summary, existing methods for detecting data tampering are not timely or accurate enough, and in scenarios where the primary and backup databases are not compromised simultaneously, there is a lack of effective methods for determining reliable data and technical capabilities for data recovery. Summary of the Invention

[0004] This application provides a data anti-tampering method, apparatus, device, medium, and product to address the technical problems that existing methods for detecting data tampering are not timely and accurate enough, and lack effective reliable data determination methods and data repair capabilities in scenarios where the primary and backup databases are not simultaneously compromised.

[0005] To solve the above-mentioned technical problems, this application is implemented as follows:

[0006] In a first aspect, embodiments of this application provide a data anti-tampering method, the method being applied to a ledger database system including a primary database and a backup database, the method comprising:

[0007] The master database ledger data stored in the master database and the standby database ledger data stored in the standby database are obtained respectively. Based on the master database ledger data, the standby database ledger data, the master database historical record copy stored in the standby database, and the standby database historical record copy stored in the master database, a joint data verification is performed on the master database and the standby database to obtain the verification result.

[0008] Based on the verification results, the primary database ledger data, the primary database historical record copy, the backup database ledger data, and the backup database historical record copy, the reliability of the primary database ledger data and the reliability of the backup database ledger data are determined, and a reliability judgment result is obtained.

[0009] Based on the credibility judgment result, data repair is performed on untrusted ledger data, wherein the ledger data includes: primary database ledger data and / or backup database ledger data.

[0010] Optionally, based on the primary database ledger data, the standby database ledger data, a copy of the primary database historical records stored in the standby database, and a copy of the standby database historical records stored in the primary database, a joint data verification is performed on the primary database and the standby database, which further includes:

[0011] Obtain the historical ledger data of the primary database and the historical ledger data of the backup database;

[0012] The ledger data history of the primary database is encrypted and synchronized to the backup database to obtain a copy of the primary database history stored in the backup database;

[0013] The historical ledger data of the backup database is encrypted and synchronized to the primary database to obtain a copy of the historical ledger data of the backup database stored in the primary database.

[0014] Optionally, the ledger data history of the primary database is encrypted and synchronized to the backup database to obtain a copy of the primary database's historical records stored in the backup database; the process of encrypting the ledger data history of the backup database and synchronizing it to the primary database to obtain a copy of the backup database's historical records stored in the primary database includes:

[0015] Obtain the first hash chain information corresponding to the operation history of the master database ledger data, and use the first hash chain information as the ledger data history of the master database;

[0016] After encrypting the ledger data history of the primary database using the first key, the data is synchronized to the backup database to obtain a copy of the primary database's history.

[0017] Obtain the second hash chain information corresponding to the operation history of the backup database ledger data, and use the second hash chain information as the historical ledger data of the backup database;

[0018] After encrypting the historical ledger data of the backup database using the second key, the data is synchronized to the primary database to obtain a copy of the historical records of the backup database.

[0019] Optionally, the ledger data history is the hash chain information corresponding to the operation history of the entire ledger data, or it is the sampling history obtained by sampling the hash chain information, wherein the hash chain information includes: first hash chain information and second hash chain information.

[0020] Optionally, if the ledger data history is the sampled history, the ledger data history of the primary database is encrypted and synchronized to the backup database to obtain a copy of the primary database history stored in the backup database; encrypting the ledger data history of the backup database and synchronizing it to the primary database to obtain a copy of the backup database history stored in the primary database includes:

[0021] Either the primary database or the backup database is used as the sampling initiating node, and the other is used as the peer sampling node.

[0022] On the sampling initiating node side, the sampling point corresponding to the sampling history of the sampling initiating node is determined. When synchronizing the sampling history to the other sampling node, the sampling point is written into the synchronization log and the synchronization log is copied to the other sampling node.

[0023] On the other party's sampling node side, the sampling point is replayed and aligned according to the synchronization log. It is checked whether the ledger data and the historical ledger data of the other party's sampling node have been replayed to the sampling point. After confirming that the data has been replayed to the sampling point, the historical ledger data of the other party's sampling node is sampled and encrypted based on the sampling point. The encrypted historical sampling data of the other party's sampling node is then synchronized to the sampling initiating node.

[0024] Optionally, a joint data verification is performed on the primary database and the backup database to obtain the verification result, including:

[0025] Either the primary database or the backup database is used as the verification initiating node, and the other is used as the peer verification node.

[0026] On the verification initiating node side, a local verification is performed on its own ledger data. If the local verification fails, it is determined that the joint data verification has failed.

[0027] If the local verification passes, the verification initiating node sends a data verification request to the peer verification node and obtains the peer verification node's local verification result after the peer verification node performs local verification on its own ledger data based on the data verification request; if the peer verification node's local verification result fails, it is determined that the joint data verification has failed.

[0028] If the local verification result of the other party verification node is passed, then the hash value of the latest operation of the other party verification node is obtained, and it is determined whether the hash value of the latest operation of the other party verification node exists in the historical record copy of the other party verification node stored by the verification initiating node; if it does not exist, then it is determined that the joint data verification has failed.

[0029] If the hash value of the latest operation of the peer verification node exists in the historical record copy of the peer verification node stored by the verification initiating node, then the hash value of the latest operation of the verification initiating node is obtained, and it is determined whether the hash value of the latest operation of the verification initiating node exists in the historical record copy of the verification initiating node stored by the peer verification node; if it exists, then the joint data verification is determined to be successful; if it does not exist, then the joint data verification is determined to be unsuccessful.

[0030] Optionally, based on the verification result, the primary database ledger data, the primary database historical record copy, the standby database ledger data, and the standby database historical record copy, the reliability of the primary database ledger data and the reliability of the standby database ledger data are determined to obtain a reliability judgment result, including:

[0031] Based on the verification results and the consistency between the primary database historical record copy and the primary database ledger data, the reliability of the primary database ledger data is determined.

[0032] Based on the verification results and the consistency between the backup database historical record copy and the backup database ledger data, the reliability of the backup database ledger data is determined.

[0033] The credibility judgment result includes at least one of the following: trustworthy, untrustworthy, or credibility unknown.

[0034] Optionally, based on the verification results and the consistency between the primary database historical record copy and the primary database ledger data, the reliability of the primary database ledger data is determined, including:

[0035] If the verification result of the master database fails, the master database ledger data is determined to be untrustworthy.

[0036] If the verification result of the primary database passes, the first key is used to decrypt the primary database history copy. If the decryption is successful, it is determined whether the decrypted primary database history copy is a subset of the primary database's ledger data history. If it is a subset, the primary database ledger data is determined to be trustworthy; if it is not a subset, the primary database ledger data is determined to be untrustworthy. If the decryption fails, the trustworthiness of the primary database ledger data is determined to be unknown.

[0037] Optionally, based on the verification results and the consistency between the backup database historical record copy and the backup database ledger data, the reliability of the backup database ledger data is determined, including:

[0038] If the verification result of the backup database fails, the backup database ledger data is determined to be untrustworthy.

[0039] If the verification result of the backup database passes, the second key is used to decrypt the backup database history copy. If the decryption is successful, it is determined whether the decrypted backup database history copy is a subset of the backup database's ledger data history. If it is a subset, the backup database ledger data is determined to be trustworthy; if it is not a subset, the backup database ledger data is determined to be untrustworthy. If the decryption fails, the trustworthiness of the backup database ledger data is determined to be unknown.

[0040] Optionally, based on the credibility assessment result, data repair is performed on untrusted ledger data, including:

[0041] If the credibility judgment result is that the primary database ledger data is trustworthy and the backup database ledger data is untrustworthy, the primary database ledger data shall be used to overwrite the backup database ledger data.

[0042] If the credibility judgment result indicates that the backup database ledger data is trustworthy and the primary database ledger data is untrustworthy, the backup database ledger data is used to overwrite the primary database ledger data.

[0043] If the credibility judgment result indicates that both the primary database ledger data and the backup database ledger data are untrustworthy, the primary database ledger data and the backup database ledger data are restored from a preset trusted data backup.

[0044] If the credibility judgment result is that either the primary database ledger data or the backup database ledger data is untrustworthy and the credibility of the other is unknown, data repair is performed according to a preset repair strategy.

[0045] Optionally, the preset repair strategy includes at least one of the following:

[0046] Overwrite the ledger data of the untrusted party with the ledger data of the party whose trustworthiness is unknown;

[0047] After restoring data from a preset data backup of the party whose trustworthiness is unknown, the restored data is used to overwrite the ledger data of the untrusted party.

[0048] Optionally, the master-slave architecture of the ledger database system includes at least one of the following: a master-slave architecture, a master-multiple-slave architecture, or a cascaded master-slave architecture; the ledger database system is a highly available distributed database system based on the master-slave architecture.

[0049] Secondly, embodiments of this application provide a data anti-tampering device, which is applied to a ledger database system including a primary database and a backup database, and the device includes:

[0050] The execution module is used to obtain the master database ledger data stored in the master database and the standby database ledger data stored in the standby database respectively, and perform joint data verification on the master database and the standby database based on the master database ledger data, the standby database ledger data, the master database historical record copy stored in the standby database and the standby database historical record copy stored in the master database, and obtain the verification result.

[0051] The credibility judgment module is used to determine the credibility of the primary database ledger data and the credibility of the backup database ledger data based on the verification result, the primary database ledger data, the primary database historical record copy, the backup database ledger data and the backup database historical record copy, and obtain a credibility judgment result.

[0052] The data repair module is used to repair untrusted ledger data based on the credibility judgment result, wherein the ledger data includes: primary database ledger data and / or backup database ledger data.

[0053] Thirdly, embodiments of this application provide a network device, including: a processor, a memory, and a program stored in the memory and executable on the processor, wherein when the program is executed by the processor, it implements the steps of a data anti-tampering method as described in the first aspect.

[0054] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of a data anti-tampering method as described in the first aspect.

[0055] Fifthly, embodiments of this application provide a computer program product, including computer instructions, which, when executed by a processor, implement the steps of a data anti-tampering method as described in the first aspect.

[0056] In this embodiment, the standby database stores the historical ledger data of the primary database, and the primary database stores the historical ledger data of the standby database. Based on the current ledger data stored by both the primary and standby databases, the system further obtains historical proof information stored by the other node. Therefore, when verifying the primary and standby databases, it no longer relies solely on the local ledger verification results of a single node. Instead, it can combine the primary database ledger data, the standby database ledger data, and the historical record copies stored cross-referenced by both sides for joint judgment. This makes it easier to detect inconsistencies between the primary and standby databases, as well as between the ledger data and historical records, improving the ability to identify abnormal states. When the joint data verification fails, the system further combines the primary database ledger data, the standby database ledger data, and the corresponding historical record copies to determine the credibility of the data on both sides. This provides a clearer basis for subsequent repair, ensuring that data repair is based on a reliable source, preventing the continued propagation of abnormal data, and enabling the system to recover even if the primary and standby databases do not fail simultaneously. In summary, the technical solution of this application possesses high accuracy in data tampering detection and strong data recovery capabilities. Attached Figure Description

[0057] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0058] Figure 1 A flowchart illustrating a data anti-tampering method provided in this application embodiment;

[0059] Figure 2 A structural block diagram of a primary / backup ledger database architecture provided in this application embodiment;

[0060] Figure 3 A structural block diagram of a data encryption and decryption operation based on a ledger database master-slave architecture provided in this application embodiment;

[0061] Figure 4 A flowchart illustrating data sampling based on a ledger database master-slave architecture is provided for embodiments of this application;

[0062] Figure 5 A flowchart illustrating data verification based on a ledger database master-slave architecture is provided for embodiments of this application.

[0063] Figure 6 A structural block diagram of a data anti-tampering device provided in an embodiment of this application;

[0064] Figure 7 This is a structural block diagram of a network device provided in an embodiment of this application. Detailed Implementation

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

[0066] Figure 1 This application illustrates a data anti-tampering method according to an embodiment of the present application. The method is applied to a ledger database system that includes a primary database and a backup database, such as... Figure 1 As shown, the method includes:

[0067] Step S101: Obtain the master database ledger data stored in the master database and the standby database ledger data stored in the standby database respectively. Based on the master database ledger data, the standby database ledger data, the master database historical record copy stored in the standby database and the standby database historical record copy stored in the master database, perform joint data verification on the master database and the standby database to obtain the verification result.

[0068] Step S102: Based on the verification results, primary database ledger data, primary database historical record copy, standby database ledger data and standby database historical record copy, determine the reliability of the primary database ledger data and the reliability of the standby database ledger data, and obtain the reliability judgment result;

[0069] Step S103: Based on the credibility judgment result, perform data repair on the untrusted ledger data; wherein, the ledger data includes: primary database ledger data and / or backup database ledger data.

[0070] In this embodiment, the standby database stores the historical ledger data of the primary database, and the primary database stores the historical ledger data of the standby database. Based on the current ledger data stored by both the primary and standby databases, the system further obtains historical proof information stored by the other node. Therefore, when verifying the primary and standby databases, it no longer relies solely on the local ledger verification results of a single node. Instead, it can combine the primary database ledger data, the standby database ledger data, and the historical record copies stored cross-referenced by both sides for joint judgment. This makes it easier to detect inconsistencies between the primary and standby databases, as well as between the ledger data and historical records, improving the ability to identify abnormal states. When the joint data verification fails, the system further combines the primary database ledger data, the standby database ledger data, and the corresponding historical record copies to determine the credibility of the data on both sides. This provides a clearer basis for subsequent repair, ensuring that data repair is based on a reliable source, preventing the continued propagation of abnormal data, and enabling the system to recover even if the primary and standby databases do not fail simultaneously. In summary, the technical solution of this application possesses high accuracy in data tampering detection and strong data recovery capabilities.

[0071] In some embodiments, optionally, joint data verification is performed on the primary database and the secondary database based on the primary database ledger data, the secondary database ledger data, a primary database historical record copy stored in the secondary database, and a secondary database historical record copy stored in the primary database. This process may include, prior to:

[0072] Obtain the historical ledger data of the primary database and the historical ledger data of the backup database;

[0073] The ledger data history of the primary database is encrypted and synchronized to the backup database to obtain a copy of the primary database history stored in the backup database;

[0074] The historical ledger data of the backup database is encrypted and synchronized to the primary database to obtain a copy of the historical ledger data of the backup database stored in the primary database.

[0075] It should be noted that, in this embodiment, the ledger database system includes a primary database and a backup database. The primary database typically undertakes the responsibility of writing ledger data, while the backup database receives data changes synchronized from the primary database and maintains the ledger state corresponding to the primary database. To improve the system's ability to detect and recover from tampering, in addition to traditional primary-backup replication, the system also maintains a bidirectional encrypted synchronization link for the historical ledger data.

[0076] During system operation, the system first retrieves the historical ledger data of the primary database and the standby database. "Historical ledger data" can be understood as the hash chain information formed by historical ledger data operations. Taking the primary database as an example, after processing user write, update, and delete ledger data operations, the primary database generates hash chain information corresponding to the history of these operations, representing the evolution of the primary database's ledger data from its existing state to its current state. Similarly, after completing the corresponding data replay, the standby database also forms its own hash chain information corresponding to its ledger data operation history. This type of hash chain information serves as historical state proof information, and its subsequent uses are primarily for joint verification, trustworthiness judgment, and repair processes.

[0077] After obtaining the ledger data history records of both the primary and standby databases, the system encrypts and synchronizes the primary database's ledger data history records to the standby database, creating a copy of the primary database's history records on the standby database. Simultaneously, the system encrypts and synchronizes the standby database's ledger data history records to the primary database, creating a copy of the standby database's history records on the primary database. In this way, in addition to holding their current ledger data, the primary and standby databases also each hold proof information about the other's historical state.

[0078] After establishing the historical record copies, the system further retrieves the primary database ledger data stored in the primary database and the standby database ledger data stored in the standby database. Combining the primary and standby historical record copies, it performs joint data verification on both databases. In other words, joint data verification is not limited to local hash chain checks of single-sided ledger data; it includes the current ledger data of the primary database, the current ledger data of the standby database, the primary database historical record copy held by the standby database, and the standby database historical record copy held by the primary database in the judgment scope. This allows the system to continue using the cross-stored historical proof information to determine the authenticity and credibility of the current state of both databases, even when both the primary and standby databases claim "local verification passed."

[0079] If the joint data verification passes, it can be considered that the current state of the primary and backup databases is at least free of anomalies under the joint verification conditions defined in this application. If the joint data verification fails, the system further determines the reliability of the primary database ledger data and the backup database ledger data based on the verification results and the consistency between the primary database ledger data and the primary database historical record copy, as well as the consistency between the backup database ledger data and the backup database historical record copy, thus forming a reliability judgment result. The reliability judgment result is not limited to two states: trustworthy or untrustworthy. In some cases, an unknown reliability state may also occur. For example, if one side's local verification passes, but the counterpart copy used to corroborate its historical evolution relationship is damaged or cannot be decrypted, the system cannot directly confirm that the data on that side is untrustworthy, but it is also inappropriate to rashly use it as a repair source; therefore, it can be classified as unknown reliability. After completing the reliability judgment, the system then performs data repair on the untrustworthy ledger data. Repair involves selectively overwriting the data using the trusted ledger data based on the reliability judgment result, or restoring from a preset trusted data backup when neither side can be directly used as a trusted repair source.

[0080] Therefore, this embodiment first establishes cross-historical record copies, then performs joint verification, followed by a trustworthiness assessment, and finally proceeds to the repair phase. The system can not only more effectively detect anomalies between the primary and backup ledger data, but also complete recovery when a trusted source exists, thereby ensuring data integrity and security.

[0081] In one possible implementation, the master-slave architecture of the ledger database system includes at least one of the following: a master-slave architecture, a master-multiple-slave architecture, or a cascaded master-slave architecture; the ledger database system is a highly available distributed database system based on a master-slave architecture.

[0082] It should be noted that the technical solutions of the embodiments of this application are not limited to a single primary-backup node pair, but can also be extended to a primary-multiple-backup architecture, a cascaded primary-backup architecture, and a distributed database system that achieves high availability based on a primary-backup architecture.

[0083] For example, in a primary-multiple-standby scenario, the primary database can establish bidirectional encrypted synchronization relationships with multiple standby databases for historical ledger data. In this case, each standby database stores a copy of the primary database's historical records, and the primary database can also store separate copies of the historical records for each standby database. When a standby database experiences an anomaly, the primary database can use the corresponding historical record copy for joint verification and trustworthiness assessment. Conversely, when the primary database experiences an anomaly, it can also combine the historical record copies stored separately by the multiple standby databases for a comprehensive assessment. Due to the increased number of available backup nodes, the system has more external historical evidence sources when determining the trustworthiness of data on one side, thereby improving the accuracy of the judgment.

[0084] In one possible implementation, the ledger data history of the primary database is encrypted and synchronized to the standby database to obtain a copy of the primary database's historical records stored in the standby database; the ledger data history of the standby database is encrypted and synchronized to the primary database to obtain a copy of the standby database's historical records stored in the primary database, including: obtaining the first hash chain information corresponding to the operation history of the primary database's ledger data, and using the first hash chain information as the primary database's ledger data history; encrypting the primary database's ledger data history using a first key and synchronizing it to the standby database to obtain a copy of the primary database's historical records; obtaining the second hash chain information corresponding to the operation history of the standby database's ledger data, and using the second hash chain information as the standby database's ledger data history; encrypting the standby database's ledger data history using a second key and synchronizing it to the primary database to obtain a copy of the standby database's historical records.

[0085] It should be noted that establishing historical record copies is a prerequisite for subsequent joint verification and trustworthiness assessment. The primary database historical record copy and the backup database historical record copy can be formed as follows: For the primary database, firstly, the first hash chain information corresponding to the operation history of the primary database ledger data is obtained, and this first hash chain information is used as the primary database's ledger data historical record. Since adjacent historical nodes are interconnected through hash relationships, this first hash chain information can serve as proof of the evolution of the primary database's ledger data history. Subsequently, the primary database's ledger data historical record is encrypted using the first key, and after encryption, it is synchronized to the backup database to obtain the primary database historical record copy stored in the backup database.

[0086] Correspondingly, on the standby database side, the second hash chain information corresponding to the operation history of the standby database ledger data is obtained, and this second hash chain information is used as the standby database's ledger data history. Then, the standby database's ledger data history is encrypted using a second key, and the encrypted result is synchronized to the primary database to obtain a copy of the standby database's history stored in the primary database.

[0087] In this possible implementation, the first key and the second key are used for encrypting the historical records of the primary and backup databases, respectively. Thus, each database retains encryption control over its own historical records, ensuring that while copies of historical records stored by the other can be saved and accessed, the other party does not gain the ability to forge such copies. In actual deployment, the first and second keys can come from the same key management system, but still correspond to the primary and backup databases respectively and are not shared between them.

[0088] For example, the encryption history synchronization of the primary database can be performed after the primary database has completed writing the ledger data. After changes occur in the primary database ledger data, the historical record formed based on that state is only complete and comparable when the corresponding ledger state has already been set on the primary database side. Correspondingly, since the standby database typically needs to receive and replay data changes from the primary database first, the encryption history synchronization of the standby database can be performed after the standby database has completed replaying the ledger data. This process ensures that the historical record formed on the standby database accurately corresponds to its currently replayed ledger state.

[0089] Therefore, by encrypting and bidirectionally synchronizing the historical data of the primary and standby database ledgers respectively, a data foundation for subsequent joint verification is formed, and historical records of both the primary and standby databases are stored separately. Even if the ledger data on one side is tampered with, the other side may still hold a copy of the historical records formed before the tampering, thus providing a basis for trustworthiness assessment and data recovery.

[0090] In one possible implementation, the ledger data history is either the hash chain information corresponding to the operation history of the entire ledger data, or the sampling history obtained by sampling the hash chain information, wherein the hash chain information includes: first hash chain information and second hash chain information.

[0091] In this implementation, the ledger data history can take two forms. One approach is to directly synchronize the entire hash chain information corresponding to the ledger data operation history as the ledger data history. This method retains relatively complete historical proof information and is suitable for scenarios with high verification accuracy requirements. The other approach is to sample the hash chain information and synchronize only the sampled history. This method does not need to transmit all historical chain information, but retains a portion of the records that can represent a specific historical state, thereby reducing the transmission, storage, and computational overhead of bidirectional synchronization. Sampling can be performed according to preset time intervals, data write volume, or preset rules.

[0092] Therefore, in practical applications, the choice between using full historical records or sampled historical records can be made based on the system's different requirements for security and resource consumption. The former is more conducive to improving verification integrity, while the latter is more conducive to balancing system performance.

[0093] In one possible implementation, when the ledger data history is a sampling history, the ledger data history of the primary database is encrypted and synchronized to the standby database to obtain a copy of the primary database history stored in the standby database; the ledger data history of the standby database is encrypted and synchronized to the primary database to obtain a copy of the standby database history stored in the primary database, including: using either the primary database or the standby database as the sampling initiating node, and the other as the peer sampling node; on the sampling initiating node side, determining the sampling point corresponding to the sampling history of the sampling initiating node, writing the sampling point to the synchronization log when synchronizing the sampling history to the peer sampling node, and copying the synchronization log to the peer sampling node; on the peer sampling node side, replaying and aligning the sampling point according to the synchronization log, checking whether the ledger data and the ledger data history of the peer sampling node have been replayed to the sampling point; after confirming that the sampling point has been replayed, sampling and encrypting the ledger data history of the peer sampling node based on the sampling point, and then synchronizing the encrypted sampling history of the peer sampling node to the sampling initiating node.

[0094] It should be noted that when using historical sampling records, a log-based consistent sampling method can be used to ensure that the sampling sets formed by the primary and standby databases correspond to each other. Specifically, either the primary or standby database can act as the sampling initiating node, and the other can act as the peer sampling node. The sampling initiating node first determines the sampling point corresponding to the current historical sampling record, and writes the sampling point into the synchronization log and copies it to the peer sampling node when synchronizing the historical sampling record. After receiving the synchronization log, the peer sampling node performs replay alignment based on the sampling point and checks whether the local ledger data and the local ledger data historical record have been replayed to the state corresponding to the sampling point. Only when both are in place will the peer sampling node sample the local ledger data historical record based on the same sampling point, and synchronize the sampling result to the sampling initiating node after encryption.

[0095] By using the above method, both the primary and backup sides can form corresponding sampling history records around the same sampling point, thereby avoiding deviations in subsequent joint verification due to inconsistent sampling points.

[0096] In one possible implementation, joint data verification is performed on the primary and standby databases to obtain the verification result. This includes: using either the primary or standby database as the verification initiating node and the other as the peer verification node; on the verification initiating node side, local verification is performed on its own ledger data; if the local verification fails, the joint data verification is determined to have failed; if the local verification passes, the verification initiating node sends a data verification request to the peer verification node and obtains the peer verification node's local verification result after the peer verification node performs local verification on its own ledger data based on the data verification request; if the peer verification node's local verification result fails, the joint data verification is determined to have failed; if the peer verification node... If the local verification result is successful, then obtain the hash value of the latest operation of the other party's verification node, and determine whether the hash value of the latest operation of the other party's verification node exists in the historical record copy of the other party's verification node stored by the verification initiating node; if it does not exist, then the joint data verification is determined to have failed. If the hash value of the latest operation of the other party's verification node exists in the historical record copy of the other party's verification node stored by the verification initiating node, then obtain the hash value of the latest operation of the verification initiating node, and determine whether the hash value of the latest operation of the verification initiating node exists in the historical record copy of the verification initiating node stored by the other party's verification node; if it exists, then the joint data verification is determined to have passed; if it does not exist, then the joint data verification is determined to have failed.

[0097] It should be noted that joint data verification is initiated by either the primary or backup database, with the other acting as the peer verification node. First, the initiating node performs a local verification of its own ledger data. If the local verification fails, the joint data verification is automatically confirmed to have failed. If the initiating node's local verification passes, it sends a data verification request to the peer verification node and obtains the local verification result returned by the peer verification node after performing its own local verification. If the peer verification node's local verification result fails, the joint data verification is also confirmed to have failed. If both local verifications pass, the hash value of the peer verification node's latest operation is obtained, and it is determined whether this hash value exists in the peer verification node's historical record copy stored by the initiating node. If it does not exist, it means that the peer verification node's current state cannot be supported by the peer's historical proof information held locally, and the joint data verification fails. If the above determination is true, the hash value of the initiating node's latest operation is obtained, and it is determined whether it exists in the peer verification node's historical record copy. Joint data verification is only considered successful if both determinations are true.

[0098] Therefore, this embodiment establishes a joint verification mechanism based on local verification by both parties and bidirectional historical proof. Joint data verification is no longer limited to the primary database verifying itself and the backup database verifying itself; instead, it forms a joint judgment mechanism where the primary and backup databases each perform local self-verification, and the historical records cross-stored by both can mutually prove the current latest state. Even if an attacker can rewrite partial ledger data on one side, as long as they cannot simultaneously control the external historical proof information stored on the other side, the system still has a high probability of detecting inconsistencies between the current state and the historical evolution relationship, thereby improving tamper detection capabilities.

[0099] In one possible implementation, the reliability of the primary database ledger data and the reliability of the secondary database ledger data are determined based on the verification results, primary database ledger data, primary database historical record copies, secondary database ledger data, and secondary database historical record copies, resulting in a reliability judgment result, including:

[0100] Based on the verification results and the consistency between the primary database historical record copy and the primary database ledger data, the reliability of the primary database ledger data is determined.

[0101] Based on the verification results and the consistency between the backup database historical record copy and the backup database ledger data, the reliability of the backup database ledger data is determined; wherein, the reliability judgment result includes at least one of the following: trustworthy, untrustworthy, or reliability unknown.

[0102] It should be noted that, in the event that the joint data verification fails, this embodiment of the application further determines the credibility of the primary database ledger data and the backup database ledger data separately, forming a credibility judgment result. This credibility judgment result may include at least one of the following: trustworthy, untrustworthy, or credibility unknown.

[0103] Specifically, on the one hand, the reliability of the primary database ledger data is determined based on the joint data verification results and the consistency between the primary database historical record copy and the primary database ledger data. On the other hand, the reliability of the standby database ledger data is determined based on the joint data verification results and the consistency between the standby database historical record copy and the standby database ledger data. This approach is more adaptable to complex scenarios where the primary and standby databases fail asynchronously. For example, the primary database may be clearly abnormal, while the standby database can still serve as a reliable source for repair; or the primary database may not be directly determined to be unreliable, but its corresponding historical record copy may be corrupted, thus only its reliability can be determined as unknown. By splitting the reliability determination into two parts—primary database reliability determination and standby database reliability determination—subsequent repairs can decide whether to allow each database to serve as a repair source based on the status of the different sides, thereby avoiding the misuse of data with unclear reliability to overwrite the other side, which could lead to data repair failure.

[0104] In one possible implementation, the trustworthiness of the primary database ledger data is determined based on the verification result and the consistency between the primary database historical record copy and the primary database ledger data. This includes: if the primary database verification result is unsuccessful, determining that the primary database ledger data is untrustworthy; if the primary database verification result is successful, decrypting the primary database historical record copy using a first key; if decryption is successful, determining whether the decrypted primary database historical record copy is a subset of the primary database's ledger data history; if it is a subset, determining that the primary database ledger data is trustworthy; if it is not a subset, determining that the primary database ledger data is untrustworthy; if decryption fails, determining that the trustworthiness of the primary database ledger data is unknown.

[0105] In one possible implementation, the trustworthiness of the backup database ledger data is determined based on the verification result and the consistency between the backup database historical record copy and the backup database ledger data. This includes: if the backup database verification result is unsuccessful, determining that the backup database ledger data is untrustworthy; if the backup database verification result is successful, decrypting the backup database historical record copy using a second key; if decryption is successful, determining whether the decrypted backup database historical record copy is a subset of the backup database's ledger data historical record; if it is a subset, determining that the backup database ledger data is trustworthy; if it is not a subset, determining that the backup database ledger data is untrustworthy; if decryption fails, determining that the trustworthiness of the backup database ledger data is unknown.

[0106] In this embodiment, the reliability of the master ledger data can be determined in the following manner.

[0107] First, check the verification result of the primary database. If the primary database verification result fails, it indicates an anomaly between the primary database ledger data and its local ledger structure or local historical proof relationship, thus directly determining that the primary database ledger data is untrustworthy. In this case, the system no longer needs to rely on the current state of the primary database as a trusted source. If the primary database verification result passes, the first key is further used to decrypt the primary database historical record copy. The primary database historical record copy refers to the primary database ledger data historical record copy stored on the backup database, generated and encrypted by the primary database, and then synchronized. By using the first key for decryption, this primary database historical record copy can be restored to historical proof information that can be compared.

[0108] If decryption is successful, the process continues to determine whether the decrypted copy of the primary database history is a subset of the primary database ledger data history. This subset does not require complete identical entries, but rather serves to determine whether the decrypted external history copy can still cover, correspond to, or prove the historical evolution relationship corresponding to the current primary database ledger data. If the decrypted copy of the primary database history is a subset of the primary database ledger data history, it means that the current state of the primary database corresponds to the external historical proof information stored in the standby database, thus confirming that the primary database ledger data is trustworthy. Conversely, if the decrypted copy of the primary database history is not a subset of the primary database ledger data history, it means that the current state of the primary database cannot be effectively proven by the external history copy, and in this case, the primary database ledger data is untrustworthy.

[0109] If decryption fails, it means that the primary database's historical record copy stored on the standby database cannot be recovered normally. This could be because the copy itself has been damaged or destroyed, or the standby database has lost the correct state of saving the copy. In this case, the system cannot further confirm the reliability of the primary database's current state based on this copy, but it is also inappropriate to hastily determine that the primary database is untrustworthy. Therefore, the status of the primary database ledger data can be set as "unknown reliability." This approach avoids making overly absolute judgments when sufficient historical evidence is lacking.

[0110] The reliability of the backup database ledger data can be determined in a similar manner, just as the reliability of the primary database ledger data can be determined in the primary database ledger data.

[0111] First, check the verification result of the standby database. If the standby database fails verification, it indicates an anomaly between the current ledger status of the standby database and its local ledger verification relationship, thus directly determining that the standby database ledger data is untrustworthy. If the standby database passes verification, the second key is used to decrypt the standby database historical record copy. The standby database historical record copy refers to the standby database ledger data historical record copy stored on the primary database side, generated and encrypted by the standby database, and then synchronized to the primary database. After successful decryption, determine whether the decrypted standby database historical record copy is a subset of the standby database ledger data historical record. If it is a subset, it indicates that the current ledger status of the standby database can be proven by the standby database historical proof information stored in the primary database, thus determining that the standby database ledger data is trustworthy; if it is not a subset, it indicates an inconsistency between the current state of the standby database and the external historical record copy held by the primary database, further determining that the standby database ledger data is untrustworthy.

[0112] If decryption fails, it indicates that the backup database's historical record copy stored in the primary database is corrupted or unavailable. In this case, the current status of the backup database cannot be directly proven based on this copy alone, and it is not advisable to hastily regard the backup database as a trusted source of repair. Therefore, the backup database ledger data can be determined to have unknown reliability.

[0113] Therefore, when the primary and backup data are abnormal, the system can distinguish which side is clearly untrusted, which side can still be trusted, and which side is in a pending state due to the damage of external historical copies, thus providing a basis for subsequent repair strategies.

[0114] In one possible implementation, data repair is performed on untrusted ledger data based on the trustworthiness assessment result, including: if the trustworthiness assessment result is that the primary database ledger data is trustworthy and the backup ledger data is untrustworthy, overwriting the backup ledger data with the primary database ledger data; if the trustworthiness assessment result is that the backup ledger data is trustworthy and the primary database ledger data is untrustworthy, overwriting the primary database ledger data with the backup ledger data; if the trustworthiness assessment result is that both the primary and backup ledger data are untrustworthy, restoring the primary and backup ledger data from a preset trusted data backup; and if the trustworthiness assessment result is that either the primary or backup ledger data is untrustworthy and the trustworthiness of the other is unknown, performing data repair according to a preset repair strategy.

[0115] The preset repair strategy includes at least one of the following: overwriting the ledger data of the untrusted party with the ledger data of the party whose trustworthiness is unknown; or overwriting the ledger data of the untrusted party with the restored data after restoring the data from the preset data backup of the party whose trustworthiness is unknown.

[0116] It should be noted that in this embodiment, the system repairs untrusted ledger data based on the trustworthiness assessment result. When the primary ledger data is trustworthy but the backup ledger data is untrustworthy, the primary ledger data can be used to overwrite the backup ledger data. Conversely, when the backup ledger data is trustworthy but the primary ledger data is untrustworthy, the backup ledger data can be used to overwrite the primary ledger data. When both the primary and backup ledger data are untrustworthy, it means that neither the primary nor backup data can be directly used as a repair source. In this case, the primary and backup ledger data can be restored from a preset trusted data backup.

[0117] Furthermore, when either the primary or backup ledger data is untrusted, and the trustworthiness of the other is unknown, a fixed repair method is not directly applied. Instead, a preset repair strategy is used. This preset repair strategy can include at least one of the following: One method is to directly overwrite the untrusted party's ledger data with the ledger data from the party with unknown trustworthiness. This method is suitable for scenarios where rapid recovery is paramount. Another method is to first restore data from a preset backup of the party with unknown trustworthiness, and then use the restored data to overwrite the untrusted party's ledger data. This method is suitable for scenarios that emphasize recovery accuracy and reliability.

[0118] Therefore, when anomalies occur in the primary and backup databases, the system can prioritize using data from the trusted side to repair data from the untrusted side, thereby preventing the further propagation of abnormal data. When both sides' data are untrusted, the system can further complete the recovery through trusted backups, enabling the system to not only detect tampering but also have actual recovery capabilities.

[0119] In summary, by encrypting and synchronizing the historical ledger data of the primary database to the standby database, and encrypting and synchronizing the historical ledger data of the standby database to the primary database, the system gains access to historical proof information stored by the other node, in addition to the primary and standby databases each storing their current ledger data. Therefore, when verifying the primary and standby databases, it no longer relies solely on the local ledger verification results of a single node. Instead, it can combine the primary database ledger data, the standby database ledger data, and the historical records stored cross-referenced by both databases for joint judgment. This makes it easier to detect inconsistencies between the primary and standby databases, as well as between the ledger data and historical records, improving the ability to identify abnormal states. When the joint data verification fails, the system further combines the primary database ledger data, the standby database ledger data, and the corresponding historical records to separately determine the credibility of the data on both sides. This provides a clearer basis for subsequent repairs, ensuring that data repair is based on a trusted source, preventing the further propagation of abnormal data, and enabling the system to recover even if the primary and standby databases do not fail simultaneously. In conclusion, the technical solution of this application possesses high accuracy in data tampering detection and strong data recovery capabilities.

[0120] This paper introduces a data anti-tampering method provided in the embodiments of this application from the perspective of specific application scenarios. The technical solution proposed in the embodiments of this application is based on a ledger database master-slave architecture (such as...). Figure 2 As shown, by using cross-encrypted bidirectional redundancy or sampling backup of ledger data history, more accurate detection of data tampering can be achieved and the ability to repair data after it has been tampered with can be provided.

[0121] Specifically, in this embodiment, historical records of each other's ledger data are added to both the primary and standby databases. During data verification, joint verification can be performed on the primary database ledger data, standby database ledger data, historical records of the primary database ledger, and historical records of the standby database ledger to determine whether the primary and standby database ledger data are trustworthy. Furthermore, through cross-encryption—that is, the historical records of the primary database ledger data stored in the standby database are encrypted by the primary database, and the historical records of the standby database ledger data stored in the primary database are encrypted by the standby database—it is ensured that data can be recovered if either the primary or standby database is not compromised.

[0122] "Historical records" are hash chains of historical operations on the ledger data. This information is used only for data verification and to determine data trustworthiness. Historical records do not need to record the operations themselves. Depending on the user's requirements for verification accuracy, historical records can be a full redundant hash chain of historical operations or a sampled backup of the hash chain (e.g., sampling once per minute). Historical records can be stored in a data table or a data file. Storing them in a data file is more recommended because it allows for different management methods than database files (e.g., different user access permissions), thus preventing attackers from simultaneously compromising both the ledger data file and the historical record file.

[0123] This application embodiment adds a historical record synchronization module to the existing ledger database. This module performs bidirectional synchronization of historical records between the primary and standby databases. That is, it synchronizes the historical records from the primary database to the standby database, and vice versa. As mentioned earlier, this information can be the full historical record (i.e., data redundancy in the historical record table) or a sampled historical record. Using the full historical record provides higher system security. Using a system-configurable sampled historical record allows for a balance between performance and security. Configurable sampling strategies include, but are not limited to: time interval-based sampling strategies; data write volume-based sampling strategies; rule-based sampling strategies, etc., meaning users can flexibly configure rules according to their actual needs.

[0124] Historical data synchronization from the primary database to the standby database should occur after the primary database ledger data is written, and historical data synchronization from the standby database to the primary database should occur after the standby database ledger data is replayed.

[0125] Cross-encryption is performed by the encryption / decryption module. When using cross-encryption, the primary and backup databases should each maintain their own encryption keys for historical data, and these keys cannot be shared. This ensures the independence of the data between the primary and backup databases, thereby guaranteeing data trustworthiness. For details, please refer to... Figure 3 The encryption module retrieves the corresponding key from the key management system. Although the primary and backup databases can share a key management system, they each need to use their own keys and cannot share them. The encryption module is responsible for encrypting the local historical data using the local key and then synchronizing it to the other party through the ledger history synchronization module. The encryption / decryption module is also responsible for decrypting the historical data saved by the other party during verification and repair processes. Decryption also uses the local key. Since encryption and decryption are both completed within the same database instance, using symmetric encryption algorithms such as AES (Advanced Encryption Standard) will result in better performance for the encryption / decryption module. However, the technical solution proposed in this application can also use asymmetric encryption algorithms.

[0126] Additionally, it's worth noting that employing a sampling strategy can significantly reduce the resource consumption associated with bidirectional synchronization. For example, sampling at a minute frequency requires only 1440 synchronizations per day, with the synchronized record (only synchronizing hash values ​​representing the current system state) amounting to 1440 * 32 bytes = 46.08KB. Sampling at a second frequency results in 2.76MB of data. The resource consumption in terms of computation and storage is negligible compared to the database load.

[0127] When a sampling strategy is used for historical record synchronization, a log-based consistency sampling method can be adopted to ensure the consistency of the historical record sampling sets between the primary and standby databases. When the primary database synchronizes historical records to the standby database, the used sampling points should be written to the log and replicated to the standby database. When the standby database replays sampling points, it should check whether the ledger data and its historical records have been replayed completely before synchronizing the historical records of the standby database's ledger data to the primary database (see reference). Figure 4 ).

[0128] The historical data synchronization module should include encryption to ensure system security. Data should be encrypted before being sent to the recipient. It must be ensured that the data cannot be tampered with on the recipient's server (although it can be compromised). The historical data synchronization modules for the primary and backup databases should not use the same encryption key.

[0129] In the solution proposed in this application, data verification adopts joint verification of primary and backup data (see reference). Figure 5 First, the node initiating the data verification performs its own data verification. This verification can use traditional ledger database verification methods. If its own data verification fails, the joint verification fails. Second, if the node's data verification passes, it sends a data verification request to the other node. For example, if the primary database is the data verification initiator, it sends a data verification request to the backup database. The other node returns the data verification result. If the other node's data verification result fails, the joint verification fails. Third, if both the primary and other nodes pass the data verification, the primary database retrieves the hash value of the latest operation from the backup database. If the hash value of the backup database's latest operation is in the primary database's history, then the backup database's history is in the primary database's history; that is, the backup database's history is a subset of the primary database's history. The data verification passes; otherwise, the data verification fails. If all the above verification steps pass, the joint verification passes.

[0130] In the solution proposed in this application, the core of data repair is determining the trustworthiness of the data. After determining the trustworthiness of the ledger data, trustworthy data can be used to overwrite untrustworthy data, or untrustworthy data can be repaired according to a configurable repair strategy.

[0131] The basic rules for judging data credibility are as follows: If the ledger data itself fails verification, the server where the ledger data is located is at risk of being compromised and is not trustworthy; if the ledger data is inconsistent with the other party's historical records and the other party's historical records are complete after decryption, the server itself is at risk of being compromised and is not trustworthy; if the ledger data is inconsistent with the other party's historical records and the other party's historical records cannot be decrypted, the other party's server is at risk of being compromised and is not trustworthy.

[0132] More specifically, the rules for data credibility assessment and data repair are detailed as follows:

[0133] 1. If the primary database ledger data passes verification but the standby database ledger data fails verification, and the primary database ledger data is consistent with the historical data of the primary database ledger data stored on the standby database, then the primary database ledger data is trustworthy, while the standby database ledger data is untrustworthy, and the primary database ledger data must be used to overwrite the standby database ledger data.

[0134] 2. If the primary database ledger data passes verification, but the standby database ledger data fails verification, and the primary database ledger data is inconsistent with the historical data of the primary database ledger stored on the standby database, then the reliability of the primary database ledger data is unknown, and the standby database ledger data is untrustworthy. In this case, a remediation plan can be determined based on configurable strategies. For example, given the low probability of both the primary and standby databases being compromised simultaneously, the primary database data can be trusted, and its ledger data can be used to overwrite the standby database ledger data; alternatively, the primary database data can be distrusted, and data can be restored from the primary database based on backups and logs before overwriting the standby database ledger data.

[0135] 3. If the primary database ledger data fails verification but the standby database ledger data passes verification, and the standby database ledger data is consistent with the historical standby database ledger data stored on the primary database, then the primary database ledger data is untrusted, while the standby database ledger data is trustworthy. The standby database ledger data should be used to overwrite the primary database ledger data.

[0136] 4. If the primary database ledger data fails verification, but the standby database ledger data passes verification, and the standby database ledger data is inconsistent with the historical standby database ledger data stored on the primary database, then the primary database ledger data is untrustworthy, and the trustworthiness of the standby database ledger data is unknown. In this case, a remediation plan can be determined based on configurable strategies. For example, given the low probability of both the primary and standby databases being compromised simultaneously, the standby database data can be trusted, and its ledger data can be used to overwrite the primary database ledger data; alternatively, the standby database data can be distrusted, and data can be restored from the standby database based on backups and logs before overwriting the primary database ledger data.

[0137] 5. If both the primary database ledger data and the standby database ledger data pass the verification, but the primary database ledger data is inconsistent with the standby database ledger data, while the standby database ledger data is consistent with the historical standby database ledger data stored on the primary database, and the primary database ledger data is inconsistent with the historical primary database ledger data stored on the standby database, then it means that the primary database ledger data is untrusted and the standby database data is trustworthy. The standby database ledger data should be used to overwrite the primary database ledger data.

[0138] 6. If the primary database ledger data and the standby database ledger data both pass the data verification, but the primary database ledger data is inconsistent with the standby database ledger data, or the standby database ledger data is inconsistent with the historical standby database ledger data stored on the primary database, then it means that the primary database ledger data is trustworthy, while the standby database data is not trustworthy. In this case, the primary database ledger data should be used to overwrite the standby database ledger data.

[0139] 7. If both the primary and standby database ledgers pass verification, but the primary and standby ledgers are inconsistent, the historical records of the standby ledger stored on the primary database have been corrupted, and the primary ledger data is inconsistent with the historical records of the primary ledger stored on the standby database, then the primary ledger data is untrustworthy, and the trustworthiness of the standby data is unknown. In this case, a remediation plan can be determined based on configurable strategies. For example, given the low probability of both the primary and standby databases being compromised simultaneously, the standby data can be trusted, and its ledger data can be used to overwrite the primary ledger data; alternatively, the standby data can be distrusted, and data can be restored from the standby database based on backups and logs before overwriting the primary ledger data.

[0140] 8. If both the primary and standby database ledgers pass verification, but the primary and standby ledgers are inconsistent, indicating that the historical records of the primary database ledger stored on the standby have been corrupted and are inconsistent with the historical records of the standby ledger stored on the primary, then the reliability of the primary database ledger is unknown, and the standby data is untrustworthy. In this case, a remediation plan can be determined based on configurable strategies. For example, given the low probability of both the primary and standby databases being compromised simultaneously, the primary database data can be trusted, and its ledger data can be used to overwrite the standby ledger data; alternatively, the primary database data can be distrusted, and data can be restored from the primary database based on backups and logs before overwriting the standby ledger data.

[0141] 9. In addition to the above situations, if the primary database ledger data and the standby database ledger data both pass the data verification, but the primary database ledger data and the standby database ledger data are inconsistent, the historical data records of the other party saved by the primary and standby databases are both destroyed, and the ledger data is inconsistent with the historical data records of the ledger data saved by the other party node, it means that the primary and standby database data are not trustworthy and need to be restored from a trustworthy data backup.

[0142] In the above rules, the consistency between the primary database ledger data and the standby database ledger data can be verified using existing ledger data verification methods; the consistency between the primary database ledger data and the standby database ledger data can be determined by the method described above, namely, whether the operation history of the standby database is a subset of the operation history of the primary database; the consistency between the primary database ledger data and the ledger data history stored in the standby database, and the consistency between the standby database ledger data and the standby database ledger data history stored in the primary database, can be achieved by checking whether the decrypted counterpart's ledger data history is a subset of the local ledger data.

[0143] It should be noted that the above data anti-tampering methods are based on a primary-secondary database architecture. The technical solution proposed in this application can be further extended to primary-multiple-secondary, cascaded primary-secondary, and other primary-secondary architectures. By increasing the number of backup databases, the risk of the cluster being completely synchronized can be further reduced, the accuracy of data trustworthiness assessment can be increased, and the probability of accurate recovery of ledger data can be improved. Furthermore, the technical solution proposed in this application can also be applied to highly available distributed databases based on a primary-secondary architecture.

[0144] In summary, this application proposes a method to enhance data security by adding cross-encrypted bidirectional redundancy or backup of historical ledger data in a ledger database employing a master-slave architecture. This method can more effectively detect data tampering and can recover data even if the master and slave databases are not simultaneously compromised. Specifically, by using a master-slave architecture to add cross-encrypted historical ledger data redundancy independent of the data table management method, the data recovery capability of the ledger data is increased, thus improving the security of traditional ledger databases. Furthermore, by utilizing master-slave joint verification, database tampering can be detected more promptly and effectively through consistency checks between the master and slave databases.

[0145] Figure 6 This application illustrates a data anti-tampering device 60 according to an embodiment of the present application. The device is applied to a ledger database system including a primary database and a backup database, such as... Figure 6 As shown, the data anti-tampering device 60 includes:

[0146] The execution module 61 is used to obtain the master database ledger data stored in the master database and the standby database ledger data stored in the standby database respectively, and perform joint data verification on the master database and the standby database based on the master database ledger data, the standby database ledger data, the master database historical record copy stored in the standby database and the standby database historical record copy stored in the master database, and obtain the verification result.

[0147] The credibility judgment module 62 is used to determine the credibility of the main database ledger data and the credibility of the backup database ledger data based on the verification result, the main database ledger data, the main database historical record copy, the backup database ledger data and the backup database historical record copy, and obtain a credibility judgment result.

[0148] The data repair module 63 is used to repair untrusted ledger data based on the credibility judgment result, wherein the ledger data includes: primary database ledger data and / or backup database ledger data.

[0149] In one possible implementation, the data tamper-proof device 60 further includes:

[0150] The synchronization module is used to obtain the ledger data history records of the primary database and the ledger data history records of the backup database; encrypt the ledger data history records of the primary database and synchronize them to the backup database to obtain a copy of the primary database history records stored in the backup database; encrypt the ledger data history records of the backup database and synchronize them to the primary database to obtain a copy of the backup database history records stored in the primary database.

[0151] In one possible implementation, the acquisition module 601 is further configured to acquire the first hash chain information corresponding to the operation history of the primary database ledger data, and use the first hash chain information as the ledger data history of the primary database; encrypt the ledger data history of the primary database using the first key and then synchronize it to the backup database to obtain a copy of the primary database history; acquire the second hash chain information corresponding to the operation history of the backup database ledger data, and use the second hash chain information as the ledger data history of the backup database; encrypt the ledger data history of the backup database using the second key and then synchronize it to the primary database to obtain a copy of the backup database history.

[0152] In one possible implementation, the ledger data history is either the hash chain information corresponding to the operation history of the entire ledger data, or the sampling history obtained by sampling the hash chain information, wherein the hash chain information includes: first hash chain information and second hash chain information.

[0153] In one possible implementation, when the ledger data history is a sampling history, the acquisition module 601 is also used to take either the primary database or the backup database as the sampling initiating node and the other database as the other sampling node.

[0154] On the sampling initiating node side, determine the sampling points corresponding to the sampling history of the sampling initiating node. When synchronizing the sampling history to the other sampling node, write the sampling points into the synchronization log and copy the synchronization log to the other sampling node.

[0155] On the other party's sampling node side, the sampling points are replayed and aligned according to the synchronization log. It is checked whether the ledger data and historical records of the ledger data of the other party's sampling node have been replayed to the sampling points. After confirming that the data has been replayed to the sampling points, the ledger data historical records of the other party's sampling node are sampled and encrypted based on the sampling points. The encrypted sampling historical records of the other party's sampling node are then synchronized to the sampling initiating node.

[0156] In one possible implementation, the execution module 602 is further configured to use either the primary database or the backup database as the verification initiating node and the other database as the peer verification node.

[0157] On the verification initiating node side, local verification is performed on its own ledger data. If the local verification fails, it is determined that the joint data verification has failed.

[0158] If the local verification passes, the verification initiating node sends a data verification request to the peer verification node and obtains the peer verification node's local verification result after performing local verification on its own ledger data based on the data verification request; if the peer verification node's local verification result fails, the joint data verification is determined to have failed.

[0159] If the local verification result of the other party's verification node is passed, then obtain the hash value of the latest operation of the other party's verification node, and determine whether the hash value of the latest operation of the other party's verification node exists in the historical record copy of the other party's verification node stored by the verification initiating node; if it does not exist, then determine that the joint data verification has failed.

[0160] If the hash value of the latest operation of the other party's verification node exists in the historical record copy of the other party's verification node stored by the verification initiating node, then obtain the hash value of the latest operation of the verification initiating node and determine whether the hash value of the latest operation of the verification initiating node exists in the historical record copy of the verification initiating node stored by the other party's verification node; if it exists, then the joint data verification is determined to be successful; if it does not exist, then the joint data verification is determined to be unsuccessful.

[0161] In one possible implementation, the execution module 602 is further configured to determine the trustworthiness of the primary database ledger data based on the verification results and the consistency between the primary database historical record copy and the primary database ledger data; and to determine the trustworthiness of the backup database ledger data based on the verification results and the consistency between the backup database historical record copy and the backup database ledger data; wherein the trustworthiness judgment result includes at least one of the following: trustworthy, untrustworthy, or trustworthiness unknown.

[0162] In one possible implementation, the execution module 602 is further configured to determine that the master database ledger data is untrustworthy if the verification result of the master database fails.

[0163] If the verification result of the primary database passes, the primary database history copy is decrypted using the first key. If the decryption is successful, it is determined whether the decrypted primary database history copy is a subset of the primary database ledger data history. If it is a subset, the primary database ledger data is considered trustworthy; if it is not a subset, the primary database ledger data is considered untrustworthy. If the decryption fails, the trustworthiness of the primary database ledger data is considered unknown.

[0164] In one possible implementation, the execution module 602 is further configured to determine that the backup database ledger data is untrustworthy if the verification result of the backup database fails.

[0165] If the verification result of the backup database passes, the backup database history copy is decrypted using the second key. If the decryption is successful, it is determined whether the decrypted backup database history copy is a subset of the backup database's ledger data history. If it is a subset, the backup database ledger data is considered trustworthy; if it is not a subset, the backup database ledger data is considered untrustworthy. If the decryption fails, the trustworthiness of the backup database ledger data is considered unknown.

[0166] In one possible implementation, the execution module 602 is further configured to overwrite the backup ledger data with the primary ledger data if the trustworthiness judgment result is that the primary ledger data is trustworthy and the backup ledger data is untrustworthy.

[0167] If the credibility assessment result is that the backup ledger data is trustworthy and the primary ledger data is untrustworthy, the backup ledger data will be used to overwrite the primary ledger data.

[0168] If the trustworthiness assessment result shows that neither the primary database ledger data nor the backup database ledger data is trustworthy, the primary database ledger data and the backup database ledger data are restored from the preset trustworthy data backup.

[0169] If the credibility assessment result is that either the primary database ledger or the backup database ledger is untrustworthy and the credibility of the other is unknown, data repair will be performed according to the preset repair strategy.

[0170] In one possible implementation, the pre-defined repair strategy includes at least one of the following: overwriting the ledger data of the untrusted party with the ledger data of the party whose trustworthiness is unknown; and after restoring data from a pre-defined data backup of the party whose trustworthiness is unknown, overwriting the ledger data of the untrusted party with the restored data.

[0171] In one possible implementation, the master-slave architecture of the ledger database system includes at least one of the following: a master-slave architecture, a master-multiple-slave architecture, or a cascaded master-slave architecture; the ledger database system is a highly available distributed database system based on a master-slave architecture.

[0172] In summary, by encrypting and synchronizing the historical ledger data of the primary database to the standby database, and encrypting and synchronizing the historical ledger data of the standby database to the primary database, the system gains access to historical proof information stored by the other node, in addition to the primary and standby databases each storing their current ledger data. Therefore, when verifying the primary and standby databases, it no longer relies solely on the local ledger verification results of a single node. Instead, it can combine the primary database ledger data, the standby database ledger data, and the historical records stored cross-referenced by both databases for joint judgment. This makes it easier to detect inconsistencies between the primary and standby databases, as well as between the ledger data and historical records, improving the ability to identify abnormal states. When the joint data verification fails, the system further combines the primary database ledger data, the standby database ledger data, and the corresponding historical records to separately determine the credibility of the data on both sides. This provides a clearer basis for subsequent repairs, ensuring that data repair is based on a trusted source, preventing the further propagation of abnormal data, and enabling the system to recover even if the primary and standby databases do not fail simultaneously. In conclusion, the technical solution of this application possesses high accuracy in data tampering detection and strong data recovery capabilities.

[0173] This application provides a network device 70, such as... Figure 7 As shown, the network device 70 includes a processor 701, a memory 702, and a program stored in the memory 702 and executable on the processor 701. When the program is executed by the processor 701, it implements the steps of a data anti-tampering method as shown in the above embodiment.

[0174] This application also provides a computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements the steps of a data anti-tampering method as shown in the above embodiments, achieving the same technical effect. To avoid repetition, it will not be described again here. The computer-readable storage medium may include, for example, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0175] This application also provides a computer program product, including computer instructions. When executed by a processor, the computer instructions implement the steps of the data anti-tampering method shown in the above embodiments and achieve the same technical effect. To avoid repetition, they will not be described again here.

[0176] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0177] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0178] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A method for preventing data tampering, characterized in that, The method is applied to a ledger database system that includes a primary database and a standby database, and the method includes: The master database ledger data stored in the master database and the standby database ledger data stored in the standby database are obtained respectively. Based on the master database ledger data, the standby database ledger data, the master database historical record copy stored in the standby database, and the standby database historical record copy stored in the master database, a joint data verification is performed on the master database and the standby database to obtain the verification result. Based on the verification results, the primary database ledger data, the primary database historical record copy, the backup database ledger data, and the backup database historical record copy, the reliability of the primary database ledger data and the reliability of the backup database ledger data are determined, and a reliability judgment result is obtained. Based on the credibility judgment result, data repair is performed on untrusted ledger data, wherein the ledger data includes: primary database ledger data and / or backup database ledger data.

2. The method according to claim 1, characterized in that, Based on the primary database ledger data, the standby database ledger data, the primary database historical record copy stored in the standby database, and the standby database historical record copy stored in the primary database, a joint data verification is performed on the primary database and the standby database. Prior to this, the verification also includes: Obtain the historical ledger data of the primary database and the historical ledger data of the backup database; The ledger data history of the primary database is encrypted and synchronized to the backup database to obtain a copy of the primary database history stored in the backup database; The historical ledger data of the backup database is encrypted and synchronized to the primary database to obtain a copy of the historical ledger data of the backup database stored in the primary database.

3. The method according to claim 2, characterized in that, The ledger data history of the primary database is encrypted and synchronized to the backup database to obtain a copy of the primary database history stored in the backup database; The historical ledger data of the backup database is encrypted and synchronized to the primary database to obtain a copy of the backup database's historical data stored in the primary database, including: Obtain the first hash chain information corresponding to the operation history of the master database ledger data, and use the first hash chain information as the ledger data history of the master database; After encrypting the ledger data history of the primary database using the first key, the data is synchronized to the backup database to obtain a copy of the primary database's history. Obtain the second hash chain information corresponding to the operation history of the backup database ledger data, and use the second hash chain information as the historical ledger data of the backup database; After encrypting the historical ledger data of the backup database using the second key, the data is synchronized to the primary database to obtain a copy of the historical records of the backup database.

4. The method according to claim 3, characterized in that, The ledger data history is the hash chain information corresponding to the operation history of the entire ledger data, or it is the sampling history obtained by sampling the hash chain information. The hash chain information includes: first hash chain information and second hash chain information.

5. The method according to claim 4, characterized in that, If the ledger data history is the sampled history, the ledger data history of the primary database is encrypted and synchronized to the backup database to obtain a copy of the primary database history stored in the backup database. The historical ledger data of the backup database is encrypted and synchronized to the primary database to obtain a copy of the backup database's historical data stored in the primary database, including: Either the primary database or the backup database is used as the sampling initiating node, and the other is used as the peer sampling node. On the sampling initiating node side, the sampling point corresponding to the sampling history of the sampling initiating node is determined. When synchronizing the sampling history to the other sampling node, the sampling point is written into the synchronization log and the synchronization log is copied to the other sampling node. On the other party's sampling node side, the sampling point is replayed and aligned according to the synchronization log. It is checked whether the ledger data and the historical ledger data of the other party's sampling node have been replayed to the sampling point. After confirming that the data has been replayed to the sampling point, the historical ledger data of the other party's sampling node is sampled and encrypted based on the sampling point. The encrypted historical sampling data of the other party's sampling node is then synchronized to the sampling initiating node.

6. The method according to claim 1, characterized in that, A joint data verification is performed on the primary database and the backup database to obtain the verification result, including: Either the primary database or the backup database is used as the verification initiating node, and the other is used as the peer verification node. On the verification initiating node side, a local verification is performed on its own ledger data. If the local verification fails, it is determined that the joint data verification has failed. If the local verification passes, the verification initiating node sends a data verification request to the peer verification node and obtains the peer verification node's local verification result after the peer verification node performs local verification on its own ledger data based on the data verification request; if the peer verification node's local verification result fails, it is determined that the joint data verification has failed. If the local verification result of the other party verification node is passed, then the hash value of the latest operation of the other party verification node is obtained, and it is determined whether the hash value of the latest operation of the other party verification node exists in the historical record copy of the other party verification node stored by the verification initiating node; if it does not exist, then it is determined that the joint data verification has failed. If the hash value of the latest operation of the peer verification node exists in the historical record copy of the peer verification node stored by the verification initiating node, then the hash value of the latest operation of the verification initiating node is obtained, and it is determined whether the hash value of the latest operation of the verification initiating node exists in the historical record copy of the verification initiating node stored by the peer verification node; if it exists, then the joint data verification is determined to be successful; if it does not exist, then the joint data verification is determined to be unsuccessful.

7. The method according to claim 3, characterized in that, Based on the verification results, the primary database ledger data, the primary database historical record copy, the standby database ledger data, and the standby database historical record copy, the reliability of the primary database ledger data and the reliability of the standby database ledger data are determined to obtain a reliability judgment result, including: Based on the verification results and the consistency between the primary database historical record copy and the primary database ledger data, the reliability of the primary database ledger data is determined. Based on the verification results and the consistency between the backup database historical record copy and the backup database ledger data, the reliability of the backup database ledger data is determined. The credibility judgment result includes at least one of the following: trustworthy, untrustworthy, or credibility unknown.

8. The method according to claim 7, characterized in that, Based on the verification results and the consistency between the primary database historical record copy and the primary database ledger data, the reliability of the primary database ledger data is determined, including: If the verification result of the master database fails, the master database ledger data is determined to be untrustworthy. If the verification result of the primary database passes, the first key is used to decrypt the primary database history copy. If the decryption is successful, it is determined whether the decrypted primary database history copy is a subset of the primary database's ledger data history. If it is a subset, the primary database ledger data is determined to be trustworthy; if it is not a subset, the primary database ledger data is determined to be untrustworthy. If the decryption fails, the trustworthiness of the primary database ledger data is determined to be unknown.

9. The method according to claim 7, characterized in that, Based on the verification results and the consistency between the backup database historical record copy and the backup database ledger data, the reliability of the backup database ledger data is determined, including: If the verification result of the backup database fails, the backup database ledger data is determined to be untrustworthy. If the verification result of the backup database passes, the second key is used to decrypt the backup database history copy. If the decryption is successful, it is determined whether the decrypted backup database history copy is a subset of the backup database's ledger data history. If it is a subset, the backup database ledger data is determined to be trustworthy; if it is not a subset, the backup database ledger data is determined to be untrustworthy. If the decryption fails, the trustworthiness of the backup database ledger data is determined to be unknown.

10. The method according to claim 7, characterized in that, Based on the credibility assessment results, data repair is performed on untrusted ledger data, including: If the credibility judgment result is that the primary database ledger data is trustworthy and the backup database ledger data is untrustworthy, the primary database ledger data shall be used to overwrite the backup database ledger data. If the credibility judgment result indicates that the backup database ledger data is trustworthy and the primary database ledger data is untrustworthy, the backup database ledger data is used to overwrite the primary database ledger data. If the credibility judgment result indicates that both the primary database ledger data and the backup database ledger data are untrustworthy, the primary database ledger data and the backup database ledger data are restored from a preset trusted data backup. If the credibility judgment result is that either the primary database ledger data or the backup database ledger data is untrustworthy and the credibility of the other is unknown, data repair is performed according to a preset repair strategy.

11. The method according to claim 10, characterized in that, The preset repair strategy includes at least one of the following: Overwrite the ledger data of the untrusted party with the ledger data of the party whose trustworthiness is unknown; After restoring data from a preset data backup of the party whose trustworthiness is unknown, the restored data is used to overwrite the ledger data of the untrusted party.

12. The method according to any one of claims 1 to 11, characterized in that, The master-slave architecture of the ledger database system includes at least one of the following: a master-slave architecture, a master-multiple-slave architecture, or a cascaded master-slave architecture; the ledger database system is a distributed database system implemented based on the master-slave architecture.

13. A data anti-tampering device, characterized in that, The apparatus is applied to a ledger database system comprising a primary database and a standby database, and the apparatus includes: The execution module is used to obtain the master database ledger data stored in the master database and the standby database ledger data stored in the standby database respectively, and perform joint data verification on the master database and the standby database based on the master database ledger data, the standby database ledger data, the master database historical record copy stored in the standby database and the standby database historical record copy stored in the master database, and obtain the verification result. The credibility judgment module is used to determine the credibility of the primary database ledger data and the credibility of the backup database ledger data based on the verification result, the primary database ledger data, the primary database historical record copy, the backup database ledger data and the backup database historical record copy, and obtain a credibility judgment result. The data repair module is used to repair untrusted ledger data based on the credibility judgment result, wherein the ledger data includes: primary database ledger data and / or backup database ledger data.

14. A network device, characterized in that, include: A processor, a memory, and a program stored in the memory and executable on the processor, wherein the program, when executed by the processor, implements the steps of the data anti-tampering method as described in any one of claims 1 to 12.

15. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the data anti-tampering method as described in any one of claims 1 to 12.

16. A computer program product, characterized in that, It includes computer instructions that, when executed by a processor, implement the steps of the data anti-tampering method as described in any one of claims 1 to 12.

Images