Hierarchical verification and data rights allocation system and method thereof

Abstract

The invention discloses a hierarchical verification and data right distribution system based on a hardware root of trust, and the system comprises a set certificate issuing root trust server which is used for carrying out the butt joint with a certificate issuing mechanism, completing the qualification authentication of an electronic signature making mechanism, and managing a verification data set; the quintuple packet terminal is used for performing private key signature on the data hash or the electronic signature data; the plurality of trusted content distribution network edge nodes are used for receiving the signature data of the quintuple packet, independently completing signature verification, generating right confirmation certificates including edge node hardware signatures, and reporting the right confirmation certificates to the set certificate communication root trust server; the block chain intelligent contract layer is used for storing the right confirmation voucher, registering data assets, verifying a data hash source and automatically executing income distribution; and the plurality of trusted content distribution network edge nodes generate right confirmation certificates after the signature verification is passed, and the right confirmation certificates are solidified to the block chain through the certificate collection and communication root trust server to serve as a unique basis for data ownership certification and subsequent income distribution.

Description

(19) State Intellectual Property Office (12) Invention Patent Application (10) Application Publication Number (43) Application Publication Date (21) Application Number 202610493131.0 (22) Application Date 2026.04.14 (71) Applicant Hangzhou Yuhua Technology Co., Ltd. Address 311258, Wangjiali, Chang'an Village, Wenyan Street, Xiaoshan District, Hangzhou City, Zhejiang Province Applicant Hu Jinqian Xilian Technology Co., Ltd. Xixin Technology Co., Ltd. Hangzhou Gaoxinmei Investment Consulting Co., Ltd. (72) Inventor Hu Jinqian Guo Ai (74) Patent Agency Shanghai Deyue Intellectual Property Agency (General Partnership) 31344 Patent Attorney Dong Danghong (51) Int.Cl. H04L 9 / 32 (2006.01) H04L 9 / 40 (2022.01) H04L 9 / 00 (2022.01) H04W 12 / 069 (2021.01) H04W 12 / 106 (2021.01) (54) Invention Title: A Layered Verification and Data Rights Allocation System and Method Thereof (57) Abstract: This invention discloses a layered verification and data rights allocation system based on a hardware root of trust, comprising: a unified certificate management root trust server, used to interface with certificate authorities to complete the qualification certification of electronic signature production institutions and manage the verification data set; a five-digit terminal, used to sign data hashes or electronic signature data with private keys; multiple trusted content distribution network edge nodes, used to receive the signature data of the five-digit terminal, independently complete signature verification and generate a certificate of ownership including the hardware signature of the edge node, and report the certificate of ownership to the unified certificate management root trust server; a blockchain smart contract layer, used to store the certificate of ownership, register data assets, verify the source of data hashes and automatically execute revenue distribution; the certificate of ownership generated by the multiple trusted content distribution network edge nodes after the signature verification is passed is solidified to the blockchain by the unified certificate management root trust server, serving as the sole basis for data ownership proof and subsequent revenue distribution. Claims (3 pages), Description (12 pages), Drawings (2 pages), CN 122372213 A, 2026.07.10, CN 1 22 37 22 13 A. 1. A hierarchical verification and data rights allocation system based on a hardware root of trust, comprising: a unified certificate management root trust server, used to interface with certificate authorities to complete the qualification certification of electronic signature creation institutions and manage verification data sets; a five-digit terminal, used to perform private key signing on data hashes or electronic signature data; multiple trusted content delivery network edge nodes, used to receive the signature data from the five-digit terminal, independently complete signature verification and generate a certificate of rights including the edge node hardware signature, and report the certificate of rights to the unified certificate management root trust server; a blockchain smart contract layer, used to store the certificate of rights, registered data assets, verification data hash source, and...Automatic revenue distribution; The ownership certificates generated by the multiple trusted content distribution network edge nodes after signature verification are solidified into the blockchain by the centralized certificate management root trust server, serving as the sole basis for data ownership proof and subsequent revenue distribution. 2. The hierarchical verification and data rights distribution system according to claim 1, characterized in that: the centralized certificate management root trust server includes a qualification authentication module and a data synchronization module; the qualification authentication module is used to interface with certificate authorities to perform low-frequency qualification authentication, which is only performed when the signature creation institution first connects or the certificate validity period is updated. After successful authentication, the public key certificate, signature tag, and status information of the signature creation institution are obtained; the data synchronization module is used to push the verification data set obtained by the qualification authentication module to each edge node through an encrypted synchronization protocol, and only push incremental change data when a new certificate authority connects or the certificate is updated; the edge nodes do not rely on real-time certificate authority queries, but independently complete high-frequency authenticity verification of each signature or each piece of data using locally cached public key certificates, signature tags, and status information. 3. The hierarchical verification and data rights allocation system according to claim 1, characterized in that: the edge nodes are also used to automatically query and verify the source root trust server or certificate authority in real time when the local cache is missing, realizing a compatibility and degradation mode with the traditional PKI system; the edge nodes communicate with each other via a 6G communication network with low latency, and when the local cache of a certain edge node is missing, it first initiates a real-time query request to the adjacent edge nodes through the 6G network to obtain the verification data cached by the neighboring nodes, and only returns to the source root trust server or certificate authority when neither of the adjacent nodes has a match. 4. The hierarchical verification and data rights allocation system according to claim 1, characterized in that: the root trust server for centralized certificate processing and the edge node both have built-in quantum-resistant cryptographic modules to support quantum-resistant signature algorithms based on lattice cryptography, multivariate cryptography, or hash-based signatures; during the system initialization phase, each component generates a quantum-resistant public-private key pair, wherein the quantum-resistant public key is used to verify the authenticity of the signature, and the quantum-resistant private key is used to perform quantum-resistant signatures on the confirmation certificate and verification data; when receiving signature data, the edge node prioritizes using the quantum-resistant signature algorithm for verification, and if the signature uses a traditional PKI algorithm, it is downgraded to the traditional verification mode. 5. The hierarchical verification and data rights allocation system according to claim 1, characterized in that: the five-digital packet terminal has built-in BeiDou positioning module and BeiDou short message communication module; when the five-digital packet terminal performs private key signature on the data hash, it simultaneously obtains the current geographical location information and the BeiDou satellite time stamp, and includes the location information and the BeiDou time stamp in the signature data packet; the edge node also includes a verification module, used to simultaneously verify the geographical location information and the BeiDou time stamp when verifying the signature.The validity of the timestamp is determined by whether the geographical location exceeds the preset authorized area or whether the deviation between the BeiDou timestamp and the local time of the edge node exceeds a preset threshold. If so, the signature is deemed invalid and the generation of the confirmation certificate is refused. The five-digit terminal also supports uploading the signature data to the BeiDou satellite via the BeiDou short message communication module in areas without terrestrial network coverage. The BeiDou satellite forwards the data to the ground station, and the ground station routes it to the nearest edge node. 6. The hierarchical verification and data rights allocation system according to any one of claims 1 to 5, characterized in that the system executes a dynamic benefit allocation algorithm based on contribution weight, the algorithm executing the following steps: When a batch of datasets including N data items is traded, for the i-th data item, its contribution weight factor wi=f(qi, ti, ri, li, si) is defined, where qi is the data quality score, automatically calculated by the edge node based on data integrity verification and signature validity; ti is the data freshness factor, ΔT is the time difference between the data generation time and the current time, and λ is the decay coefficient; ri is the data historical citation factor, ri=log(1+Ri), Ri is the number of times the data has been traded or cited on the chain; li is the data geographical value factor, li=g(di), di is the geographical distance between the data collection point and the data trading center, the geographical value factor is positively correlated with the scarcity of the data collection area; si is the data security level factor, si=h(ki), ki is the quantum-resistant encryption strength level used in the data transmission and storage process, the higher the security level, the larger si is. The total revenue distribution amount is given by the formula, where Vtotal is the total transaction amount. The edge node completes the calculation of all wi and Pi off-chain, generating a Merkle tree including proof of contribution for each data item. After being uploaded to the chain, each provider receives revenue based on the Merkle proof. 7. A hierarchical verification and data rights allocation method based on the system of any one of claims 1 to 6, comprising the following steps: S1. The root trust server connects with the certificate authority to complete the qualification certification of the signature production institution, generates a verification data set, and pushes the incremental update of the verification data set to each edge node through the data synchronization module; S2. The five-digit terminal uses the built-in hardware security chip to perform private key signing on the data hash, and sends the signed data to the nearest edge node; S3. After receiving the signed data, the edge node independently completes the signature verification using the locally cached verification data. After successful verification, it generates a confirmation certificate including the edge node's hardware signature and reports the confirmation certificate to the root trust server; S4. The root trust server solidifies the confirmation certificate to the blockchain for storage, and the data provider registers data assets and sets the sharing ratio through a smart contract; S5. The data buyer initiates a transaction request, and the smart contract verifies whether each data hash in the transaction has been registered and queries the data.The corresponding profit sharing ratio is used to automatically calculate the total amount payable and distribute the profits proportionally to the digital wallets of each data provider. 8. The hierarchical verification and data rights allocation method according to claim 7 is characterized in that: when the local cache of the edge node is missing, it automatically returns to the root trust server or certificate authority for real-time verification to achieve compatibility and degradation verification. 9. The hierarchical verification and data rights allocation method according to claim 7 is characterized in that, in step S5, the smart contract adopts a profit distribution mode that separates off-chain calculation and on-chain verification, including the following steps: S5-1, the edge node or root trust server calculates the profit distribution details of each data asset in this transaction off-chain and generates a Merkle tree including the distribution results; S5-2, the Merkle tree root hash and the total transaction amount are submitted to the smart contract for on-chain storage, instead of submitting the distribution details one by one; S5-3, each data provider receives the corresponding profit share off-chain with the Merkle proof, and the smart contract only verifies the validity of the Merkle proof. 10. The layered verification and data rights allocation method according to any one of claims 7 to 9, characterized in that, in step S5, the smart contract executes a dynamic revenue allocation algorithm based on contribution weight, comprising the following steps: For N data items in a single batch of transactions, the contribution weight factor wi=f(qi, ti, ri, li, si) of the i-th data item is defined as follows: where qi is the data quality score, with a value range of [0,1], automatically calculated by the edge node based on the data integrity verification result and signature validity; is the data freshness factor, ΔT is the time difference between the data generation time and the current time, and λ is a preset decay coefficient; ri=log(1+Ri) is the data history citation factor, Ri is the number of times the data has been successfully traded or cited in the blockchain smart contract layer; li is the data geographical value factor, li=g(di), di is the geographical distance between the data collection point and the data trading center, the geographical distance is calculated by the Beidou positioning information provided by the five-digit terminal during signing, and the geographical value factor is positively correlated with the scarcity of the data collection area; si is the data security level factor, si=h(ki), where ki is the quantum-resistant encryption strength level used during data transmission and storage; the higher the security level, the larger si is. The total weight of the i-th data item's revenue distribution amount is calculated as follows: where Vtotal is the total transaction amount. When there is a two-tier revenue sharing between the original data provider and the data aggregator, the original provider receives Pi·α, and the data aggregator receives Pi·(1-α), where α is the preset revenue sharing ratio for the original provider. The edge node completes the calculation of all wi, W, and Pi off-chain, generating (qi, ti, ri, li, si, wi, ...) for each data item.Pi) proves the Merkle tree, stores the Merkle tree root hash on the chain, and each participant receives the reward based on the Merkle proof. The chain only verifies the validity of the Merkle proof and does not perform line-by-line calculation. Claims 3 / 3 Page 4 CN 122372213 A A hierarchical verification and data rights allocation system and method Technical Field

