Data verification method and device based on block chain

Abstract

The invention discloses a data verification method and device based on a block chain. In the case, the block chain comprises a main chain block and a plurality of auxiliary chain blocks; performing credibility verification on the main chain block and the target auxiliary chain block in response to the data verification instruction; if the credibility verification result represents that the main chain block and the target auxiliary chain block are credible, obtaining a first hash value corresponding to the target RPKI data object from the target auxiliary chain block based on the identification information; obtaining a target RPKI data object downloaded from the data warehouse by the data relying party, and performing hash calculation on the target RPKI data object to obtain a second hash value; and verifying the target RPKI data object according to the first hash value and the second hash value to identify an abnormal change condition of the target RPKI data object. According to the method, by adopting a data warehouse and block chain hash dual-storage verification mechanism, the authenticity and integrity of the RPKI data object are effectively guaranteed, and the security and credibility of the RPKI are remarkably enhanced.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a data verification method and apparatus based on blockchain. Background Technology

[0002] As the scale and complexity of the global internet grow exponentially, the inherent security vulnerabilities of its core interconnection architecture—the routing mechanism between Autonomous Systems (AS) based on the Border Gateway Protocol (BGP)—have become increasingly prominent, posing a key bottleneck to cybersecurity and stability. Because BGP was not designed with embedded security and trust mechanisms, attacks such as prefix hijacking, path forgery, and route leakage are frequent, continuously threatening the reliable operation of the global digital economy, data sovereignty, and critical business systems.

[0003] To address these challenges, an inter-domain routing security system centered on Resource Public Key Infrastructure (RPKI) has emerged. This system establishes verifiable authorization relationships for IP address resource allocation and AS route announcements by introducing public-key cryptography and digital certificate mechanisms. However, existing RPKI systems and their evolutions (such as BGPsec and ASPA) still heavily rely on the traditional hierarchical Certificate Authority (CA) model. Data owners typically publish RPKI data objects to data warehouses by delegating to a higher-level CA or RIR. This centralized trust architecture presents a centralized security threat: under the hierarchical authorization mechanism, the trust anchor has single-point control. RPKI data objects in the RPKI system data warehouse (such as RRDP or rsync servers) are vulnerable to unilateral manipulation threats, including but not limited to data deletion, suppression, corruption, tampering, forgery injection, or unauthorized revocation, making it difficult to ensure the authenticity and integrity of the authentication data obtained by the data-dependent party (RP). Summary of the Invention

[0004] To address the aforementioned issues, this application provides a blockchain-based data verification method and apparatus, aiming to accurately identify abnormal changes in the target (such as tampering or destruction), effectively ensuring authenticity and integrity, thereby significantly enhancing the security and credibility of RPKI.

[0005] The embodiments of this application disclose the following technical solutions:

[0006] In a first aspect, this application provides a blockchain-based data verification method, wherein the blockchain includes a main chain block and multiple auxiliary chain blocks, the main chain block is used for trust anchoring of the auxiliary chain blocks, and the multiple auxiliary chain blocks are used for notarizing RPKI data objects based on different security mechanisms of Resource Public Key Infrastructure (RPKI). The method includes:

[0007] In response to the data verification command, the main chain block and the target auxiliary chain block are verified to obtain a trusted verification result. The data verification command carries the identification information of the target RPKI data object required by the data dependency party. The target auxiliary chain block is used to store the evidence record of the target RPKI data object. The trusted verification result is used to characterize whether the main chain block and the target auxiliary chain block are trusted.

[0008] If the trusted verification result indicates that the main chain block and the target auxiliary chain block are trusted, then based on the identification information, the first hash value corresponding to the target RPKI data object is obtained from the target auxiliary chain block;

[0009] Obtain the target RPKI data object downloaded from the data warehouse by the data dependency party, and perform a hash calculation on the target RPKI data object to obtain a second hash value;

[0010] The target RPKI data object is verified based on the first hash value and the second hash value to identify abnormal changes in the target RPKI data object.

[0011] In an optional implementation, the main chain block undergoes trusted verification, including:

[0012] Obtain the block header, the block body to be verified, and the first Merkle proof of the main chain block; the first Merkle proof includes the hash values ​​of all sibling nodes on the path from the first target leaf node to the root node of the Merkle tree, and the first target leaf node is the tree node corresponding to the main chain block;

[0013] Obtain the first Merkle root from the block header; the first Merkle root is the hash value of the root node of the Merkle tree;

[0014] Based on the block body to be verified, obtain the anchoring information corresponding to all the auxiliary chain blocks, and calculate the second Merkle root based on the anchoring information and the first Merkle proof;

[0015] If the first Merkle root is the same as the second Merkle root, then the main chain block is determined to be trustworthy;

[0016] If the first Merkle root is different from the second Merkle root, then the main chain block is determined to be untrustworthy.

[0017] In optional implementations, the target secondary chain block undergoes trusted verification, including:

[0018] Obtain the third Merkle root from the main chain block; the third Merkle root is the hash value of the target root node on the Merkle tree, the target root node is the root node within the range of the target auxiliary chain block, and the anchoring information of all auxiliary chain blocks within the range is synchronously uploaded to the main chain block.

[0019] Obtain the block header and second Merkle proof of the target auxiliary chain block, and perform a hash calculation on the block header of the target auxiliary chain block to obtain a third hash value; the second Merkle proof includes the hash values ​​of all sibling nodes on the path from the second target leaf node to the target root node, and the second target leaf node is the tree node corresponding to the target auxiliary chain block;

[0020] Based on the third hash value and the second Merkle proof, construct the target Merkle tree, and calculate the hash value of the root node of the target Merkle tree to obtain the fourth Merkle root;

[0021] If the third Merkle root is the same as the fourth Merkle root, then the target auxiliary chain block is determined to be trustworthy.

[0022] If the third Merkle root is different from the fourth Merkle root, then the target auxiliary chain block is determined to be untrustworthy.

[0023] In an optional implementation, the step of verifying the target RPKI data object based on the first hash value and the second hash value to identify abnormal changes in the target RPKI data object includes:

[0024] Obtain the fourth hash value corresponding to the target RPKI data object from the list of the manifest file of the data warehouse;

[0025] If the first hash value, the second hash value, and the fourth hash value are the same, then it is determined that the target RPKI data object has not undergone any abnormal changes;

[0026] If the first hash value, the second hash value, and the fourth hash value are different, then it is determined that the target RPKI data object has undergone the abnormal change.

[0027] In an optional implementation, following the response to the data verification instruction, the blockchain-based data verification method further includes:

[0028] The target RPKI data object is obtained from the data warehouse; the target RPKI data object includes a CA certificate, the manifest file list, and a security policy object file, the security policy object file including a route source authorization (ROA) file, an autonomous system provider authorization (ASPA) file, and a BGPsec certificate file.

[0029] The data warehouse is subjected to target verification based on the target RPKI data object to obtain an initial verification result. The initial verification result is used to characterize whether the data in the data warehouse is trustworthy. The target verification includes inventory verification, certificate verification, and security policy object verification. The inventory verification is used to verify whether all files in the inventory file are stored in the data warehouse. The certificate verification is used to verify whether the CA certificate has been revoked. The security policy object verification is used to verify whether the security policy object file has undergone abnormal changes.

[0030] If the initial verification result indicates that the data in the data warehouse is trustworthy, then the trustworthiness verification of the main chain block and the target auxiliary chain block will continue.