[0001] This invention belongs to the field of network security technology, specifically involving digital identity authentication system and method. Background Technology

[0002] At present, as data becomes a new production factor, the data trading market is booming. However, the existing data rights confirmation, verification and trading system still has significant technical defects.

[0003] On the one hand, the traditional Public Key Infrastructure (PKI) / Certificate Authority (CA) system couples the qualification certification of the seal making institution with the real verification of each seal (including seal, signature) or each piece of data, which means that each verification needs to return to the CA institution or seal institution in real time to query the certificate status and seal validity. This coupling of verification paths brings two prominent problems: First, the latency of a single verification is as high as 50-200 milliseconds, which seriously affects user experience and system throughput in high-concurrency scenarios; second, the verification process relies entirely on real-time network connections, which is basically unusable in network outages, weak network conditions, or edge computing environments, severely limiting the application scenarios of electronic signatures and data verification.

[0004] Although the "Administrative Measures for Electronic Seals" (General Office of the State Council of the People's Republic of China, Guo Ban Fa

[2025] No. 33) clearly requires mutual trust and recognition of electronic seals, it has not changed the legal status of CA institutions as the root of trust. How to achieve an order-of-magnitude improvement in verification efficiency while maintaining the root trust of CA institutions is a technical problem that urgently needs to be solved in this field.

[0005] On the other hand, in the process of market-oriented allocation of data elements, there is a lack of effective technical means for the confirmation of data source ownership and the protection of rights in secondary transactions. Existing platforms mostly use centralized logs to record the identity of data uploaders and transaction flow. The logs are easily tampered with or forged, making it difficult to provide legally valid proof of data source, resulting in frequent disputes over data ownership. More importantly, when data is aggregated and resold or traded multiple times, the original data providers have no way of knowing where the data goes, nor can they receive any share of the revenue, which severely dampens their enthusiasm. At the same time, when millions of data points are packaged and traded, the contribution of each data point to the transaction value is difficult to quantify. Calculating revenue line by line on the blockchain would incur unacceptably high gas fees. Therefore, how to achieve quantitative assessment of the contribution of massive data transactions and low-cost automatic revenue distribution while ensuring the non-repudiation of data sources has become a core technological bottleneck in the construction of data element market infrastructure.

[0006] It should be noted that the above introduction to the technical background is only for the purpose of clearly and completely explaining the technical solution of the present invention and facilitating the understanding of those skilled in the art. It should not be assumed that the above technical solutions are known to those skilled in the art simply because these solutions have been described in the background section of the present invention. Summary of the Invention

[0007] The purpose of the present invention is to overcome the shortcomings of the prior art and provide a hierarchical verification and data rights allocation system and method based on a hardware root of trust.

[0008] The present invention discloses a hierarchical verification and data rights allocation system based on a hardware root of trust, comprising:

[0009] a unified certificate management root trust server, used to interface with a Certificate Authority (CA) to complete the qualification certification of electronic signature production institutions, manage the verification data set, and encrypt and push the incremental updates of the above verification data set to multiple edge nodes; multiple trusted content delivery network (CDN) edge nodes, each node... (The rest of the text appears to be a citation and does not translate directly.) The built-in centralized certificate management security module serves as the hardware trust root, maintaining a local verification data cache. It receives signature data from five data packets, independently completes signature verification, and generates ownership certificates including edge node hardware signatures. These ownership certificates are then reported to the root trust server. The five data packet terminal has a built-in hardware security chip for signing data hashes or electronic signature data with a private key. A blockchain smart contract layer is used to store ownership certificates, register data assets, verify the source of data hashes, and automatically execute revenue distribution. The ownership certificates generated by the aforementioned multiple trusted content distribution network edge nodes after successful signature verification are solidified into the blockchain by the centralized certificate management root trust server, serving as the sole basis for data ownership proof and subsequent revenue distribution.

[0010] Further, the aforementioned root trust server for unified certificate processing includes a qualification authentication module and a data synchronization module; the qualification authentication module is used to interface with the CA institution to perform low-frequency qualification authentication. The low-frequency qualification authentication is only performed when the seal-making institution first accesses or when the certificate validity period is updated. After successful authentication, the public key certificate, seal label, and status information of the seal-making institution are obtained; the data synchronization module is used to push the verification data set obtained by the qualification authentication module to each edge node through an encrypted synchronization protocol, and only push incremental change data when a new CA institution accesses or the certificate is updated; the edge nodes do not rely on real-time CA institution queries, and independently complete the high-frequency real verification of each seal or each piece of data using locally cached public key certificates, seal labels, and status information. The verification latency is 1-5 milliseconds and offline verification is supported.

[0011] Further, the aforementioned edge nodes are also used to automatically return to the source root trust server or CA when the local cache is missing.The institution performs real-time query verification to achieve a compatibility and degradation mode with the traditional PKI system; the aforementioned edge nodes conduct low-latency collaborative communication through a 6G communication network. When the local cache of a certain edge node is missing, it first initiates a real-time query request to the neighboring edge nodes through the 6G network to obtain the verification data cached by the neighboring nodes. Only when the neighboring nodes fail to find the data will it return to the source root trust server or CA institution, thereby utilizing the sub-millisecond transmission latency of the 6G network to further reduce the frequency of returning to the source and the total verification latency.

[0012] Furthermore, the aforementioned certificate-based root trust server and the aforementioned edge nodes are all equipped with quantum-resistant cryptography modules to support quantum-resistant signature algorithms based on lattice-based cryptography, multivariate cryptography, or hash-based signatures. During the system initialization phase, each component generates a quantum-resistant public-private key pair, wherein the quantum-resistant public key is used to verify the authenticity of the signature, and the quantum-resistant private key is used to perform quantum-resistant signatures on the certificate of ownership and the verification data. When the signature data is received, the edge node prioritizes the use of a quantum-resistant signature algorithm for verification. If the signature uses a traditional PKI algorithm, it is downgraded to the traditional verification mode, thereby achieving backward compatibility and quantum-resistant migration capability to resist the threat of future quantum computers cracking the existing PKI system.

[0013] Further, the above-mentioned five-data-packet terminal has a built-in Beidou positioning module and a Beidou short message communication module. When the above-mentioned five-data-packet terminal performs private key signing on the data hash, it simultaneously obtains the current geographical location information and the Beidou satellite time stamp, and incorporates the location information and the Beidou time stamp into the signature data packet.

[0014] Further, the above-mentioned edge node also includes a verification module, which is used to verify the validity of the geographical location information and the Beidou time stamp when verifying the signature: if the geographical location exceeds the preset authorized area range, or the deviation between the Beidou time stamp and the local time of the edge node exceeds a preset threshold, the signature is determined to be invalid and the generation of the confirmation certificate is refused.

[0015] Further, the above-mentioned five-data-package terminal also supports uploading signature data to the Beidou satellite via the Beidou short message communication module in areas without terrestrial network coverage. The Beidou satellite forwards the data to the ground station, and then the ground station routes it to the nearest edge node, thereby realizing the global coverage of data ownership confirmation and verification capabilities.

[0016] Further, the above-mentioned certificate-based root trust server executes a dynamic revenue distribution algorithm based on contribution weight. The algorithm executes the following steps. Specification 2 / 12 Page 6 CN 122372213 A

[0017] When a batch of datasets containing N data items is traded, for the i-th data item, its contribution weight factor is defined as

[0018] wi=f(qi, ti, ri, li, si) (Equation 1)

[0019] In the formula, qi is the data quality score, which is automatically calculated by the edge node based on data integrity verification and signature validity; ti is the data freshness factor, ΔT is the time difference between the data generation time and the current time, and λ is the decay coefficient; ri is the data history citation factor, ri=log(1+Ri), where Ri is the number of times the data has been traded or cited on the chain; li is the data geographical value factor, li=g(di), where di is the geographical distance between the data collection point and the data trading center. The geographical value factor is positively correlated with the scarcity of the data collection area (for example, data collected in remote areas has a higher geographical value factor); si is the data security level factor, si=h(ki), where ki is the quantum-resistant encryption strength level (e.g., 128-bit, 256-bit, 384-bit) used in the transmission and storage of the data. The higher the security level, the larger si is.

[0020] The total revenue distribution amount is (Formula 2)

[0022] In the formula, Vtotal is the total transaction amount.

[0023] The aforementioned edge nodes complete the calculation of all wi and Pi off-chain, generating a Merkle tree including proof of contribution for each data item. After being uploaded to the chain, each provider receives revenue based on the Merkle proof.

[0024] The present invention also discloses a layered verification and data rights allocation method, including the following steps: S1, the root trust server connects with the CA institution to complete the qualification certification of the signature production institution, generates a verification data set, and pushes the incremental update of the above verification data set to each edge node through the data synchronization module; S2, the five-digit terminal uses the built-in hardware security chip to sign the data hash with a private key, and sends the signed data to the nearest edge node; S3, after receiving the signature data, the edge node independently completes the signature verification using the locally cached verification data. After the verification is passed, a confirmation certificate including the edge node hardware signature is generated, and the confirmation certificate is reported to the root trust server; S4, the root trust server solidifies the confirmation certificate to the blockchain for storage, and the data provider registers data assets and sets the sharing ratio through a smart contract; S5, the data buyer initiates a transaction request, the smart contract verifies whether each data hash in the transaction has been registered, queries the corresponding sharing ratio, automatically calculates the total amount payable, and distributes the income to the digital wallets of each data provider according to the ratio.

[0025] Further, in step S3 above, the latency for the edge node to complete signature verification is 1-5 milliseconds; when the edge node's local cache is missing, it automatically returns to the root trust server or CA institution for real-time verification, with a latency of 50-200 milliseconds, achieving compatibility and degradation verification.

[0026] Further, in step S5 above, the smart contract adopts a revenue distribution model that separates off-chain computation and on-chain verification, including the following steps: S5-1, the edge node or root trust server calculates the revenue of each data asset in this transaction off-chain.The revenue distribution details are generated, and a Merkle tree including the distribution results is generated; S5-2, the Merkle tree root hash and the total transaction amount are submitted to the smart contract for on-chain storage, instead of submitting the distribution details one by one; S5-3, each data provider receives the corresponding revenue share off-chain based on the Merkle proof, and the smart contract only verifies the validity of the Merkle proof. Through the above steps, the on-chain gas fee of a single transaction is independent of the number of data items N, and is only related to O(1) on-chain operations.

[0027] Further, in the above step S5, the smart contract executes a dynamic revenue distribution algorithm based on contribution weight, including the following steps.

[0028] For N data points in a single batch of transactions, the contribution weight factor of the i-th data point is defined as

[0029] wi=f(qi, ti, ri, li, si) (Equation 1)

[0030] Where, qi is the data quality score, with a value range of [0, 1], which is automatically calculated by the above edge nodes based on the data integrity verification results and signature validity; is the data freshness factor, Δ T is the time difference between the data generation time and the current time, λ is the preset decay coefficient; ri=log(1+Ri) is the data history reference factor, Ri is the number of times the data has been successfully traded or referenced in the above-mentioned blockchain smart contract layer; li is the data geographical value factor, li=g(di), di is the geographical distance between the data collection point and the data trading center, the geographical distance is calculated by the Beidou positioning information provided by the above-mentioned five data package terminal when signing, the geographical value factor is positively correlated with the scarcity of the data collection area; si is the data security level factor, si=h(ki), ki is the anti-quantum encryption strength level used in the transmission and storage of data, the higher the security level, the larger si is.

[0031] Calculate the total weight (Equation 3)

[0033] The income distribution amount of the i-th data is

[0034] (Equation 4)

[0035] Where, Vtotal is the total amount of this transaction.

[0036] When there is a two-tier revenue sharing between the original data provider and the data aggregator, the original provider receives Pi·α, and the data aggregator receives Pi·(1-α), where α is a preset revenue sharing ratio for the original provider.

[0037] The aforementioned edge nodes complete the calculation of all wi, W, and Pi off-chain, generating a Merkle tree including the (qi, ti, ri, li, si, wi, Pi) proof for each piece of data. The root hash of the Merkle tree is stored on the chain. After being uploaded to the chain, each participant receives the reward based on the Merkle proof. The chain only verifies the validity of the Merkle proof without performing individual calculations, thereby achieving low-cost automatic allocation of massive data transactions.