[0031] If the initial verification result indicates that the data in the data warehouse is untrustworthy, a first alarm message is generated; the first alarm message is used to alert the data dependent party that the data in the data warehouse is untrustworthy.

[0032] Among the optional implementation methods, blockchain-based data verification methods also include:

[0033] If the trusted verification result indicates that the main chain block and / or the target auxiliary chain block is untrusted, a second alarm message is generated; the second alarm message is used to prompt the data dependency party that the main chain block and / or the target auxiliary chain block is untrusted.

[0034] In an optional implementation, before performing trusted verification on the main chain block and the target auxiliary chain block respectively in response to the data verification instruction and obtaining the trusted verification result, the blockchain-based data verification method further includes:

[0035] Send the auxiliary chain registration request submitted by the auxiliary chain block to the main chain block;

[0036] The main chain blocks execute main chain consensus node voting verification based on the auxiliary chain registration request, so as to vote on the auxiliary chain blocks to be registered through consensus algorithm and obtain voting results;

[0037] If the voting result is greater than or equal to the first preset threshold, a secondary chain registration record is generated and sent to the secondary chain block.

[0038] The auxiliary chain block to be registered is created based on the auxiliary chain registration record.

[0039] In an optional implementation, after creating the auxiliary chain block to be registered based on the auxiliary chain registration record, the blockchain-based data verification method further includes:

[0040] If it is detected that a data publisher has published an RPKI data object to the data warehouse, then according to the RPKI security mechanism corresponding to the RPKI data object, the evidence storage information of the RPKI data object is stored in the corresponding auxiliary chain block.

[0041] In an optional implementation, after creating the auxiliary chain block to be registered based on the auxiliary chain registration record, the blockchain-based data verification method further includes:

[0042] If the number of currently registered auxiliary chain blocks is less than a second preset threshold, then sending the anchoring information of the registered auxiliary chain blocks to the main chain block is prohibited; the anchoring information includes the identifier, block range information, and Merkle root of the registered auxiliary chain blocks;

[0043] If the number of currently registered auxiliary chain blocks is greater than or equal to the second preset threshold, the anchoring information is sent to the main chain block.

[0044] The main chain block uses the identifier to authenticate the registered auxiliary chain block;

[0045] If the registered auxiliary chain block passes the identity verification, the anchoring information is written into the main chain block, and the anchoring certificate of the main chain block is sent to the registered auxiliary chain block; the anchoring certificate includes the hash value of the registered auxiliary chain block and the height of the main chain block;

[0046] If the registered auxiliary chain block fails the identity verification, a third alarm message is generated; the third alarm message is used to indicate that the registered auxiliary chain block is untrusted.

[0047] In a second aspect, this application provides a blockchain-based data verification device. The blockchain includes a main chain block and multiple auxiliary chain blocks. The main chain block is used for trust anchoring of the auxiliary chain blocks, and the multiple auxiliary chain blocks are used for notarizing RPKI data objects based on different security mechanisms of Resource Public Key Infrastructure (RPKI). The device includes:

[0048] The blockchain trusted verification module is used to respond to data verification instructions by performing trusted verification on the main chain block and the target auxiliary chain block respectively, and obtaining trusted verification results. The data verification instructions carry the identification information of the target RPKI data object required by the data dependency party. The target auxiliary chain block is used to store the evidence storage record of the target RPKI data object. The trusted verification results are used to characterize whether the main chain block and the target auxiliary chain block are trusted.

[0049] The evidence acquisition module is used to obtain the first hash value corresponding to the target RPKI data object from the target auxiliary chain block based on the identification information if the trusted verification result indicates that the main chain block and the target auxiliary chain block are trusted.

[0050] The data processing module is used to obtain the target RPKI data object downloaded by the data dependency from the data warehouse, and to perform hash calculation on the target RPKI data object to obtain a second hash value;

[0051] The data verification module is used to verify the target RPKI data object based on the first hash value and the second hash value in order to identify abnormal changes in the target RPKI data object.

[0052] In a third aspect, this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the aforementioned blockchain-based data verification method.

[0053] In a fourth aspect, this application provides a processor for running a computer program, which executes the aforementioned blockchain-based data verification method during runtime.

[0054] Compared with the prior art, this application has the following beneficial effects:

[0055] In the technical solution of this application, a blockchain architecture containing a main chain block and multiple auxiliary chain blocks is constructed. The main chain block is used to anchor the trust of the auxiliary chain blocks, and RPKI data objects are stored in multiple auxiliary chain blocks based on different security mechanisms of Resource Public Key Infrastructure (RPKI). This achieves the decoupling of trust anchoring and data storage functions through a layered architecture of "main chain - multiple auxiliary chains". This avoids the risk of relying on a single CA as a centralized trust anchor in traditional RPKI, and also avoids the problem of high blockchain operating pressure caused by directly writing all RPKI data objects into the main chain block.

[0056] By responding to data verification commands and based on the identification information of the target RPKI data object required by the data-dependent party carried in the data verification commands, trusted verification is performed on the main chain block and the target auxiliary chain block used to store the notarization record of the target RPKI data object. This yields a trusted verification result characterizing the trustworthiness of the main chain block and the target auxiliary chain block. This ensures that the validity of the stored data is verified only after both the main chain block and the target auxiliary chain block have passed consensus verification, thus fundamentally guaranteeing the authenticity of the RPKI data object obtained by the data-dependent party. If the trusted verification result indicates that the main chain block and the target auxiliary chain block are trustworthy, the corresponding identifier of the target RPKI data object is retrieved from the target auxiliary chain block based on the identification information. The system obtains the first hash value and simultaneously retrieves the target RPKI data object downloaded from the data warehouse by the data dependency party. It then performs a hash calculation on the target RPKI data object to obtain the second hash value. This ensures that the hash values ​​(i.e., the first and second hash values) serve as an immutable fingerprint of the target RPKI data object, guaranteeing the traceability of the data source. Finally, the system verifies the target RPKI data object based on the first and second hash values. This dual-storage verification mechanism, combining the data warehouse and blockchain hashes, accurately identifies abnormal changes (such as tampering or destruction) of the target RPKI data object, effectively guaranteeing the authenticity and integrity of the RPKI data object, thereby significantly enhancing the security and trustworthiness of RPKI. Attached Figure Description

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

[0058] Figure 1 A flowchart illustrating a blockchain-based data verification method provided in this application embodiment;

[0059] Figure 2 A flowchart illustrating a trusted verification process for a main chain block, provided as an embodiment of this application;

[0060] Figure 3 A flowchart illustrating a trusted verification process for a target auxiliary chain block, provided as an embodiment of this application;

[0061] Figure 4 A flowchart illustrating the process for identifying abnormal changes to a target RPKI data object, provided in an embodiment of this application;

[0062] Figure 5This is a schematic diagram of the structure of a blockchain-based data verification device provided in an embodiment of this application. Detailed Implementation

[0063] As described earlier, the global internet is currently divided into multiple Autonomous Systems (AS) that communicate with each other. AS numbers are used to identify the individual AS numbers used in the Border Gateway Protocol (BGP). BGP enables interconnection between ASes by exchanging route advertisements between them. However, BGP accepts any route advertised by an AS by default. Therefore, even if an AS advertises an IP prefix that does not belong to it, the advertisement will be accepted and propagated by the other end, leading to security issues such as prefix hijacking, path hijacking, and route leakage in BGP routing.

[0064] To address the aforementioned issues, an inter-domain routing security system centered on Resource Public Key Infrastructure (RPKI) emerged. RPKI improves the BGP protocol during the routing process, enabling the protection and verification of BGP routing information. RPKI is a Route Authority Authentication (ROA) based on digital signatures and security certificates. The main entities in the RPKI mechanism include: Certificate Authorities (CAs) within the certificate issuance system, data publishers, data warehouses, and Relying Parties (RPs). In the RPKI system, RPKI data objects (such as certificates, certificate revocation lists, manifests, and ROAs) are stored as files in a distributed data warehouse. These files are transferred from the data publisher to the data warehouse and downloaded by the data relying party for route verification. There are two main types of data publication: data owner-published data and data owner-delegated data publication.

[0065] However, existing RPKI systems and their evolution schemes (such as BGPsec and ASPA) still heavily rely on the traditional hierarchical Certificate Authority (CA) model. Data owners typically publish RPKI data objects to the data warehouse by delegating to a higher-level CA or RIR. This centralized trust architecture presents centralized security threats: under the hierarchical authorization mechanism, the trust anchor has a single point of control; RPKI data objects in the centralized data warehouse of the RPKI system (such as RRDP or rsync server) are vulnerable to unilateral manipulation threats, including but not limited to data deletion, suppression, corruption, tampering, forgery injection, or unauthorized revocation, making it difficult to ensure the authenticity and integrity of the authentication data obtained by the data-dependent party.

[0066] The inventors have proposed a blockchain-based data verification method. This method constructs a blockchain architecture that includes a main chain block and multiple auxiliary chain blocks. The main chain block is used to anchor the trust in the auxiliary chain blocks. In multiple auxiliary chain blocks, RPKI data objects are stored and proven based on different security mechanisms of Resource Public Key Infrastructure (RPKI). This achieves the decoupling of trust anchoring and data storage functions through a layered architecture of "main chain - multiple auxiliary chains". This avoids the risk of relying on a single CA as a centralized trust anchor in traditional RPKI, and also avoids the problem of high blockchain operating pressure caused by directly writing all RPKI data objects into the main chain block.

[0067] By responding to data verification commands and based on the identification information of the target RPKI data object required by the data-dependent party carried in the data verification commands, trusted verification is performed on the main chain block and the target auxiliary chain block used to store the notarization record of the target RPKI data object. This yields a trusted verification result characterizing the trustworthiness of the main chain block and the target auxiliary chain block. This ensures that the validity of the stored data is verified only after both the main chain block and the target auxiliary chain block have passed consensus verification, thus fundamentally guaranteeing the authenticity of the RPKI data object obtained by the data-dependent party. If the trusted verification result indicates that the main chain block and the target auxiliary chain block are trustworthy, the corresponding identifier of the target RPKI data object is retrieved from the target auxiliary chain block based on the identification information. The system obtains the first hash value and simultaneously retrieves the target RPKI data object downloaded from the data warehouse by the data dependency party. It then performs a hash calculation on the target RPKI data object to obtain the second hash value. This ensures that the hash values ​​(i.e., the first and second hash values) serve as an immutable fingerprint of the target RPKI data object, guaranteeing the traceability of the data source. Finally, the system verifies the target RPKI data object based on the first and second hash values. This dual-storage verification mechanism, combining the data warehouse and blockchain hashes, accurately identifies abnormal changes (such as tampering or destruction) of the target RPKI data object, effectively guaranteeing the authenticity and integrity of the RPKI data object, thereby significantly enhancing the security and trustworthiness of RPKI.

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

[0069] Method Implementation Examples

[0070] This application provides an embodiment of a blockchain-based data verification method, wherein the blockchain includes a main chain block and multiple auxiliary chain blocks. The main chain block is used for trust anchoring of the auxiliary chain blocks, and the multiple auxiliary chain blocks are used for notarization of RPKI data objects based on different security mechanisms of Resource Public Key Infrastructure (RPKI). It should be noted that the steps shown in the flowcharts in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although the flowcharts show a logical order, in some cases, the steps shown or described may be executed in a different order than that presented here.

[0071] It should be noted that this application constructs a blockchain architecture containing a main chain block and multiple auxiliary chain blocks, using the main chain block to anchor the auxiliary chain blocks with trust. This enables the main chain to act as a globally consistent root of trust, undertaking lightweight yet highly secure consensus and anchoring responsibilities. Furthermore, it utilizes different security mechanisms based on Resource Public Key Infrastructure (RPKI) in multiple auxiliary chain blocks to store RPKI data objects, achieving fine-grained and high-concurrency data storage of RPKI data objects. Thus, through the layered architecture of "main chain - multiple auxiliary chains," the trust anchoring and data storage functions are decoupled. This avoids the risks of relying on a single CA as a centralized trust anchor in traditional RPKI, and also avoids the high operational pressure on the blockchain caused by directly writing all RPKI data objects into the main chain block.

[0072] In one implementation, a blockchain-based data verification system can serve as the execution entity for the blockchain-based data verification method of this application. For ease of description, the blockchain-based data verification system will be referred to as the system below. The blockchain-based data verification system mainly consists of a main chain block, multiple auxiliary chain blocks, and a blockchain client. The blockchain client is deployed locally on the data-dependent party and can be used to synchronize information between the main chain block and auxiliary chain blocks, and to cache data. The blockchain client can also verify the auxiliary chain by comparing the Merkle root of the auxiliary chain anchoring information in the main chain block header with the Merkle proof provided by the auxiliary chain. The verification triggering conditions include: the blockchain client's first startup, auxiliary chain updates, and anomaly alarms. When performing RPKI data object verification operations, it compares data based on on-chain evidence.

[0073] Optionally, the main chain block can be used to anchor the hashes of multiple auxiliary chain blocks. The consensus nodes of the main chain block are initially established by five global regional internet registries (such as AFRINIC, APNIC, ARIN, LACNIC, and RIPE NCC). The main chain block deploys two types of core smart contracts: a chain registration contract and an anchoring management contract. A list of public keys for the identity of main chain nodes is pre-installed in the genesis block, used to verify the legitimacy of node identities. The main chain block can also be used to maintain auxiliary chain information, specifically including: auxiliary chain ID, auxiliary chain type, list of validating nodes, status, version number, etc. Status can include inactive, active, frozen, etc.

[0074] In one feasible implementation, multiple auxiliary chain blocks can submit registration requests (e.g., registration requests containing auxiliary chain type, initial node list, and consensus rules) to the main chain block through the main chain block's chain registration contract. The chain registration contract can be used to trigger voting verification by the main chain consensus nodes. If the voting results meet the passing conditions, the chain registration contract generates an auxiliary chain registration record (including auxiliary chain identifier information) and returns a registration success certificate to the auxiliary chain block. Specifically, this process includes the following steps:

[0075] Step 11: Send the auxiliary chain registration request submitted by the auxiliary chain block to the main chain block.

[0076] Step 12: The main chain consensus node votes to verify the auxiliary chain registration request based on the auxiliary chain block, so as to vote on the auxiliary chain block to be registered through the consensus algorithm and obtain the voting result.

[0077] Step 13: If the voting result is greater than or equal to the first preset threshold, a secondary chain registration record is generated and sent to the secondary chain block.

[0078] Step 14: Create a secondary chain block to be registered based on the secondary chain registration record.

[0079] It should be noted that steps 11-14 above are not shown in the figure.