[0038] The core advantage of this invention lies in the following: by decoupling the qualification authentication and real verification coupled in the traditional PKI system, a layered architecture of "central low-frequency authentication + edge high-frequency verification + 6G collaborative communication" is constructed. The root trust server of the certificate-based service only performs qualification authentication of the seal-making institution at a low frequency when interfacing with the CA institution, while the massive data signature verification tasks are independently completed by the nearest trusted CDN edge nodes using local caching. This reduces the single verification latency from 50-200 milliseconds in the traditional solution to 1-5 milliseconds and supports offline availability. Furthermore, when the local cache is missing, it prioritizes initiating sub-millisecond collaborative queries to adjacent edge nodes through the 6G network, further controlling the average verification latency to within 5-10 milliseconds. Meanwhile, the five-digit terminal has a built-in hardware security chip, a Beidou positioning module, and a Beidou short message communication module. It performs hardware signature on the data hash and anchors the geographical location and Beidou time stamp. After the edge node generates a certificate of ownership containing the hardware signature, it is solidified into the blockchain smart contract layer by the root trust server of the certificate collection and management system. Combined with the support of anti-quantum cryptography module for anti-quantum algorithms such as lattice cryptography to resist future quantum computer attacks, and a dynamic benefit distribution algorithm based on the five-dimensional contribution weight factor wi=f(qi, ti, ri, li, si), it systematically solves six major industry pain points, namely, difficulty in data ownership confirmation, low verification efficiency, offline unavailability, difficulty in global coverage, high quantum threat, and lack of protection for secondary transaction rights, while maintaining the legal compliance of CA root trust.

[0039] The beneficial effects of the present invention are as follows.

[0040] First, the verification efficiency is improved. The layered verification architecture built by the root trust server of the unified certificate system and the trusted CDN edge nodes reduces the real-time back-to-origin latency of 50-200 milliseconds in the traditional PKI system to 1-5 milliseconds and supports offline verification. The edge nodes achieve sub-millisecond collaborative query through 6G communication, so that the average verification latency is still controlled within 5-10 milliseconds in the case of cache missing.

[0041] Second, the legal effect is strengthened. The hardware signature of the five-digit package terminal is combined with the confirmation certificate of the edge node, which is solidified and stored in the blockchain smart contract layer. Combined with the geographical location anchoring provided by the Beidou positioning module and the Beidou satellite time stamp, each piece of data is provided with unforgeable spatiotemporal proof and judicial-level non-repudiable evidence.

[0042] Third, quantum security is strengthened. The root trust server and edge nodes of the unified certificate system have built-in quantum-resistant cryptographic modules, which support quantum-resistant signature algorithms such as lattice cryptography and are backward compatible with traditional PKI, and can resist the cracking threat of future quantum computers.

[0043] Fourth, rights protection is enhanced. The smart contract employs a dynamic revenue distribution algorithm based on a five-dimensional contribution weighting factor wi=f(qi, ti, ri, li, si). By introducing a geographical value factor li and a security level factor si, it ensures that data collected from remote areas is distributed more evenly.Data receives higher pricing, incentivizing high-strength quantum-resistant encryption and ensuring that the original provider continues to receive a fair share in multiple resales of the data.

[0044] Fifth, scalability is improved. The Merkle tree proof mode, which separates off-chain computation from on-chain verification, decouples the on-chain gas fees for millions of data package transactions from the number of data entries, maintaining them at a constant level.

[0045] Sixth, global coverage is achieved. The Beidou short message communication module of the five-data-package terminal supports data upload via Beidou satellite in areas without terrestrial network coverage, achieving global coverage of data ownership confirmation and verification.

[0046] Seventh, compatibility is improved. The 6G collaborative priority and downgraded back-to-source mechanism ensures that traditional institutions and terminals that have not been connected to the unified tag library or upgraded to quantum-resistant capabilities can still be verified normally by the system, realizing a smooth migration from traditional systems to layered verification architectures and from traditional cryptography to quantum-resistant cryptography. Brief Description of the Drawings

[0047] Figure 1 is a schematic diagram of a layered verification and data rights allocation system based on hardware root of trust in an embodiment of the present invention.

[0048] Figure 2 is a flowchart of a hierarchical verification and data rights allocation method based on a hardware trust root in one embodiment of the present invention.

[0049] Reference numerals in the above figures:

[0050] Hierarchical verification and data rights allocation system 10, certificate-based root trust server 100, qualification authentication module 110, data synchronization module 120, quantum-resistant cryptography module 130, trusted CDN edge node 200, 6G communication interface module 210, quantum-resistant cryptography module 220, verification module 230, five-digit terminal 300, Beidou positioning module 310, Beidou short message communication module 320, blockchain smart contract layer 400, S1 to S5 are steps. Detailed Embodiments

[0051] In order to better understand the present invention, the following embodiments are given in conjunction with the accompanying drawings. It should be understood that the embodiments of the present invention are only used to explain the present invention and not to limit it, and the scope of protection of the present invention is limited only by the claims of the present invention. The embodiments provided by the present invention are only some preferred embodiments and are not intended to limit the present invention in any way. Those skilled in the art can make changes, equivalent substitutions, or modifications to the content of this invention, resulting in different implementations. However, any changes and modifications, or equivalent substitutions, made to the method of this invention without departing from the inventive concept are within the scope of protection of this invention.

[0052] It should be noted that the following detailed descriptions are exemplary and intended to provide further explanation of the invention. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains.

[0053] It should be noted that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the exemplary embodiments according to the invention. As used herein, unless the context clearly indicates otherwise, the singular form is used.It is also intended to include plural forms. Furthermore, it should be understood that when the terms "comprising" and / or "including" are used in this specification, they indicate the presence of features, steps, operations, and / or combinations thereof.

[0054] First, please refer to FIG1. ​​FIG1 is a schematic diagram of a hardware-based root-of-trust layered verification and data rights allocation system 10 according to an embodiment of the present invention. As shown in FIG1, the hardware-based root-of-trust layered verification and data rights allocation system 10 of the present invention includes a unified certificate management root trust server 100, multiple trusted content delivery network (CDN) edge nodes 200, a five-digit terminal 300, and a blockchain smart contract layer 400.

[0055] The hierarchical verification and data rights allocation system 10 based on hardware trust root provided by the present invention uses the above-mentioned certificate management root trust server 100 as the central trust anchor point, which is responsible for connecting with the CA institution to complete the low-frequency qualification certification of the electronic signature production institution, and encrypting and pushing the verification data set (including public key certificate, signature label and status information) to each edge node; the above-mentioned multiple trusted CDN edge nodes 200 have built-in certificate management security modules as hardware trust roots, and independently receive and verify the signature data from the five-digit package terminal 300 using locally maintained verification data cache. The signature verification can be completed in milliseconds without real-time back to the source, and at the same time, the authorization certificate signed by the edge node hardware is generated and reported to the root trust server; the above-mentioned five-digit package terminal 300 has built-in hardware security chip, which is used to perform private key signing on data hash or electronic signature data to ensure the hardware-level non-repudiation of the data source.

[0056] In one embodiment of the present invention, the five-digit terminal 300, as the representative device of the terminal layer, undertakes the responsibility of secure signature at the data source end. The hardware security chip provides the five-digit terminal 300 with "hardware root of trust" level security, making the signature of each piece of data legally recognized and non-repudiable. The aforementioned blockchain smart contract layer 400 is responsible for storing the confirmation certificate solidified by the root trust server 100 on the chain, and providing an automated execution environment for data asset registration, source verification, and revenue distribution. The entire system, through a layered mechanism of independent verification by edge nodes and low-frequency authentication by the center, enables each piece of data to generate a legally valid confirmation certificate when uploaded or signed, and serves as the sole basis for subsequent revenue distribution by the blockchain smart contract. Thus, while maintaining the legitimacy of the CA root trust, it realizes the confirmation of data source, transaction witnessing, and automatic distribution of revenue.

[0057] In another embodiment of the present invention, the qualification authentication module 110 in the aforementioned unified certificate management root trust server 100 is responsible for low-frequency docking with the CA institution. The specific operation method is as follows.

[0058] When a new signature-making agency applies to access system 10 for the first time, the qualification authentication module 110 sends a request to the agency.The CA institution submits qualification review materials. After the CA institution completes the review, it returns the digital certificate and qualification certificate of the seal-making institution. The qualification certification module 110 stores the qualification information. This process is only performed once when the seal-making institution accesses the network, and a renewal request is sent to the CA institution again when the certificate expires. The operation frequency is only once every 1 to 3 years.