[0080] In another feasible implementation, the auxiliary chain block can also submit an anchor package to the anchor management contract of the main chain block based on an event threshold (e.g., every N auxiliary chain blocks generated) or a time threshold (e.g., a timed event). This package includes the auxiliary chain identifier, block range information, and Merkle root. In this case, the main chain block can also authenticate the auxiliary chain block. If the authentication passes, the anchor management contract can write the auxiliary chain's Merkle root and other information into the main chain block and return an anchor certificate to the auxiliary chain block. This certificate contains the transaction hash and the main chain block height. If the authentication fails, the anchor management contract can return an error code and a reason. Specifically, this process includes the following steps:

[0081] Step 21: If the number of currently registered auxiliary chain blocks is less than the second preset threshold, then the anchoring information of the currently registered auxiliary chain blocks is prohibited from being sent to the main chain blocks.

[0082] In step 21, the anchoring information includes the identifier of the registered secondary chain block, the block range information, and the Merkle root. For example, anchoring information = {secondary chain ID, anchoring information type, start height, end height, Merkle root of the block range, timestamp}. The anchoring information type includes ANCHOR (anchoring) and REGISTER (registration), etc.

[0083] Step 22: If the number of currently registered auxiliary chain blocks is greater than or equal to the second preset threshold, then send the anchoring information of the currently registered auxiliary chain blocks to the main chain block.

[0084] Step 23: Verify the identity of the registered auxiliary chain blocks based on the identifiers of the main chain blocks.

[0085] Step 24: If the registered auxiliary chain block passes the identity verification, the anchoring information is written into the main chain block, and the anchoring certificate of the main chain block is sent to the registered auxiliary chain block.

[0086] In step 24, the anchoring credentials include the hash value of the registered secondary chain block and the height of the main chain block.

[0087] Step 25: If the registered auxiliary chain block fails to pass identity verification, a third alarm message is generated.

[0088] In step 25, the third alarm message is used to indicate that the registered auxiliary chain block is untrusted. For example, the third alarm message may include the error code and reason mentioned above.

[0089] It should be noted that steps 21-25 above are not shown in the figure.

[0090] In another feasible implementation, after creating a registerable auxiliary chain block based on the auxiliary chain registration record, if the system detects that the publisher has published an RPKI data object to the data warehouse, it can store the evidence information of the RPKI data object in the corresponding auxiliary chain block according to the settings for storing the RPKI data object content on the auxiliary chain. That is, the auxiliary chain block can manage the evidence data of the RPKI data object. The auxiliary chain block is divided according to different RPKI security mechanisms (e.g., RPKI base auxiliary chain, ROA auxiliary chain, ASPA auxiliary chain, BGPsec auxiliary chain). The nodes of the auxiliary chain block are the data object uploading mechanisms in the RPKI data warehouse; the ROA auxiliary chain is mandatory, and other auxiliary chains are optional. The evidence data for RPKI data objects includes the RPKI data object file hash and file metadata. The RPKI data object file hash is calculated based on a hash algorithm such as SHA-256. The file metadata may include the file name, file size, function tag, timestamp, etc. The "function tag" is used to identify the purpose of the file, such as CA certificate, manifest, certificate revocation list, ROA, ASPA, BGPsec.

[0091] For example, for RPKI trust chain data files such as CA certificates (e.g., CER_Data), manifests (e.g., Manifest_Data), and certificate revocation lists (e.g., CRL_Data), the system can perform hash operations SHA-256 (e.g., CER_Data), SHA-256 (e.g., Manifest_Data), and SHA-256 (e.g., CRL_Data) respectively, and upload the hash values ​​to the RPKI base chain. For the RPKI ROA data file ROA_Data, the system can perform a hash operation SHA-256 (e.g., ROA_Data) and upload the hash value to the RPKI base chain. For the ASPA data file ASPA_Data, the system can perform a hash operation SHA-256 (e.g., ASPA_Data) and upload the hash value to the ASPA chain. For the BGPsec data file BGPsec_Data, the system can perform a hash operation SHA-256 (e.g., BGPsec_Data) and upload the hash value to the BGPsec chain.

[0092] See Figure 1 The figure is a flowchart of a blockchain-based data verification method provided in an embodiment of this application, as shown below. Figure 1 As shown, the method includes the following steps:

[0093] Step S101: In response to the data verification command, perform trusted verification on the main chain block and the target auxiliary chain block respectively, and obtain trusted verification results.

[0094] In step S101, the data verification instruction carries the identification information of the target RPKI data object required by the data dependent party (such as the RPKI data object file name, etc.), the target auxiliary chain block is used to store the evidence record of the target RPKI data object, and the trusted verification result is used to characterize whether the main chain block and the target auxiliary chain block are trusted.

[0095] In this embodiment, the system can respond to a data verification command and, based on the identification information of the target RPKI data object required by the data dependency party carried in the data verification command, perform trusted verification on the main chain block and the target auxiliary chain block used to store the evidence record of the target RPKI data object, respectively. This results in a trusted verification result that characterizes whether the main chain block and the target auxiliary chain block are trusted. This ensures that the validity of the stored data is recognized only when both the main chain block and the target auxiliary chain block have passed consensus verification, thereby fundamentally ensuring the authenticity of the RPKI data object obtained by the data dependency party.

[0096] See Figure 2 The figure is a flowchart of a trusted verification process for a main chain block provided in an embodiment of this application. The process includes the following steps:

[0097] Step S201: Obtain the block header, the block body to be verified, and the first Merkle proof of the main chain block.

[0098] In step S201, the first Merkle proof includes the hash values ​​of all sibling nodes on the path from the first target leaf node to the root node of the Merkle tree, where the first target leaf node is the tree node corresponding to the main chain block.

[0099] In this embodiment of the application, the block header of the main chain block may include the information shown in Table 1, and the block body to be verified may include the information shown in Table 2.

[0100] Table 1

[0101]

[0102] Table 2

[0103]

[0104] Step S202: Obtain the first Merkle root from the block header.

[0105] In step S202, the first Merkle root is the hash value of the root node of the Merkle tree.

[0106] Step S203: Obtain the anchoring information corresponding to all auxiliary chain blocks based on the block body to be verified, and calculate the second Merkle root based on the anchoring information and the first Merkle proof.

[0107] In this embodiment, the anchoring information is defined as {secondary chain ID, anchoring information type, start height, end height, Merkle root of the block range, timestamp}. The anchoring information type includes ANCHOR and REGISTER. The system can obtain the anchoring information corresponding to all secondary chain blocks based on the block body to be verified, and calculate the second Merkle root based on the anchoring information and the first Merkle proof, providing an accurate data foundation for the trusted verification of subsequent main chain blocks.

[0108] Step S204: If the first Merkle root is the same as the second Merkle root, then the main chain block is determined to be trustworthy.

[0109] Step S205: If the first Merkle root and the second Merkle root are not the same, then the main chain block is determined to be untrustworthy.

[0110] In this embodiment, the system efficiently verifies the integrity and trustworthiness of the main chain block by comparing the first Merkle root stored in the main chain block header with the second Merkle root recalculated based on the auxiliary chain anchoring information in the block body. If the first Merkle root and the second Merkle root are consistent, the system can determine that the anchoring data has not been tampered with and that the main chain block is trustworthy. If the first Merkle root and the second Merkle root are inconsistent, the system can determine that the anchoring data has been tampered with and that the main chain block is untrustworthy. This utilizes the cryptographic properties of the Merkle tree to ensure that any tampering with the auxiliary chain anchoring information can be accurately detected. While ensuring the authenticity of cross-chain evidence storage, it supports lightweight node verification, resists forgery attacks, and meets the core security requirements of RPKI data object evidence storage for auditability and immutability, significantly improving the reliability of trust anchors and the overall system security in a multi-chain architecture.