[0059] The data synchronization module 120 takes over the operation after the qualification certification is completed. It packages the obtained public key certificate, seal label and certificate status information into a verification data set, and actively pushes it to all trusted CDN edge nodes 200 through an encrypted synchronization protocol to ensure that each edge node 200 has complete and up-to-date verification data in its local cache. At the same time, when a new institution accesses the network or the certificate is updated, the data synchronization module 120 only pushes the incremental change data to each edge node 200 in encrypted form, instead of synchronizing the entire data, thereby greatly reducing network bandwidth consumption and central load.

[0060] The aforementioned qualification certification module is responsible for low-frequency institutional access and certificate management, and the aforementioned data synchronization module is responsible for efficiently distributing verification data to edge nodes. The aforementioned certificate management root trust server 100 implements the core logic of the layered architecture of "central low-frequency authentication + edge high-frequency verification".

[0061] It is worth noting that in system 10, the aforementioned certificate management root trust server 100 and each trusted CDN edge node 200 have built-in quantum-resistant cryptographic modules during the system initialization phase. The aforementioned root trust server 100 has built-in quantum-resistant cryptographic module 130, and the aforementioned edge node 200 has built-in quantum-resistant cryptographic module 220. The aforementioned quantum-resistant cryptographic modules support quantum-resistant signature algorithms such as those based on lattice cryptography manual page 6 / 12 10 CN 122372213 A (e.g., Cryptographic Suite for Algebraic Lattices (CRYSTALS)-Dilithium algorithm), multivariate cryptography, or hash-based signatures (e.g., SPHINCS+ algorithm).

[0062] During system initialization, the root trust server 100 generates a quantum-resistant root key pair, each edge node 200 generates its own quantum-resistant node key pair, and the five-digit terminal 300 generates a quantum-resistant user key pair. All quantum-resistant public keys are distributed and stored through the root trust server 100, while the quantum-resistant private keys are securely stored in the hardware security chip or the secure module built into each component, never leaving the device.

[0063] When the five-digit terminal 300 signs the data hash, it preferentially uses the quantum-resistant private key to execute the quantum-resistant signature algorithm to generate signature data, and sends the signature data along with the quantum-resistant algorithm identifier to the edge node 200.After receiving the signature data, node 200 first parses the algorithm identifier. If the identifier is a quantum-resistant algorithm, it calls the quantum-resistant cryptographic module to verify the signature using the corresponding quantum-resistant public key. If the identifier is a traditional Public Key Infrastructure (PKI) algorithm (such as RSA or Elliptic Curve Digital Signature Algorithm (ECDSA)), it automatically downgrades to the traditional verification mode and reads the corresponding traditional public key from the local cache to complete the verification. After successful verification, the ownership certificate generated by the edge node 200 also includes a quantum-resistant signature field, ensuring that the ownership certificate itself has quantum-resistant security.

[0064] Through the above dual-mode verification mechanism, system 10 can still maintain security after the practical application of quantum computers, while being backward compatible with the existing PKI system, achieving a smooth quantum-resistant migration without replacing existing terminal equipment.

[0065] In one embodiment of the present invention, the above-mentioned five-digit packet terminal 300 has a built-in Beidou positioning module 310 and a Beidou short message communication module 320. The Beidou positioning module 310 supports receiving civilian frequency band signals such as B1C and B2a of the Beidou satellite navigation system, and can obtain high-precision geographical location information (including longitude, latitude, and altitude, with positioning accuracy up to the centimeter level) and Beidou satellite time stamp (accuracy up to the nanosecond level) in real time.

[0066] When the five-digit packet terminal 300 performs private key signing on the data hash, it also collects the current geographical location information and Beidou timestamp, and packages the data hash, signature value, geographical location information, Beidou timestamp, and terminal ID into an enhanced signature data packet.

[0067] After receiving the data packet, the edge node 200 verifies the signature and calls the built-in verification module 230. The verification module 230 determines whether the geographical location information is within the authorized range based on the preset authorized area range (for example, a data collection task is only authorized to be carried out within a specific latitude and longitude rectangle area). If it exceeds the range, it refuses to verify and returns a "location unauthorized" error. The verification module 230 can also calculate the absolute value of the difference between the Beidou timestamp and the local time of the edge node 200. If the deviation exceeds the preset threshold (for example, ±5 seconds), it is determined that the signature has a risk of replay attack or time forgery and refuses to verify.

[0068] In areas without terrestrial network coverage (such as oceans, deserts, remote mountainous areas, ocean-going ships, etc.), the five-data packet terminal 300 encodes the enhanced signature data packet into Beidou short message format (the maximum capacity of a single message is about 1,000 Chinese characters or 14,000 bits) through the Beidou short message communication module and uploads it to the Beidou satellite through the Beidou satellite's Radio Determination Satellite Service (RDSS). Beidou satellites will send short messagesThe message is forwarded to the ground center station, which decodes it and routes it to the nearest trusted CDN edge node 200 via a dedicated network. After receiving the signature data forwarded by the BeiDou short message, the edge node 200 completes the verification according to the same geographical location and timestamp verification rules.

[0069] Through the above specific implementation, the system 10 realizes the global data ownership confirmation and verification capability in areas with terrestrial network coverage (4G / 5G / 6G) and areas without terrestrial network coverage (BeiDou short message). At the same time, it provides unforgeable spatiotemporal proof of data through geographical location anchoring and time stamping (page 7 / 12 of the BeiDou manual, CN 122372213 A).

[0070] In system 10, when a transaction containing N data assets (e.g., N = 100,000 ecological environment monitoring data collected in remote areas) occurs, the nearest trusted CDN edge node 200 first obtains five core parameters of each data from its local cache or through the root trust server 100: quality score qi, generation timestamp Ti, on-chain historical citation count Ri, geographical coordinates of the data collection point, and the quantum-resistant encryption strength level ki used in the data transmission and storage process.

[0071] Wherein, qi ranges from [0, 1], and is automatically calculated and solidified in the confirmation certificate by the edge node 200 based on data integrity verification and the signature validity of the five-data-package terminal 300 when the data is first uploaded. Freshness factor, ΔT is the time difference between the current time and the data generation time Ti, and λ is a preset decay coefficient (e.g., λ = 0.01). Historical citation factor ri = log(1 + Ri), where Ri is the cumulative number of times the data has been successfully traded or cited in the blockchain smart contract layer 400. The geographic value factor li = g(di), where di is the geographic distance between the data collection point and the data transaction center. The edge node 200 calculates this distance based on the BeiDou positioning information provided by the five-data-package terminal 300 during signing. For example, for data collected in remote areas such as deserts, oceans, and polar regions, the geographic value factor li can be as high as 2.0, while for data collected in ordinary areas such as cities, li is 1.0. The security level factor si = h(ki), where ki is the quantum-resistant encryption strength level (e.g., 128-bit, 256-bit, 384-bit). If 256-bit or higher quantum-resistant encryption is used when uploading data, then si = 1.5; if 128-bit encryption is used, then si = 1.2; and if only traditional encryption is used, then si = 1.0.

[0072] Edge node 200 then calculates the contribution weight factor for each data point

[0073] wi = qi·ti·ri·li·si (Equation 5)

[0074] and sums them to obtain the total weight (Equation 3)

[0076] Assuming the total transaction amount is Vtotal = 1 million yuan, then the allocation amount for the i-th data point is

[0077] (Equation 4)

[0078] For example, a piece of data collected on the Qinghai-Tibet Plateau, using 256-bit quantum-resistant encryption, with a quality score of 0.9, collected 30 days ago, and cited 5 times in history, has a wi = 0.9 × e - 0.01 × 30 × log(1+5) × 2.0 × 1.5 = 0.9 × 0.74 × 1.79 × 2.0 × 1.5 ≈ 3.58. A piece of data collected in a city, using traditional encryption, and with other similar conditions, has a wi = 0.9 × 0.74 × 1.79 × 1.0 × 1.0 ≈ 1.19. The former's contribution weight is approximately three times that of the latter, thus it can obtain a higher share of the revenue.