[0111] See Figure 3 The figure is a flowchart of a trusted verification process for a target auxiliary chain block provided in an embodiment of this application. The process includes the following steps:

[0112] Step S301: Obtain the third Merkle root from the main chain block.

[0113] In step S301, the third Merkle root is the hash value of the target root node on the Merkle tree. The target root node is the root node within the range of the target auxiliary chain block, and the anchoring information of all auxiliary chain blocks within the range is synchronously uploaded to the main chain block.

[0114] Step S302: Obtain the block header and second Merkle proof of the target auxiliary chain block, and perform a hash calculation on the block header of the target auxiliary chain block to obtain the third hash value.

[0115] In step S302, the second Merkle proof includes the hash values ​​of all sibling nodes on the path from the second target leaf node to the target root node, where the second target leaf node is the tree node corresponding to the target auxiliary chain block.

[0116] In this embodiment of the application, the block header of the auxiliary chain block may include the information shown in Table 3, and the block body may include the information shown in Table 4.

[0117] Table 3

[0118]

[0119] Table 4

[0120]

[0121] Step S303: Construct the target Merkle tree based on the third hash value and the second Merkle proof, and calculate the hash value of the root node of the target Merkle tree to obtain the fourth Merkle root.

[0122] Step S304: If the third Merkle root is the same as the fourth Merkle root, then the target auxiliary chain block is determined to be trustworthy.

[0123] Step S305: If the third Merkle root is different from the fourth Merkle root, then the target auxiliary chain block is determined to be untrusted.

[0124] In this embodiment, the system first obtains the target root node hash (third Merkle root) for the corresponding time interval from the main chain block, and then combines the block header hash (third hash value) of the target auxiliary chain block and its Merkle path to the target root node (second Merkle proof) to construct the target Merkle tree and calculate its root hash (i.e., fourth Merkle root). If the third Merkle root and the fourth Merkle root are consistent, the system can determine that the auxiliary chain block has not been tampered with and determine that it has passed the trusted verification. If the third Merkle root and the fourth Merkle root are inconsistent, the system can determine that the auxiliary chain block has been tampered with and determine that it has failed the trusted verification. This significantly improves verification efficiency, effectively isolates data from different time periods, enhances the system's anti-tampering capability and audit traceability, and provides a low-overhead, high-security auxiliary chain evidence verification path for light clients. It is particularly suitable for security infrastructure scenarios such as RPKI that require strict temporal consistency and large-scale object management.

[0125] It should be noted that by introducing a range-based Merkle tree structure grouped by creation time (i.e., the target Merkle tree), efficient, accurate and reliable verification of specific auxiliary chain blocks (i.e., target auxiliary chain blocks) is achieved.

[0126] Optionally, if the trusted verification result indicates that the main chain block and / or the target auxiliary chain block are untrusted, the system can generate a second alarm message; wherein the second alarm message is used to indicate that the main chain block and / or the target auxiliary chain block of the data dependency are untrusted.

[0127] In one feasible implementation, after responding to a data verification command, the system can first perform trusted verification of the target RPKI data object required by the data dependency through an RPKI verification method (i.e., target verification) to determine whether to continue executing trusted verification of the main chain block and the target auxiliary chain block. This improves RPKI security while effectively avoiding redundant on-chain verification overhead for invalid or revoked objects, significantly improving system efficiency. Traditional RPKI verification methods include CA certificate verification, manifest file verification, RPKI data object file integrity verification, consistency verification, and verification of routing security data (i.e., route origin authorization, route path, and route business relationship). Specifically, this process includes the following steps:

[0128] Step 31: Obtain the target RPKI data object from the data warehouse.

[0129] In step 31, the target RPKI data object includes a CA certificate, a list of manifest files, and a security policy object file. The security policy object file includes a route source authorization (ROA) file, an autonomous system provider authorization (ASPA) file, and a BGPsec certificate file.

[0130] Step 32: Perform target validation on the data warehouse based on the target RPKI data object to obtain the initial validation results.

[0131] In step 32, the initial verification result is used to characterize whether the data in the data warehouse is trustworthy. The target verification includes inventory verification, certificate verification, and security policy object verification. Inventory verification is used to verify whether all files in the inventory file are stored in the data warehouse. Certificate verification is used to verify whether the CA certificate has been revoked. Security policy object verification is used to verify whether the security policy object file has undergone abnormal changes.

[0132] Step 33: If the initial verification result indicates that the data in the data warehouse is trustworthy, then continue to perform trustworthy verification of the main chain block and the target auxiliary chain block.

[0133] Step 34: If the initial verification result indicates that the data in the data warehouse is unreliable, then generate the first alarm message.

[0134] In step 34, the first alarm message is used to indicate that the data in the data warehouse of the data dependency party is untrustworthy.

[0135] It should be noted that this application uses the RPKI verification method (i.e., target verification) to perform trusted verification on the target RPKI data object required by the data dependency party as a pre-verification step. Only after the data in the RPKI data warehouse has passed RPKI verification is the on-chain trusted verification of the corresponding main chain block and the target auxiliary chain block triggered. This achieves an organic combination of RPKI semantic security and blockchain immutability. While improving the overall security of RPKI, it effectively avoids the redundant on-chain verification overhead for invalid or revoked objects, improves system efficiency, and ensures that only semantically valid and on-chain evidence-based RPKI data objects are ultimately adopted, thereby constructing a dual guarantee mechanism of semantic correctness and trusted evidence.

[0136] It should be noted that steps 31-34 above are not shown in the figure.

[0137] Step S102: If the trusted verification result indicates that the main chain block and the target auxiliary chain block are trusted, then the first hash value corresponding to the target RPKI data object is obtained from the target auxiliary chain block based on the identification information.

[0138] Step S103: Obtain the target RPKI data object downloaded from the data warehouse by the data dependency party, and perform hash calculation on the target RPKI data object to obtain the second hash value.

[0139] In this embodiment of the application, if the trusted verification result indicates that the main chain block and the target auxiliary chain block are trusted, the system can obtain the first hash value corresponding to the target RPKI data object from the target auxiliary chain block based on the identification information. At the same time, it can obtain the target RPKI data object downloaded from the data warehouse by the data dependency party, and perform hash calculation on the target RPKI data object to obtain the second hash value. This realizes the use of hash values ​​(i.e., the first hash value and the second hash value) as the immutable fingerprint of the target RPKI data object, ensuring the traceability of the data source.

[0140] Step S104: Verify the target RPKI data object based on the first hash value and the second hash value to identify abnormal changes in the target RPKI data object.

[0141] In this embodiment, the system can verify the target RPKI data object based on the first hash value, the second hash value, and the fourth hash value obtained from the manifest file list of the data warehouse. This achieves a dual storage verification mechanism of data warehouse and blockchain hash, which accurately identifies abnormal changes (such as tampering or destruction) of the target RPKI data object, effectively ensuring the authenticity and integrity of the RPKI data object, thereby significantly enhancing the security and credibility of RPKI.

[0142] See Figure 4The figure is a flowchart of a process for identifying abnormal changes to a target RPKI data object according to an embodiment of this application. The process includes the following steps:

[0143] Step S1041: Obtain the fourth hash value corresponding to the target RPKI data object from the list of the data warehouse manifest file.