[0079] When there is a two-tier revenue sharing between the original data provider and the data aggregator, the original provider receives Pi·α, and the data aggregator receives Pi·(1-α), where α is the preset revenue sharing ratio of the original provider (e.g., α = 70%). All calculations of wi, W, and Pi are performed off-chain in the environment of edge node 200. Edge node 200 then constructs a Merkle tree with each data item (qi, ti, ri, li, si, wi, Pi) as leaf nodes. After calculating the root hash, it submits only the root hash and the total amount Vtotal to the blockchain smart contract layer 400. Each data provider (including the original provider and the aggregator) requests its own Merkle proof path from edge node 200. With this proof, it calls the claim function of smart contract layer 400. After the smart contract verifies that the proof matches the root hash, it transfers Pi·α (original provider) or Pi·(1-α) (aggregator) to the corresponding address.

[0080] Through the above specific implementation, system 10, based on the integration of 6G edge collaboration, quantum cryptography resistance, and BeiDou positioning, further realizes differentiated pricing of data collection location value and data security strength through geographical value factors and security level factors, making the distribution of revenue more fair, refined, and in line with market rules.

[0081] Please refer to Figure 2. Figure 2 is a flowchart of a hierarchical verification and data rights allocation method based on a hardware trust root according to an embodiment of the present invention. As shown in Figure 2, the above-mentioned hierarchical verification and data rights allocation method based on a hardware trust root is described in the following steps: S1. The root trust server connects with the CA institution to complete the qualification certification of the signature production institution, generates a verification data set, and pushes the incremental update of the above verification data set to each edge node through the data synchronization module. S2. The five-digit terminal uses the built-in hardware security chip to perform private key signing on the data hash and sends the signed data to the nearest edge node. S3. After receiving the signature data, the edge node independently completes the signature verification using the locally cached verification data. After the verification is passed, it generates a confirmation certificate containing the edge node's hardware signature and reports the confirmation certificate to the root trust server. S4. The root trust server...The server solidifies the confirmation certificate to the blockchain for storage, and the data provider registers data assets and sets the revenue sharing ratio through a smart contract. S5, the data buyer initiates a transaction request, the smart contract verifies whether each data hash in the transaction has been registered, queries the corresponding revenue sharing ratio, automatically calculates the total amount payable, and distributes the revenue to the digital wallets of each data provider proportionally.

[0082] It is worth noting that in one embodiment of the present invention, during the execution of step S3 in system 10, the edge node 200 completes the specific latency indicators of signature verification and the implementation details of compatibility degradation verification. When the five-digital terminal 300 sends the signature data to the nearest trusted CDN edge node 200, the edge node 200 first queries the local cache of its built-in certificate-based security module. If the corresponding public key certificate, signature label and status information already exist in the local cache, the edge node 200 directly completes the signature verification operation inside the node. The end-to-end latency from receiving data to outputting the verification result is strictly controlled within the range of 1 to 5 milliseconds, which is the high-frequency local verification mode. If edge node 200 does not find the corresponding verification data in its local cache (for example, the signing authority has not yet connected to the unified tag library, or the cache miss is caused by network synchronization delay), edge node 200 automatically triggers a compatibility degradation verification process: it sends a real-time origin query request to the root trust server 100 of the unified certificate management system. After receiving the request, the root trust server 100 queries its own global database. If the data is still not found, it further queries the original CA authority using the Online Certificate Status Protocol (OCSP) or the Certificate Revocation List (CRL) to obtain the real-time certificate validity status, and then returns the information to edge node 200 level by level. The end-to-end latency of this origin verification mode is 50–200 milliseconds, which is higher than that of the local verification mode, but it ensures the integrity and correctness of the signature verification. After completing the origin verification, edge node 200 can choose to store the verification data queried this time into a local cache and set a short expiration time (e.g., 1 hour or 24 hours) so that subsequent signature requests from the institution can directly hit the local cache, thereby automatically switching from the degraded mode back to the local verification mode of 1-5 milliseconds.

[0083] Through the above specific implementation, system 10 achieves seamless compatibility and smooth transition for non-connected institutions while ensuring verification efficiency.

[0084] It is worth noting that in one embodiment of the present invention, during the execution of step S5 by system 10, the smart contract adopts a revenue distribution mode that separates off-chain computation and on-chain verification. Its specific implementation includes three sub-steps. In sub-step S5-1, when a transaction containing N data assets occurs (e.g., N=500,000 AI training images), the nearest trusted CDN edgeEdge node 200 or root trust server 100 performs the complete revenue distribution calculation in the off-chain environment. It reads the provider identity, preset sharing ratio, and contribution parameters in the confirmation certificate corresponding to each piece of data, calculates the revenue amount Pi that each piece of data should receive, and forms a distribution detail list containing N records. It then uses these N detail records as leaf nodes to construct a Merkle tree. In sub-step S5-2, edge node 200 or root trust server 100 only submits the constructed Merkle tree root hash and the total amount Vtotal of this transaction to the blockchain smart contract layer 400 for on-chain storage, without putting the N distribution details on the chain one by one. This reduces the number of on-chain operations for a single transaction from O(N) to O(1). In sub-step S5-3, when each data provider needs to receive revenue, it requests its own Merkle proof path (containing approximately log2N hash values ​​required from the leaf node corresponding to the provider to the root node) from the edge node 200 or the root trust server 100. The Merkle proof is submitted to the claim function of the blockchain smart contract layer 400. The smart contract verifies whether the proof matches the stored RootHash. After verification, the corresponding revenue amount is immediately transferred from the escrow account to the digital wallet of the provider.

[0085] Since only the hash verification of the Merkle proof is performed on the chain (the gas fee is fixed and independent of N), and the revenue calculation is not performed for each transaction, the on-chain gas fee of the entire transaction remains at a constant level (approximately US$0.01 to US$0.05) regardless of whether N is 50 or 500,000 transactions. Thus, low-cost, scalable, and automatic revenue distribution for massive data transactions is achieved in system 10.

[0086] It is worth noting that during the execution of step S5 in system 10, the smart contract adopts a dynamic revenue distribution algorithm based on contribution weight, the specific implementation of which is as follows.

[0087] When a transaction containing N data assets (e.g., N = 100,000 ecological environment monitoring data collected in remote areas) occurs, the nearest trusted CDN edge node 200 first obtains five core parameters of each data from the local cache or through the root trust server 100 of the certificate management system—quality score qi, generation timestamp Ti, on-chain historical reference count Ri, geographical coordinates of the data collection point (derived from the Beidou positioning information provided by the five-digit terminal 300 during signing), and the quantum-resistant encryption strength level ki used in the transmission and storage of the data. Among them, the value of qi is in the range of [0,1], which is automatically calculated by the edge node 200 based on the data integrity verification and the signature validity of the five-digit terminal 300 when the data is first uploaded and is solidified in the confirmation certificate.

[0088] The edge node 200 then calculates the freshness factor (ΔT is the time difference between the current time and the data generation time Ti, λ is the preset decay coefficient, for example λ=0.01), historical reference factor ri=log(1+Ri) (Ri is the cumulative number of times the data has been successfully traded or referenced in the blockchain smart contract layer 400), geographical value factor li=g(di) (di is the geographical distance between the data collection point and the data trading center. For data collected in remote areas such as deserts, oceans, and polar regions, li can be as high as 2.0, while for data collected in ordinary areas such as cities, li is 1.0), and security level factor si=h(ki) (si=1.5 if 256-bit or higher quantum-resistant encryption is used when uploading data, si=1.2 if 128-bit encryption is used, and si=1.0 if only traditional encryption is used).

[0089] Edge node 200 then calculates the contribution weight factor for each data item

[0090] wi = qi·ti·ri·li·si (Equation 5)

[0091] and sums them to obtain the total weight (Equation 3)

[0093] Let the total transaction amount be Vtotal, then the allocation amount for the i-th data item

[0094] (Equation 4)

[0095] When there is a two-level division between the original data provider and the data aggregator, the original provider receives Pi·α, and the data aggregator receives Pi·(1-α), where α is the preset original provider's division ratio (e.g., α=70%). After edge node 200 completes the calculation of all wi, W, and Pi off-chain, it generates a Merkle tree containing the proof information of (qi, ti, ri, li, si, wi, Pi) for each data item, and stores the root hash (RootHash) on-chain.

[0096] Each data provider (including the original provider and the aggregator) calls the blockchain smart contract layer 400 to receive revenue based on their respective Merkle proofs. The smart contract only verifies the validity of the Merkle proofs without performing line-by-line calculations, thereby realizing a dynamic revenue distribution in the system 10 that balances fairness (quantifying contribution through five dimensions: quality, freshness, citation count, geographical location, and security strength) and low cost (decoupling of Gas fees and N) in the context of massive data transactions.

[0097] Example 1: Personal health data upload ownership confirmation and first transaction revenue sharing

[0098] User Zhang San uploads his personal health records through a health data trading platform. The platform packages the data and sells it to an insurance company, and Zhang San receives a share of the revenue. Manual 10 / 12 pages 14 CN 122372213 A

[0099] Step S1 (low-frequency qualification certification and data synchronization): The root trust server 100 of the certificate exchange completes the connection with the CA institution in advance, certifies the qualification of the signature production institution of the health data trading platform, obtains the public key certificate and signature label, and generatesThe verification data set is generated and pushed to each trusted CDN edge node 200 through an encrypted synchronization protocol. This step is only performed once when the platform is first accessed.

[0100] Step S2 (Hardware Signing of Five-Digit Packet): Zhang San uses the five-digit packet terminal 300 to sign the health data hash, current timestamp, and data description with his private key using its built-in hardware security chip, generating a signed data packet, and sending it to the nearest trusted CDN edge node 200 through the network.

[0101] Step S3 (Local Verification and Credential Generation at Edge Nodes): After receiving the signed data, the trusted CDN edge node 200 reads the public key certificate and signature label corresponding to the platform from its local cache and independently completes the signature verification (takes about 1 to 5 milliseconds). After the verification is successful, the edge node 200 generates a credential, which contains the data hash, Zhang San's public key hash, timestamp, and the edge node 200's own hardware signature, and reports the credential to the root trust server 100 of the certificate management system.

[0102] Step S4 (Certificate Solidification and Data Asset Registration): The root trust server 100 of the unified certificate system solidifies the received confirmation certificate to the blockchain smart contract layer 400 for storage, ensuring the immutability and legal validity of the data source. Subsequently, Zhang San registers his data asset through the smart contract, setting the profit sharing ratio to 30%.

[0103] Step S5 (Transaction Trigger and Automatic Profit Distribution): Insurance company E, as the data purchaser, initiates a purchase request to the blockchain smart contract layer 400, including Zhang San's data hash and payment amount. The smart contract verifies that the data hash has been registered and the confirmation certificate is valid, automatically calculates the profit that Zhang San should receive (payment amount × 30%), and transfers the corresponding amount from the insurance company account to Zhang San's digital wallet.

[0104] Example 2, Enterprise Electronic Seal Contract Signing and Transaction

[0105] In a certain supply chain finance platform, enterprise A uses an electronic seal to sign an electronic contract with enterprise B. The contract terms include data use authorization and profit sharing agreement.

[0106] Step S1 (Low-frequency qualification certification and data synchronization): The root trust server 100 of the certificate management system connects with the CA institution in advance to authenticate the qualifications of the electronic seal making institutions of the supply chain finance platform and various enterprises, and synchronizes the seal label, public key certificate and status information to the local cache of each trusted CDN edge node 200.

[0107] Step S2 (Five-digital package hardware signature): Enterprise A uses the five-digital package terminal 300 to sign the hash value of the electronic contract document with its private key, generates a signature data packet, and sends it to the nearest trusted CDN edge node 200. Similarly, Enterprise B also completes the signature operation.

[0108] Step S3 (Edge node local verification and confirmation certificate generation): After receiving the signatures from both parties, the trusted CDN edge node 200 reads the public key certificates of the corresponding seal making institutions of Enterprise A and Enterprise B from its local cache, and independently completes two signatures.Verification (total time approximately 2-5 milliseconds). After successful verification, edge node 200 generates a joint confirmation certificate containing contract hash, public key hash of both parties, timestamp, and edge node hardware signature, and reports it to the root trust server 100 of the integrated certificate management system.

[0109] Step S4 (Certificate solidification and data asset registration): The root trust server 100 of the integrated certificate management system solidifies the joint confirmation certificate to the blockchain smart contract layer 400. Enterprise A and Enterprise B jointly register the contract data asset through the smart contract and set the revenue sharing ratio (e.g., Enterprise A accounts for 60% and Enterprise B accounts for 40%), and authorize the contract data to be resold in the supply chain finance scenario.

[0110] Step S5 (Transaction triggering and automatic revenue distribution): Factoring company C, as the transferee of the contract debt, initiates a transaction request to the blockchain smart contract layer 400 and pays the contract transfer consideration of RMB 1 million. The smart contract verifies that the contract data asset has been registered and the confirmation certificate is valid, and automatically allocates 600,000 yuan to enterprise A and 400,000 yuan to enterprise B according to the preset ratio, completing the automatic distribution of income as described on pages 11 / 12 of the specification, CN 122372213 A.

[0111] The above-described embodiments of the present invention can be implemented in various hardware, software codes, or combinations thereof. For example, embodiments of the present invention can also be program code that executes the above-described method in a digital signal processor (DSP). The present invention can also relate to various functions executed by computer processors, digital signal processors, microprocessors, or field programmable gate arrays (FPGAs). The processor can be configured to perform specific tasks according to the present invention, which is accomplished by executing machine-readable software code or firmware code that defines the specific methods disclosed in the present invention. The software code or firmware code can be developed into different programming languages ​​and different formats or forms. The software code can also be compiled for different target platforms. However, the different code styles, types, and languages ​​of the software code that performs tasks according to the present invention and other types of configuration code do not depart from the spirit and scope of the present invention.

[0112] Thus, those skilled in the art will recognize that although embodiments of the present invention have been shown and described in detail herein, many other variations or modifications conforming to the principles of the present invention can be directly determined or derived from the disclosure of the present invention without departing from the spirit and scope of the invention. Therefore, the scope of the present invention should be understood and recognized as covering all such other variations or modifications. Specification 12 / 12 pages 16 CN 122372213 A Figure 1 Specification Drawings 1 / 2 pages 17 CN 122372213 A Figure 2 Specification Drawings 2 / 2 pages 18 CN 122372213 A Abstract Thepresent invention discloses a hierarchical verification and data rights allocation system based on a hardware trust root, comprising: a centralized certificate and universal service root trust server, used for interfacing with certificate authorities to complete the qualification certification of electronic seal making institutions and managing the verification data collection; a five-number package terminal, used for private key signing of data hashes or electronic seal data; multiple trusted content distribution network edge nodes, used for receiving the signature data of the five-number package, independently completing signature verification and generating entitlement certificates including the hardware signature of the edge node, and reporting the entitlement certificates to the centralized certificate and universal service root trust server; a blockchain smart contract layer, used for storing the entitlement certificates, registering data assets, verifying the source of datahashes, and automatically executing revenue distribution; the entitlement certificates generated by the multiple trusted content distribution network edge nodes after passing the signature verification are solidified to the blockchain by the centralized certificate and universal service root trust server, serving as the sole basis for data ownership proof and subsequent revenue distribution.

Claims

1. A hierarchical authentication and data rights allocation system based on hardware root of trust, comprising: The unified certificate management root trust server is used to interface with certificate authorities to complete the qualification certification of electronic signature production institutions and manage the verification data set; Five-digit terminal, used to sign data hashes or electronic signature data with private keys; Multiple trusted content delivery network edge nodes are used to receive the signature data of five packets, independently complete signature verification and generate a certificate of authorization including the edge node hardware signature, and report the certificate of authorization to the root trust server of the certificate management system. A blockchain smart contract layer is used to store the confirmation certificate, registered data assets, verify the source of data hashes, and automatically execute profit distribution; The ownership certificates generated by the multiple trusted content distribution network edge nodes after successful signature verification are solidified into the blockchain by the centralized certificate management root trust server, serving as the sole basis for data ownership proof and subsequent revenue distribution.