[0144] Step S1042: If the first hash value, the second hash value, and the fourth hash value are the same, then it is determined that the target RPKI data object has not undergone any abnormal changes.

[0145] Step S1043: If the first hash value, the second hash value, and the fourth hash value are different, it is determined that the target RPKI data object has undergone abnormal changes.

[0146] It should be noted that by comparing the first hash value of the target RPKI data object in the blockchain, the second hash value calculated for the target RPKI data object in the data warehouse, and the fourth hash value corresponding to the target RPKI data object in the manifest file list of the data warehouse, abnormal changes (such as deletion, suppression, damage, tampering, revocation, and injection) of the target RPKI data object are identified. This achieves effective protection of the authenticity and integrity of RPKI data objects through a multi-verification mechanism, thereby significantly enhancing the security and credibility of RPKI.

[0147] In one feasible implementation, the target RPKI data object can be an RPKI CA certificate file, an RPKI CRL file, an RPKI manifest file, an RPKI ROA object file, an RPKI ASPA object file, and an RPKI BGPsec object file, etc. The RPKI CA certificate file can be verified based on the RPKI underlying secondary chain. Specifically, the data-dependent party downloads the CA certificate file from the data warehouse, and the system can calculate a local hash CER_H1 based on this CA certificate file. Simultaneously, it queries the RPKI underlying secondary chain to obtain the certificate's storage hash CER_H2, and then compares whether CER_H1 and CER_H2 are equal. If they are equal, the object is accepted; otherwise, an alarm is triggered.

[0148] RPKI CRL files can be verified based on the RPKI underlying secondary chain. Specifically, the data-dependent party downloads the CRL file from the data warehouse, and the system can calculate the local hash CRL_H1 based on this CRL file. At the same time, it queries the RPKI underlying secondary chain to obtain the notarized hash CRL_H2 of this CRL, and then compares CRL_H1 and CRL_H2. If they are equal, the object is accepted; if they are not equal, an alarm is triggered.

[0149] The RPKI manifest file is verifiable based on the RPKI underlying secondary chain. Specifically, the data-dependent party downloads the manifest file from the data warehouse, and the system can calculate the local hash Manifest_H1 based on this manifest file. Simultaneously, it queries the RPKI underlying secondary chain to obtain the notarized hash Manifest_H2 of this Manifest, and then compares Manifest_H1 and Manifest_H2 to see if they are equal. If they are equal, the object is accepted; otherwise, an alert is triggered.

[0150] RPKI ROA object files can be verified based on the RPKI ROA secondary chain. Specifically, before traditional RPKI ROA object verification, the data-dependent party verifies the file's trustworthiness using the evidence-based data on the RPKI ROA secondary chain: RP downloads the RPKI ROA object file from the data warehouse and calculates its hash ROA_H1. It then queries the latest hash ROA_H2 of the corresponding object file from the RPKI ROA secondary chain. The calculated hash ROA_H1 of the object file is compared with the evidence-based hash ROA_H2 on the blockchain. If ROA_H1 and ROA_H2 are equal, the object is accepted. If ROA_H1 and ROA_H2 are not equal, an alert is triggered.

[0151] RPKI ASPA object files can be verified using the ASPA secondary chain. Specifically, before traditional RPKI ASPA object verification, the data-dependent party verifies the file's trustworthiness using evidence-based data on the ASPA secondary chain. RP downloads the RPKI ASPA object file from the data warehouse and calculates its hash ASPA_H1. It then queries the ASPA secondary chain for the latest hash ASPA_H2 of the corresponding object file. The calculated hash ASPA_H1 of the object file is compared and verified with the evidence-based hash ASPA_H2 on the blockchain. If ASPA_H1 and ASPA_H2 are equal, the object file is accepted. If ASPA_H1 and ASPA_H2 are not equal, an alert is triggered.

[0152] RPKI BGPsec object files are verified based on the BGPsec secondary blockchain. Specifically, before traditional RPKI BGPsec object verification, the data-dependent party verifies the file's trustworthiness using evidence-based data on the BGPsec secondary blockchain. RP downloads the RPKI BGPsec object file from the data warehouse and calculates its hash BGPsec_H1. It then queries the latest hash BGPsec_H2 of the corresponding object file from the BGPsec secondary blockchain. The calculated hash BGPsec_H1 of the object file is compared and verified with the evidence-based hash BGPsec_H2 on the blockchain. If BGPsec_H1 and BGPsec_H2 are equal, the object file is accepted. If BGPsec_H1 and BGPsec_H2 are not equal, an alert is triggered.

[0153] The blockchain-based data verification method provided in this application decouples trust anchoring and data storage functions through a layered architecture of "main chain - multiple auxiliary chains." This avoids the risks of relying on a single CA as a centralized trust anchor in traditional RPKI, and also avoids the high operational pressure on the blockchain caused by directly writing all RPKI data objects into the main chain block. It ensures that the validity of stored data is recognized only after both the main chain block and the target auxiliary chain block have passed consensus verification, thus fundamentally ensuring the authenticity of the RPKI data objects obtained by the data-dependent party. It uses hash values ​​(i.e., the first hash value and the second hash value) as the immutable fingerprint of the target RPKI data object, ensuring the traceability of the data source. Finally, it verifies the target RPKI data object based on the first and second hash values, achieving accurate identification of abnormal changes (such as tampering or destruction) of the target RPKI data object through a dual storage verification mechanism of data warehouse and blockchain hash, effectively ensuring the authenticity and integrity of the RPKI data object, thereby significantly enhancing the security and credibility of RPKI.

[0154] Device Examples

[0155] This application provides a blockchain-based data verification device, wherein the blockchain includes a main chain block and multiple auxiliary chain blocks. The main chain block is used to anchor trust in the auxiliary chain blocks, and the multiple auxiliary chain blocks are used to store RPKI data objects based on different security mechanisms of Resource Public Key Infrastructure (RPKI). Figure 5 A schematic diagram of a blockchain-based data verification device provided in this application embodiment is shown below. Figure 5 As shown, the device includes: a blockchain trusted verification module 51, a proof acquisition module 52, a data processing module 53, and a data verification module 54. Figure 5 You can see the connections between several modules.

[0156] Among them, the blockchain trusted verification module 51 is used to respond to the data verification command and perform trusted verification on the main chain block and the target auxiliary chain block respectively to obtain the trusted verification result. The data verification command carries the identification information of the target RPKI data object required by the data dependent party. The target auxiliary chain block is used to store the evidence record of the target RPKI data object. The trusted verification result is used to characterize whether the main chain block and the target auxiliary chain block are trusted.

[0157] The evidence acquisition module 52 is used to obtain the first hash value corresponding to the target RPKI data object from the target auxiliary chain block based on the identification information if the trusted verification result indicates that the main chain block and the target auxiliary chain block are trusted.

[0158] The data processing module 53 is used to obtain the target RPKI data object downloaded from the data warehouse by the data dependency party, and to perform hash calculation on the target RPKI data object to obtain a second hash value;

[0159] The data verification module 54 is used to verify the target RPKI data object based on the first hash value and the second hash value in order to identify abnormal changes in the target RPKI data object.

[0160] Optionally, the blockchain trusted verification module includes:

[0161] The first acquisition unit is used to acquire the block header, the block body to be verified, and the first Merkle proof of the main chain block. The first Merkle proof includes the hash values ​​of all sibling nodes on the path from the first target leaf node to the root node of the Merkle tree. The first target leaf node is the tree node corresponding to the main chain block.