2. The hierarchical verification and data rights allocation system according to claim 1, characterized in that: The root trust server for centralized certificate processing includes a qualification authentication module and a data synchronization module. The qualification authentication module is used to interface with the certificate authority to perform low-frequency qualification authentication. The low-frequency qualification authentication is only performed when the seal production agency connects for the first time or when the certificate validity period is updated. After the authentication is successful, the public key certificate, seal label and status information of the seal production agency are obtained. The data synchronization module is used to push the verification data set obtained by the qualification certification module to each edge node through an encrypted synchronization protocol, and only push incremental change data when a new certificate authority is connected or the certificate is updated. The edge nodes do not rely on real-time certificate authority queries, but independently complete high-frequency verification of each signature or each piece of data by utilizing locally cached public key certificates, signature tags, and status information.

3. The hierarchical verification and data rights allocation system according to claim 1, characterized in that: The edge nodes are also used to automatically query and verify the source root trust server or certificate authority in real time when the local cache is missing, so as to achieve a compatibility and degradation mode with the traditional PKI system. The edge nodes communicate with each other via a 6G communication network with low latency. When the local cache of an edge node is missing, it first initiates a real-time query request to the neighboring edge nodes through the 6G network to obtain the verification data cached by the neighboring nodes. Only when the neighboring nodes fail to find the data will it return to the root trust server or certificate authority.

4. The hierarchical verification and data rights allocation system according to claim 1, characterized in that: Both the root trust server for centralized certificate processing and the edge nodes have built-in quantum-resistant cryptographic modules to support quantum-resistant signature algorithms based on lattice cryptography, multivariate cryptography, or hash-based signatures. During the system initialization phase, each component generates a quantum-resistant public-private key pair. The quantum-resistant public key is used to verify the authenticity of the signature, and the quantum-resistant private key is used to perform quantum-resistant signatures on the ownership certificate and verification data. When the edge node receives the signature data, it prioritizes using the quantum-resistant signature algorithm for verification. If the signature uses the traditional PKI algorithm, it is downgraded to the traditional verification mode.

5. The hierarchical verification and data rights allocation system according to claim 1, characterized in that: The five-digit terminal has a built-in Beidou positioning module and a Beidou short message communication module. When the five-digit terminal performs private key signing on the data hash, it simultaneously obtains the current geographical location information and the BeiDou satellite time stamp, and incorporates the location information and BeiDou time stamp into the signature data packet. The edge node also includes a verification module, which verifies the validity of the geographical location information and the BeiDou timestamp when verifying the signature. If the geographical location exceeds the preset authorized area range, or the deviation between the BeiDou timestamp and the local time of the edge node exceeds a preset threshold, the signature is determined to be invalid and the generation of the confirmation certificate is refused. The five-digit terminal also supports uploading signature data to the Beidou satellite via the Beidou short message communication module in areas without terrestrial network coverage. The Beidou satellite then forwards the data to the ground station, which then routes it to the nearest edge node.

6. The hierarchical verification and data rights allocation system according to any one of claims 1 to 5, characterized in that, The system executes a dynamic revenue allocation algorithm based on contribution weights, and the algorithm performs the following steps: When a batch of a dataset containing N data points is traded, for the i-th data point, its contribution weight factor is defined. w i =f(q i , t i , r i , l i , s i ) In the formula, q i Data quality scores are automatically calculated by edge nodes based on data integrity verification and signature validity. t i For data freshness factor, ΔT is the time difference between the data generation time and the current time, and λ is the attenuation coefficient; r i r is the historical citation factor for data. i =log(1+R i ), R i This refers to the historical number of times the data has been transacted or referenced on the blockchain. l i As a data geographic value factor, l i =g(d i ), d i The geographical value factor is positively correlated with the scarcity of the data collection area, representing the geographical distance between the data collection point and the data trading center. s i For data security level factors, s i =h(k i ), k i The strength level of quantum-resistant encryption used during data transmission and storage; the higher the security level, the stronger the quantum-resistant encryption. i The larger; The total amount of revenue distribution is In the formula, V total This is the total transaction amount; The edge nodes complete all w off-chain. i and P i The calculation generates a Merkle tree that includes proof of contribution for each piece of data. After being uploaded to the blockchain, each provider can claim their rewards based on the Merkle proof.

7. A hierarchical verification and data rights allocation method based on the system of any one of claims 1 to 6, comprising the following steps: S1. The root trust server connects with the certificate authority to complete the qualification certification of the signature production organization, generates a verification data set, and pushes the incremental update of the verification data set to each edge node through the data synchronization module. S2, the five-digit packet terminal uses the built-in hardware security chip to perform private key signing on the data hash and sends the signed data to the nearest edge node; S3. After receiving the signature data, the edge node independently completes the signature verification using the locally cached verification data. After the verification is successful, it generates a confirmation certificate including the edge node's hardware signature and reports the confirmation certificate to the root trust server. S4. The root trust server solidifies the ownership certificate to the blockchain for evidence storage, and the data provider registers data assets and sets the revenue sharing ratio through smart contracts. S5. The data buyer initiates a transaction request. The smart contract verifies whether each data hash in the transaction has been registered, queries the corresponding revenue sharing ratio, automatically calculates the total amount payable, and distributes the revenue proportionally to the digital wallets of each data provider.

8. The hierarchical verification and data rights allocation method according to claim 7, characterized in that: When the local cache of an edge node is missing, it automatically returns to the root trust server or certificate authority for real-time verification, achieving compatibility degradation verification.

9. The hierarchical verification and data rights allocation method according to claim 7, characterized in that, In step S5, the smart contract adopts a revenue distribution model that separates off-chain computation from on-chain verification, including the following steps: S5-1, Edge nodes or root trust servers calculate the revenue distribution details of each data asset in this transaction off-chain and generate a Merkle tree including the distribution results; S5-2. Submit the Merkle root hash and total transaction amount to the smart contract for on-chain storage, instead of submitting the allocation details one by one; S5-3. Each data provider receives its corresponding share of revenue off-chain based on the Merkle proof. The smart contract only verifies the validity of the Merkle proof.

10. The hierarchical verification and data rights allocation method according to any one of claims 7 to 9, characterized in that, In step S5, the smart contract executes a dynamic revenue distribution algorithm based on contribution weights, including the following steps: For N data points in a single batch of transactions, define the contribution weight factor for the i-th data point. w i =f(q i , t i , r i , l i , s i ) In the formula, q i The data quality score, with a value range of [0,1], is automatically calculated by the edge node based on the data integrity verification result and signature validity. ΔT is the data freshness factor, ΔT is the time difference between the data generation time and the current time, and λ is the preset decay coefficient. r i =log(1+R i R is the historical citation factor for data. i This refers to the historical number of times the data has been successfully transacted or referenced in the blockchain smart contract layer. l i As a data geographic value factor, l i =g(d i ), d i The geographical distance between the data collection point and the data trading center is calculated from the BeiDou positioning information provided by the five-digit terminal during signing. The geographical value factor is positively correlated with the scarcity of the data collection area. s i For data security level factors, s i =h(k i ), k i The strength level of quantum-resistant encryption used during data transmission and storage; the higher the security level, the stronger the quantum-resistant encryption. i The larger; Calculate the total weight The revenue distribution amount for the i-th data is In the formula, V total This is the total transaction amount; When there is a two-tiered division between the original data provider and the data aggregator, the original provider receives P. i ·α, the data aggregator obtains P i ·(1-α), where α is the preset percentage to be shared by the original provider; The edge nodes complete all w off-chain. i W, P i The calculation generates (q) for each data item. i , t i , r i , l i ,s i , w i , P i The Merkle tree is proven, and the root hash of the Merkle tree is stored on the blockchain. Each participant can receive rewards based on the Merkle proof. The blockchain only verifies the validity of the Merkle proof and does not perform line-by-line calculation.

Images