[0162] The second acquisition unit is used to obtain the first Merkle root from the block header; the first Merkle root is the hash value of the root node of the Merkle tree;

[0163] The first calculation unit is used to obtain the anchoring information corresponding to all auxiliary chain blocks based on the block body to be verified, and to calculate the second Merkle root based on the anchoring information and the first Merkle proof.

[0164] The first determining unit is used to determine that the main chain block is trustworthy if the first Merkle root is the same as the second Merkle root.

[0165] The second determining unit is used to determine that the main chain block is untrusted if the first Merkle root and the second Merkle root are not the same.

[0166] Optionally, the blockchain trusted verification module also includes:

[0167] The third acquisition unit is used to acquire the third Merkle root from the main chain block; the third Merkle root is the hash value of the target root node on the Merkle tree, the target root node is the root node in the range of the target auxiliary chain block, and the anchoring information of all auxiliary chain blocks in the range is synchronously uploaded to the main chain block.

[0168] The second calculation unit is used to obtain the block header and the second Merkle proof of the target auxiliary chain block, and to perform a hash calculation on the block header of the target auxiliary chain block to obtain a third hash value; the second Merkle proof includes the hash values ​​of all sibling nodes on the path from the second target leaf node to the target root node, and the second target leaf node is the tree node corresponding to the target auxiliary chain block.

[0169] The building unit is used to construct the target Merkle tree based on the third hash value and the second Merkle proof, and to calculate the hash value of the root node of the target Merkle tree to obtain the fourth Merkle root;

[0170] The third determining unit is used to determine that the target auxiliary chain block is trustworthy if the third Merkle root is the same as the fourth Merkle root.

[0171] The fourth determining unit is used to determine that the target auxiliary chain block is untrusted if the third Merkle root is different from the fourth Merkle root.

[0172] Optionally, the data validation module includes:

[0173] The fourth acquisition unit is used to retrieve the fourth hash value corresponding to the target RPKI data object from the list of the manifest file in the data warehouse;

[0174] The fifth determining unit is used to determine that the target RPKI data object has not undergone abnormal changes if the first hash value, the second hash value, and the fourth hash value are the same.

[0175] The sixth determining unit is used to determine that the target RPKI data object has undergone abnormal changes if the first hash value, the second hash value, and the fourth hash value are different.

[0176] Optionally, the blockchain-based data verification device also includes:

[0177] The fifth acquisition unit is used to retrieve the target RPKI data object from the data warehouse after responding to the data verification command. The target RPKI data object includes a CA certificate, a list of manifest files, and a security policy object file. The security policy object file includes a route source authorization (ROA) file, an autonomous system provider authorization (ASPA) file, and a BGPsec certificate file.

[0178] The target verification unit is used to perform target verification on the data warehouse based on the target RPKI data object and obtain the initial verification result. The initial verification result is used to characterize whether the data in the data warehouse is trustworthy. Target verification includes manifest verification, certificate verification, and security policy object verification. Manifest verification is used to verify whether all files in the manifest file are stored in the data warehouse. Certificate verification is used to verify whether the CA certificate has been revoked. Security policy object verification is used to verify whether the security policy object file has undergone abnormal changes.

[0179] The execution unit is used to continue the trust verification of the main chain block and the target auxiliary chain block if the initial verification result indicates that the data in the data warehouse is trustworthy.

[0180] The first generation unit is used to generate a first alarm message if the initial verification result indicates that the data in the data warehouse is untrustworthy; the first alarm message is used to indicate that the data in the data warehouse of the data dependent party is untrustworthy.

[0181] Optionally, the blockchain-based data verification device also includes:

[0182] The second generation unit is used to generate a second alarm message if the trusted verification result indicates that the main chain block and / or the target auxiliary chain block is untrusted; the second alarm message is used to indicate that the main chain block and / or the target auxiliary chain block of the data dependency party is untrusted.

[0183] Optionally, the blockchain-based data verification device also includes:

[0184] The first data sending unit is used to send the auxiliary chain registration request submitted by the auxiliary chain block to the main chain block before performing trusted verification on the main chain block and the target auxiliary chain block respectively in response to the data verification instruction and obtaining the trusted verification result.

[0185] The node voting verification unit is used to perform main chain consensus node voting verification based on the auxiliary chain registration request through the main chain block, so as to vote on the auxiliary chain block to be registered through the consensus algorithm and obtain the voting result;

[0186] The third generation unit is used to generate a secondary chain registration record if the voting result is greater than or equal to the first preset threshold, and send the secondary chain registration record to the secondary chain block.

[0187] Create a unit, used to create a block of auxiliary chain to be registered based on the auxiliary chain registration record.

[0188] Optionally, the blockchain-based data verification device also includes:

[0189] The storage unit is used to store the evidence information of the RPKI data object into the corresponding auxiliary chain block after the auxiliary chain block to be registered is created based on the auxiliary chain registration record. If it is detected that the CA institution has issued an RPKI data object to the data warehouse, the storage unit will store the evidence information of the RPKI data object into the corresponding auxiliary chain block according to the RPKI security mechanism corresponding to the RPKI data object.

[0190] Optionally, the blockchain-based data verification device also includes:

[0191] The prohibition unit is used to prevent the sending of anchor information of registered auxiliary chain blocks to the main chain block after creating an auxiliary chain block to be registered based on the auxiliary chain registration record, if the number of currently registered auxiliary chain blocks is less than a second preset threshold; the anchor information includes the identifier of the registered auxiliary chain block, block range information and Merkle root;

[0192] The second data sending unit is used to send anchoring information to the main chain block if the number of currently registered auxiliary chain blocks is greater than or equal to the second preset threshold.

[0193] The authentication unit is used to authenticate registered auxiliary chain blocks based on identifiers through the main chain blocks;

[0194] The data writing unit is used to write anchoring information into the main chain block if the registered auxiliary chain block passes authentication, and to send the anchoring certificate of the main chain block to the registered auxiliary chain block; the anchoring certificate includes the hash value of the registered auxiliary chain block and the height of the main chain block;

[0195] The fourth generation unit is used to generate a third alarm message if a registered auxiliary chain block fails to pass identity verification; the third alarm message is used to indicate that the registered auxiliary chain block is untrusted.

[0196] Storage Media Examples

[0197] This application provides a computer-readable storage medium storing a program, which, when executed by a processor, implements some or all of the steps in the blockchain-based data verification method described in the foregoing method embodiments of this application. The storage medium can be any medium capable of storing program code, such as a USB flash drive, external hard drive, read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0198] Processor Implementation

[0199] This application provides a processor for running a program, wherein, during program execution, some or all of the steps in the blockchain-based data verification method described in the foregoing method embodiments are performed.

[0200] It should be noted that the various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for the device embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiments. The device embodiments described above are merely illustrative, and the units described as separate components may or may not be physically separate. The components indicated as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment solution according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0201] The above is merely one specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A data verification method based on blockchain, characterized in that, The blockchain includes a main chain block and multiple auxiliary chain blocks. The main chain block is used for trust anchoring of the auxiliary chain blocks. The multiple auxiliary chain blocks are used for notarization of RPKI data objects based on different security mechanisms of Resource Public Key Infrastructure (RPKI). The method includes: In response to the data verification command, the main chain block and the target auxiliary chain block are verified to obtain a trusted verification result. The data verification command carries the identification information of the target RPKI data object required by the data dependency party. The target auxiliary chain block is used to store the evidence record of the target RPKI data object. The trusted verification result is used to characterize whether the main chain block and the target auxiliary chain block are trusted. If the trusted verification result indicates that the main chain block and the target auxiliary chain block are trusted, then based on the identification information, the first hash value corresponding to the target RPKI data object is obtained from the target auxiliary chain block; Obtain the target RPKI data object downloaded from the data warehouse by the data dependency party, and perform a hash calculation on the target RPKI data object to obtain a second hash value; The target RPKI data object is verified based on the first hash value and the second hash value to identify abnormal changes in the target RPKI data object.

2. The method according to claim 1, characterized in that, The trusted verification of the main chain blocks includes: Obtain the block header, the block body to be verified, and the first Merkle proof of the main chain block; the first Merkle proof includes the hash values ​​of all sibling nodes on the path from the first target leaf node to the root node of the Merkle tree, and the first target leaf node is the tree node corresponding to the main chain block; Obtain the first Merkle root from the block header; the first Merkle root is the hash value of the root node of the Merkle tree; Based on the block body to be verified, obtain the anchoring information corresponding to all the auxiliary chain blocks, and calculate the second Merkle root based on the anchoring information and the first Merkle proof; If the first Merkle root is the same as the second Merkle root, then the main chain block is determined to be trustworthy; If the first Merkle root is different from the second Merkle root, then the main chain block is determined to be untrustworthy.

3. The method according to claim 2, characterized in that, Trust verification of the target secondary chain block includes: Obtain the third Merkle root from the main chain block; the third Merkle root is the hash value of the target root node on the Merkle tree, the target root node is the root node within the range of the target auxiliary chain block, and the anchoring information of all auxiliary chain blocks within the range is synchronously uploaded to the main chain block. Obtain the block header and second Merkle proof of the target auxiliary chain block, and perform a hash calculation on the block header of the target auxiliary chain block to obtain a third hash value; the second Merkle proof includes the hash values ​​of all sibling nodes on the path from the second target leaf node to the target root node, and the second target leaf node is the tree node corresponding to the target auxiliary chain block; Based on the third hash value and the second Merkle proof, construct the target Merkle tree, and calculate the hash value of the root node of the target Merkle tree to obtain the fourth Merkle root; If the third Merkle root is the same as the fourth Merkle root, then the target auxiliary chain block is determined to be trustworthy. If the third Merkle root is different from the fourth Merkle root, then the target auxiliary chain block is determined to be untrustworthy.

4. The method according to claim 1, characterized in that, The step of verifying the target RPKI data object based on the first hash value and the second hash value to identify abnormal changes in the target RPKI data object includes: Obtain the fourth hash value corresponding to the target RPKI data object from the list of the manifest file of the data warehouse; If the first hash value, the second hash value, and the fourth hash value are the same, then it is determined that the target RPKI data object has not undergone any abnormal changes; If the first hash value, the second hash value, and the fourth hash value are different, then it is determined that the target RPKI data object has undergone the abnormal change.

5. The method according to claim 4, characterized in that, Following the response to the data verification instruction, the method further includes: The target RPKI data object is obtained from the data warehouse; the target RPKI data object includes a CA certificate, the manifest file list, and a security policy object file, the security policy object file including a route source authorization (ROA) file, an autonomous system provider authorization (ASPA) file, and a BGPsec certificate file. The data warehouse is subjected to target verification based on the target RPKI data object to obtain an initial verification result. The initial verification result is used to characterize whether the data in the data warehouse is trustworthy. The target verification includes inventory verification, certificate verification, and security policy object verification. The inventory verification is used to verify whether all files in the inventory file are stored in the data warehouse. The certificate verification is used to verify whether the CA certificate has been revoked. The security policy object verification is used to verify whether the security policy object file has undergone abnormal changes. If the initial verification result indicates that the data in the data warehouse is trustworthy, then the trustworthiness verification of the main chain block and the target auxiliary chain block will continue. If the initial verification result indicates that the data in the data warehouse is untrustworthy, a first alarm message is generated; the first alarm message is used to alert the data dependent party that the data in the data warehouse is untrustworthy.

6. The method according to claim 1, characterized in that, The method further includes: If the trusted verification result indicates that the main chain block and / or the target auxiliary chain block is untrusted, a second alarm message is generated; the second alarm message is used to prompt the data dependency party that the main chain block and / or the target auxiliary chain block is untrusted.

7. The method according to claim 1, characterized in that, Before performing trusted verification on the main chain block and the target auxiliary chain block respectively in response to the data verification command and obtaining the trusted verification result, the method further includes: Send the auxiliary chain registration request submitted by the auxiliary chain block to the main chain block; The main chain blocks execute main chain consensus node voting verification based on the auxiliary chain registration request, so as to vote on the auxiliary chain blocks to be registered through consensus algorithm and obtain voting results; If the voting result is greater than or equal to the first preset threshold, a secondary chain registration record is generated and sent to the secondary chain block. The auxiliary chain block to be registered is created based on the auxiliary chain registration record.

8. The method according to claim 7, characterized in that, After creating the auxiliary chain block to be registered based on the auxiliary chain registration record, the method further includes: If it is detected that a data publisher has published an RPKI data object to the data warehouse, then according to the RPKI security mechanism corresponding to the RPKI data object, the evidence storage information of the RPKI data object is stored in the corresponding auxiliary chain block.

9. The method according to claim 7, characterized in that, After creating the auxiliary chain block to be registered based on the auxiliary chain registration record, the method further includes: If the number of currently registered auxiliary chain blocks is less than a second preset threshold, then sending the anchoring information of the registered auxiliary chain blocks to the main chain block is prohibited; the anchoring information includes the identifier, block range information, and Merkle root of the registered auxiliary chain blocks; If the number of currently registered auxiliary chain blocks is greater than or equal to the second preset threshold, the anchoring information is sent to the main chain block. The main chain block uses the identifier to authenticate the registered auxiliary chain block; If the registered auxiliary chain block passes the identity verification, the anchoring information is written into the main chain block, and the anchoring certificate of the main chain block is sent to the registered auxiliary chain block; the anchoring certificate includes the hash value of the registered auxiliary chain block and the height of the main chain block; If the registered auxiliary chain block fails the identity verification, a third alarm message is generated; the third alarm message is used to indicate that the registered auxiliary chain block is untrusted.

10. A blockchain-based data verification device, characterized in that, The blockchain includes a main chain block and multiple auxiliary chain blocks. The main chain block is used for trust anchoring of the auxiliary chain blocks. The multiple auxiliary chain blocks are used for notarization of RPKI data objects based on different security mechanisms of Resource Public Key Infrastructure (RPKI). The device includes: The blockchain trusted verification module is used to respond to data verification instructions by performing trusted verification on the main chain block and the target auxiliary chain block respectively, and obtaining trusted verification results. The data verification instructions carry the identification information of the target RPKI data object required by the data dependency party. The target auxiliary chain block is used to store the evidence storage record of the target RPKI data object. The trusted verification results are used to characterize whether the main chain block and the target auxiliary chain block are trusted. The evidence acquisition module is used to obtain the first hash value corresponding to the target RPKI data object from the target auxiliary chain block based on the identification information if the trusted verification result indicates that the main chain block and the target auxiliary chain block are trusted. The data processing module is used to obtain the target RPKI data object downloaded by the data dependency from the data warehouse, and to perform hash calculation on the target RPKI data object to obtain a second hash value; The data verification module is used to verify the target RPKI data object based on the first hash value and the second hash value in order to identify abnormal changes in the target RPKI data object.

Images