A blockchain-based electronic archive management method and system
By splitting electronic archives according to their security level and generating feature codes and matching keys, the security and decentralization issues of private key management in blockchain electronic archive management are solved, improving management efficiency and security.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- JIANGXI PROVINCIAL EXPRESSWAY INVESTMENT GRP CO LTD
- Filing Date
- 2025-12-27
- Publication Date
- 2026-05-29
AI Technical Summary
In existing blockchain-based electronic record management, private key management suffers from the inability to balance security and decentralization, resulting in the inability to recover file access permissions after key loss, thus affecting management efficiency.
Electronic archives are split into core data and redundant data according to their security level, generating core encrypted blocks and redundant encrypted blocks. Archive feature codes are generated by associating hash values with tags, and target storage nodes are generated by combining them with target smart contracts. These nodes are then managed using a central server and blockchain platform, generating appropriate encryption keys.
It achieves a balance between key security and decentralization, improving the efficiency and security of electronic record management, and ensuring the immutability of core data and convenient access to redundant data.
Smart Images
Figure CN122113131A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of archival management technology, and in particular to a blockchain-based electronic archival management method and system. Background Technology
[0002] In the digital economy era, the need for secure management of electronic records is becoming increasingly urgent. Blockchain technology, with its decentralized and tamper-proof characteristics, effectively solves the problems of data tampering and poor traceability in traditional centralized electronic record management. By storing the hash value of the records on the blockchain, it provides reliable protection for the authenticity and traceability of electronic records, and has broad application prospects in the field of electronic record management.
[0003] In a blockchain-based electronic archive system, the private key is the sole credential for accessing archive data, and its security directly determines the availability of the archive. However, existing private key management has significant shortcomings: under the asymmetric encryption mechanism of blockchain, there is no function to report a lost private key or reset it. Once lost or forgotten, the corresponding electronic archive will permanently lose access. Even if the data hash is stored on the chain, access to the archive cannot be restored, resulting in the loss of important electronic archives and becoming a prominent obstacle to the application of the technology.
[0004] Furthermore, traditional private key backup solutions, such as multi-copy storage and third-party escrow, contradict the decentralized nature of blockchain: multiple copies easily lead to private key leaks, while third-party escrow involves rebuilding centralized nodes, violating the core advantages of blockchain and increasing security risks. Currently, there is a lack of effective solutions that balance private key security and decentralization, and the problem of private key loss has become a key bottleneck for the large-scale implementation of blockchain electronic record management technology. Summary of the Invention
[0005] Therefore, the purpose of this invention is to provide a blockchain-based electronic record management method and system to solve the problem that existing technologies cannot effectively balance key security and data centralization in the process of managing electronic records through blockchain, which leads to a reduction in the efficiency of electronic record management.
[0006] The first aspect of the present invention proposes: A blockchain-based electronic record management method specifically includes the following steps: The electronic files to be managed are divided into core data and redundant data according to the file security level, and core encryption blocks are generated based on the core data and redundant encryption blocks are generated based on the redundant data. The hash values of the core encrypted block and the redundant encrypted block are associated, marked, and concatenated to generate a corresponding file feature code. The core encrypted block is uploaded to a preset blockchain platform to associate the storage address of the core encrypted block with the file feature code. At the same time, it is written into the initial smart contract of the preset blockchain platform to generate a corresponding target smart contract. Based on the target smart contract, generate several corresponding target storage nodes and import the target storage nodes into the central server. The target attribute parameters of the central server are collected, and an encryption key adapted to each target storage node is generated according to the target attribute parameters to complete the management of the electronic archives.
[0007] The beneficial effects of this invention are as follows: This solution effectively solves the problem of balancing key security and data centralization in existing technologies, significantly improving the efficiency and security of electronic record management. Data is split and encrypted according to security level, achieving precise protection of core data and optimization of redundant data resources. After the core encrypted block is uploaded to the blockchain, it is associated with the record's feature code, relying on the immutability of the blockchain to ensure the security of core data while providing convenience for retrieval. The initial smart contract combines with the record information to generate the target smart contract, and the derived storage nodes are imported into the central server, realizing the integration of the advantages of blockchain's distributed security and centralized management by the central server. Adaptive keys are generated for nodes based on server attribute parameters, avoiding the defects of generic keys, strengthening key security and management convenience, and ultimately improving efficiency while ensuring security.
[0008] Furthermore, the step of associating and concatenating the hash values of the core encryption block and the redundant encryption block to generate the corresponding file feature code includes: Add a data type label to the hash value of the core encrypted block, and add an associated index identifier to the hash value of the redundant encrypted block. Create a corresponding attribute differentiation tag based on the data type label and the associated index identifier. Based on the attribute differentiation marker, and combined with the creation timestamp of the electronic archive, a dynamic association factor is generated that is compatible with the core encryption block and the redundant encryption block. The core encryption block and the redundant encryption block are then concatenated and encrypted according to the dynamic association factor to generate the corresponding initial association hash string. The first 16 bits of the initial associated hash string are extracted as a verification benchmark for verification processing and corresponding file feature codes are generated.
[0009] Furthermore, the step of extracting the first 16 bits of the initial associated hash string as a verification benchmark for verification processing and generating the corresponding file feature code includes: The first 16-bit hash fragment is merged with the data type label and a cyclic shift is performed to generate the first bound fragment. The last 16-bit hash fragment is mapped with the associated index identifier to generate the last bound fragment. The first and last binding segments are combined to generate an enhanced verification benchmark. A temporary verification key is generated based on the dynamic association factor. The temporary verification key is then XORed with the enhanced verification benchmark to remove abnormal segments and then concatenate them to form a verification-passed sequence. The core feature fragment is generated by fusing the verification sequence and the enhanced verification benchmark. The core feature fragment is then concatenated with the hash value of the dynamic association factor to be encoded into the file feature code.
[0010] Furthermore, the step of generating several corresponding target storage nodes based on the target smart contract includes: Based on the target smart contract, the access subject permissions, data update cycle and cross-chain call requirements of the core encrypted block are parsed out to construct the corresponding node requirement vector and call up the distributed node index library. Based on the node demand vector, a candidate node set is selected from the distributed node index. The candidate node set is then traced through the target smart contract to extract historical working parameters. This is combined with homomorphic encryption algorithm for encryption detection to extract a corresponding set of trusted nodes. The set of trusted nodes is sharded using the target smart contract to generate several target storage nodes.
[0011] Furthermore, the step of sharding the trusted node set through the target smart contract to generate a plurality of target storage nodes includes: The hardware encryption capabilities, network latency thresholds, and storage security level labels of each node in the trusted node set are extracted through the target smart contract to construct the corresponding node-security level adaptation matrix, and the data fields of the core encryption block are split into several sub-blocks. The sub-blocks are grouped using the node-security level adaptation matrix to form several primary fragments, and the access permission lists of each primary fragment are extracted synchronously. The access permission list is bound to the security level of the electronic file to generate a corresponding target storage node list, and several target storage nodes are generated according to the target storage node list.
[0012] Furthermore, the step of generating an encryption key adapted to each of the target storage nodes based on the target attribute parameters to correspondingly complete the management of the electronic archives includes: The target attribute parameters are decoupled into multi-dimensional features to extract the node computing power threshold, bandwidth fluctuation coefficient and access authentication level. The corresponding dynamic weighting matrix is constructed by combining the confidentiality weight of the electronic file. The dynamic weighting matrix is then iteratively optimized by the particle swarm optimization algorithm to generate the corresponding key basic factor set. The key base factor set is XORed with the hash fragment of the core encryption block, and a timestamp seed from the target smart contract is introduced to generate the corresponding initial encryption key. The initial encryption key is distributed for verification to generate the corresponding encryption key for the target storage node.
[0013] Furthermore, the step of performing distributed verification on the initial encryption key to generate the corresponding encryption key for the target storage node includes: A target adaptation matrix is constructed based on the security threshold of the electronic archive and the access authentication level of the target storage node, and the corresponding verification cluster is selected from the initial encryption key based on the target adaptation matrix. A verification proposal corresponding to the verification cluster is generated using the PBFT algorithm, and the target encryption key is selected from the verification cluster according to the verification proposal. The target encryption key is set to the encryption key of the target storage node.
[0014] The second aspect of the present invention proposes: A blockchain-based electronic records management system, wherein the system includes: The splitting module is used to split the electronic files to be managed into core data and redundant data according to the file security level, so as to generate a core encryption block based on the core data and a redundant encryption block based on the redundant data. The association module is used to associate and concatenate the hash values of the core encrypted block and the redundant encrypted block to generate a corresponding file feature code. The core encrypted block is uploaded to a preset blockchain platform to associate the storage address of the core encrypted block with the file feature code. At the same time, it is written into the initial smart contract of the preset blockchain platform to generate a corresponding target smart contract. The generation module is used to generate several corresponding target storage nodes according to the target smart contract, and import the several target storage nodes into the central server. The acquisition module is used to acquire target attribute parameters of the central server and generate encryption keys adapted to each target storage node based on the target attribute parameters, so as to complete the management of the electronic archives.
[0015] Furthermore, the association module is specifically used for: Add a data type label to the hash value of the core encrypted block, and add an associated index identifier to the hash value of the redundant encrypted block. Create a corresponding attribute differentiation tag based on the data type label and the associated index identifier. Based on the attribute differentiation marker, and combined with the creation timestamp of the electronic archive, a dynamic association factor is generated that is compatible with the core encryption block and the redundant encryption block. The core encryption block and the redundant encryption block are then concatenated and encrypted according to the dynamic association factor to generate the corresponding initial association hash string. The first 16 bits of the initial associated hash string are extracted as a verification benchmark for verification processing and corresponding file feature codes are generated.
[0016] Furthermore, the association module is specifically used for: The first 16-bit hash fragment is merged with the data type label and a cyclic shift is performed to generate the first bound fragment. The last 16-bit hash fragment is mapped with the associated index identifier to generate the last bound fragment. The first and last binding segments are combined to generate an enhanced verification benchmark. A temporary verification key is generated based on the dynamic association factor. The temporary verification key is then XORed with the enhanced verification benchmark to remove abnormal segments and then concatenate them to form a verification-passed sequence. The core feature fragment is generated by fusing the verification sequence and the enhanced verification benchmark. The core feature fragment is then concatenated with the hash value of the dynamic association factor to be encoded into the file feature code.
[0017] Furthermore, the generation module is specifically used for: Based on the target smart contract, the access subject permissions, data update cycle and cross-chain call requirements of the core encrypted block are parsed out to construct the corresponding node requirement vector and call up the distributed node index library. Based on the node demand vector, a candidate node set is selected from the distributed node index. The candidate node set is then traced through the target smart contract to extract historical working parameters. This is combined with homomorphic encryption algorithm for encryption detection to extract a corresponding set of trusted nodes. The set of trusted nodes is sharded using the target smart contract to generate several target storage nodes.
[0018] Furthermore, the generation module is specifically used for: The hardware encryption capabilities, network latency thresholds, and storage security level labels of each node in the trusted node set are extracted through the target smart contract to construct the corresponding node-security level adaptation matrix, and the data fields of the core encryption block are split into several sub-blocks. The sub-blocks are grouped using the node-security level adaptation matrix to form several primary fragments, and the access permission lists of each primary fragment are extracted synchronously. The access permission list is bound to the security level of the electronic file to generate a corresponding target storage node list, and several target storage nodes are generated according to the target storage node list.
[0019] Furthermore, the acquisition module is specifically used for: The target attribute parameters are decoupled into multi-dimensional features to extract the node computing power threshold, bandwidth fluctuation coefficient and access authentication level. The corresponding dynamic weighting matrix is constructed by combining the confidentiality weight of the electronic file. The dynamic weighting matrix is then iteratively optimized by the particle swarm optimization algorithm to generate the corresponding key basic factor set. The key base factor set is XORed with the hash fragment of the core encryption block, and a timestamp seed from the target smart contract is introduced to generate the corresponding initial encryption key. The initial encryption key is distributed for verification to generate the corresponding encryption key for the target storage node.
[0020] Furthermore, the acquisition module is specifically used for: A target adaptation matrix is constructed based on the security threshold of the electronic archive and the access authentication level of the target storage node, and the corresponding verification cluster is selected from the initial encryption key based on the target adaptation matrix. A verification proposal corresponding to the verification cluster is generated using the PBFT algorithm, and the target encryption key is selected from the verification cluster according to the verification proposal. The target encryption key is set to the encryption key of the target storage node.
[0021] The third aspect of the present invention proposes: A computer includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the blockchain-based electronic record management method as described above.
[0022] The fourth aspect of the present invention proposes: A readable storage medium having a computer program stored thereon, wherein the program, when executed by a processor, implements the blockchain-based electronic record management method as described above.
[0023] Additional aspects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description
[0024] Figure 1 A flowchart illustrating the blockchain-based electronic records management method provided in the first embodiment of the present invention; Figure 2 The structural block diagram of the blockchain-based electronic records management system provided in the third embodiment of the present invention.
[0025] The following detailed description, in conjunction with the accompanying drawings, will further illustrate the present invention. Detailed Implementation
[0026] To facilitate understanding of the present invention, a more complete description will be given below with reference to the accompanying drawings. Several embodiments of the invention are illustrated in the drawings. However, the invention can be implemented in many different forms and is not limited to the embodiments described herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete.
[0027] It should be noted that when a component is said to be "fixed to" another component, it can be directly on the other component or there may be an intervening component. When a component is said to be "connected to" another component, it can be directly connected to the other component or there may be an intervening component. The terms "vertical," "horizontal," "left," "right," and similar expressions used in this document are for illustrative purposes only.
[0028] Unless otherwise defined, 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. The terminology used herein in the description of the invention is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. The term "and / or" as used herein includes any and all combinations of one or more of the associated listed items.
[0029] Please see Figure 1 The image shows a blockchain-based electronic record management method provided in the first embodiment of the present invention. This blockchain-based electronic record management method can reasonably handle the storage relationship between the blockchain and the data center, thereby improving the management efficiency of electronic records.
[0030] Specifically, this embodiment provides: A blockchain-based electronic record management method specifically includes the following steps: Step S10: The electronic files to be managed are split into core data and redundant data according to the file security level, and a core encryption block is generated based on the core data and a redundant encryption block is generated based on the redundant data. It should be noted that the first step focuses on differentiated processing based on classification level: electronic archives are divided into core data (such as the main text of classified archives), and redundant data (such as the format information and supplementary instructions of the archives) according to their classification level (such as "Top Secret", "Confidential", "Secret" and "Public"). The core purpose is to "protect the core and efficiently handle the redundancy". Specifically, the core data is encrypted to generate core encryption blocks (using high-strength encryption algorithms such as AES-256), and the redundant data is generated into redundant encryption blocks (using lightweight encryption algorithms to reduce overhead). This ensures the security of sensitive information while also taking into account management efficiency.
[0031] Step S20: Associate and concatenate the hash values of the core encrypted block and the redundant encrypted block to generate the corresponding file feature code. Upload the core encrypted block to the preset blockchain platform to associate the storage address of the core encrypted block with the file feature code. Simultaneously, write the initial smart contract of the preset blockchain platform to generate the corresponding target smart contract. It's important to note that the second step, achieving blockchain-based evidence storage and traceability, involves associating and concatenating the hash values of the two types of encrypted blocks to generate an archive feature code. Specifically, the hash value is unique and irreversible, and the feature code acts as a "digital fingerprint" for the archive, accurately verifying its integrity. The core encrypted block is then uploaded to a pre-defined blockchain platform (leveraging the blockchain's immutability to ensure core data security). Simultaneously, the storage address of the core encrypted block is associated with the archive feature code, and this association is written into the initial smart contract to generate the target smart contract. Specifically, the smart contract codifies the "storage address-feature code" association, enabling automatic execution of access permissions and update rules, thus avoiding the risk of manual tampering.
[0032] Step S30: Generate several corresponding target storage nodes according to the target smart contract, and import the several target storage nodes into the central server. It should be noted that, based on the target smart contract, a suitable target storage node is generated (the smart contract parses the file's security level and access requirements, and selects nodes that meet the security level), and imported into the central server to achieve a balance between centralized management and distributed storage.
[0033] Step S40: Collect the target attribute parameters of the central server, and generate an encryption key adapted to each target storage node according to the target attribute parameters, so as to complete the management of the electronic archives.
[0034] It should be noted that the target attribute parameters of the data acquisition center server (such as computing power, bandwidth, and security authentication level) generate a unique encryption key for each target storage node. Specifically, this ensures the isolation of access permissions for different nodes, ultimately achieving secure management of electronic archives and realizing the goals of "on-chain storage of core data, distributed storage of redundant data, and intelligent control of access permissions".
[0035] Second Embodiment Furthermore, the step of associating and concatenating the hash values of the core encryption block and the redundant encryption block to generate the corresponding file feature code includes: Add a data type label to the hash value of the core encrypted block, and add an associated index identifier to the hash value of the redundant encrypted block. Create a corresponding attribute differentiation tag based on the data type label and the associated index identifier. Based on the attribute differentiation marker, and combined with the creation timestamp of the electronic archive, a dynamic association factor is generated that is compatible with the core encryption block and the redundant encryption block. The core encryption block and the redundant encryption block are then concatenated and encrypted according to the dynamic association factor to generate the corresponding initial association hash string. The first 16 bits of the initial associated hash string are extracted as a verification benchmark for verification processing and corresponding file feature codes are generated.
[0036] It should be noted that the first step is to achieve accurate differentiation of hash values: the hash values of core encrypted blocks are labeled with data types (such as "core-top secret"), and the hash values of redundant encrypted blocks are labeled with associated index identifiers (such as "redundant-core ID:202501"). The relationship and security level of the two types of data are clearly defined by attribute differentiation markers. Specifically, this avoids data confusion during subsequent splicing and ensures that the feature code can be traced back to the original data type.
[0037] The second step is to construct dynamic association relationships: Based on attribute-differentiated markers, dynamic association factors are generated by combining the creation timestamps of electronic archives. Specifically, the introduction of timestamps gives the association factors timeliness; even if the same archive is processed at different times, different factors will be generated, improving the uniqueness of the feature code. The hash values of the two types of encrypted blocks are then concatenated and encrypted using the dynamic association factors (e.g., using the HMAC algorithm) to generate an initial association hash string. Specifically, concatenated encryption ensures that the hash values of core and redundant data form an inseparable whole, preventing the feature code from becoming invalid after a single hash value is tampered with.
[0038] The third step involves verification and signature generation: The first 16 bits of the initial associated hash string are extracted as verification benchmarks. Specifically, the 16-bit length ensures verification accuracy while avoiding data redundancy. The integrity of the hash string is verified using these benchmarks (e.g., the first bit is used to cyclically verify the last bit). After removing abnormal data, a signature is generated. This signature integrates multi-dimensional information such as data type, association relationship, timestamp, and integrity verification, providing a reliable basis for subsequent traceability and verification of blockchain-based evidence.
[0039] Furthermore, the step of extracting the first 16 bits of the initial associated hash string as a verification benchmark for verification processing and generating the corresponding file feature code includes: The first 16-bit hash fragment is merged with the data type label and a cyclic shift is performed to generate the first bound fragment. The last 16-bit hash fragment is mapped with the associated index identifier to generate the last bound fragment. The first and last binding segments are combined to generate an enhanced verification benchmark. A temporary verification key is generated based on the dynamic association factor. The temporary verification key is then XORed with the enhanced verification benchmark to remove abnormal segments and then concatenate them to form a verification-passed sequence. The core feature fragment is generated by fusing the verification sequence and the enhanced verification benchmark. The core feature fragment is then concatenated with the hash value of the dynamic association factor to be encoded into the file feature code.
[0040] It should be noted that the first step is to bind the verification benchmark to the attribute tag: after merging the first 16-bit hash fragment with the data type tag, a circular shift is performed (e.g., left shift by 8 bits) to generate the first bound fragment. Specifically, the circular shift enhances the data obfuscation and prevents the association between the tag and the hash fragment from being cracked. The last 16-bit hash fragment is mapped to the associated index identifier (e.g., by establishing a corresponding relationship through a hash mapping table) to generate the last bound fragment. Specifically, the binding operation deeply associates the verification benchmark with the original data attribute, improving the anomaly detection capability.
[0041] The second step involves verification and sequence generation: The first and last bound segments are combined to form a strengthened verification benchmark. A temporary verification key is generated using a dynamic association factor. Specifically, the dynamic nature of the temporary key avoids the risk of brute-force attacks on fixed keys. The temporary verification key is then XORed with the strengthened verification benchmark (the reversibility of XOR operations facilitates rapid verification), eliminating abnormal segments in the hash string (such as segments that fail verification). The resulting sequence ensures the integrity and security of the hash string, laying a reliable foundation for signature generation.
[0042] The third step is to generate the final feature code: the fusion verification generates a core feature fragment (condensing key verification information) by combining the sequence with the enhanced verification benchmark; the hash value of the core feature fragment and the dynamic association factor are concatenated (further improving uniqueness), and the archive feature code is generated by encoding methods such as Base64. Specifically, the encoded feature code has a unified format, which facilitates storage on the blockchain platform and subsequent rapid comparison and verification, ensuring that the feature code of each electronic archive is globally unique and tamper-proof.
[0043] Furthermore, the step of generating several corresponding target storage nodes based on the target smart contract includes: Based on the target smart contract, the access subject permissions, data update cycle and cross-chain call requirements of the core encrypted block are parsed out to construct the corresponding node requirement vector and call up the distributed node index library. Based on the node demand vector, a candidate node set is selected from the distributed node index. The candidate node set is then traced through the target smart contract to extract historical working parameters. This is combined with homomorphic encryption algorithm for encryption detection to extract a corresponding set of trusted nodes. The set of trusted nodes is sharded using the target smart contract to generate several target storage nodes.
[0044] It's important to note that the first step, analyzing node requirements, involves extracting key requirements from the core encrypted blocks based on the target smart contract. Specifically, this includes access permissions (e.g., administrator-only access), data update cycles (e.g., monthly updates), and cross-chain call requirements (e.g., whether interaction with the government blockchain is needed). This process constructs a node requirement vector, which is then vectorized to make the requirements more precise, providing a quantitative basis for node selection. Simultaneously, a distributed node index (storing basic information about all nodes in the blockchain network) is retrieved to prepare for the selection process.
[0045] The second step is to screen trusted nodes: Based on the node requirement vector, a set of candidate nodes is screened in the index (such as nodes that meet the requirements of "computing power ≥ 100G FLOPS, latency ≤ 50ms"); the historical working parameters of the candidate nodes are traced through the target smart contract (such as the number of failures and data tampering records in the past 6 months), and encryption detection is performed in combination with homomorphic encryption algorithm (to detect security without decrypting node data). Specifically, homomorphic encryption ensures that node data is not leaked during the detection process, and finally a set of trusted nodes without security risks is extracted.
[0046] The third step is to generate target nodes: the set of trusted nodes is sharded using the target smart contract. Specifically, nodes are grouped according to "storage security level - access permission". For example, the core encrypted block of "top secret" files is assigned to nodes with bank-level security certification, while redundant data of "public" files is assigned to ordinary nodes. Sharding not only matches the security level of the security level with the security level of the nodes, but also improves data availability by utilizing the distributed storage characteristics of blockchain (the failure of a single node does not affect overall access), ultimately generating several target storage nodes.
[0047] Furthermore, the step of sharding the trusted node set through the target smart contract to generate a plurality of target storage nodes includes: The hardware encryption capabilities, network latency thresholds, and storage security level labels of each node in the trusted node set are extracted through the target smart contract to construct the corresponding node-security level adaptation matrix, and the data fields of the core encryption block are split into several sub-blocks. The sub-blocks are grouped using the node-security level adaptation matrix to form several primary fragments, and the access permission lists of each primary fragment are extracted synchronously. The access permission list is bound to the security level of the electronic file to generate a corresponding target storage node list, and several target storage nodes are generated according to the target storage node list.
[0048] It should be noted that the first step, constructing the adaptation matrix and data splitting, involves extracting the hardware encryption capabilities (such as whether it supports the national cryptographic algorithm SM4), network latency threshold (such as peak latency ≤30ms), and storage security level labels (such as "Top Secret" and "Confidential") of trusted nodes through the target smart contract, and constructing a node-security level adaptation matrix (the matrix elements represent the node's adaptation score for a certain security level of data); splitting the data fields of the core encrypted block into several sub-blocks (such as splitting by "body-attachment-metadata"). Specifically, the sub-block splitting facilitates the allocation to nodes of different security levels according to their importance.
[0049] The second step is to form primary shards: Based on the scores in the adaptation matrix, sub-blocks are assigned to the nodes with the highest adaptation scores, forming several primary shards (e.g., "text sub-blocks" are assigned to nodes with an adaptation score of 95, and "metadata sub-blocks" are assigned to nodes with an adaptation score of 80); the access permission lists of each primary shard are extracted simultaneously (e.g., "text sub-blocks are only accessible to administrators, and metadata sub-blocks can be accessed by department members"). Specifically, the permission lists provide a basis for subsequent access control.
[0050] The third step is to generate target storage nodes: bind the access permission list to the security level of the electronic archives (e.g., "Top Secret" archives can only be accessed by 3 core personnel) to ensure that the access permissions of the fragments do not exceed the overall security level of the archives; generate a target storage node list (clearly defining the sub-blocks stored by each node, access permissions, and security levels), activate the storage function of the corresponding nodes according to the list, and finally generate the target storage nodes. Specifically, this process realizes "hierarchical data storage and precise access control" to prevent core sub-blocks from being leaked due to insufficient security levels of storage nodes.
[0051] Furthermore, the step of generating an encryption key adapted to each of the target storage nodes based on the target attribute parameters to correspondingly complete the management of the electronic archives includes: The target attribute parameters are decoupled into multi-dimensional features to extract the node computing power threshold, bandwidth fluctuation coefficient and access authentication level. The corresponding dynamic weighting matrix is constructed by combining the confidentiality weight of the electronic file. The dynamic weighting matrix is then iteratively optimized by the particle swarm optimization algorithm to generate the corresponding key basic factor set. The key base factor set is XORed with the hash fragment of the core encryption block, and a timestamp seed from the target smart contract is introduced to generate the corresponding initial encryption key. The initial encryption key is distributed for verification to generate the corresponding encryption key for the target storage node.
[0052] It should be noted that the first step, core parameter extraction and optimization, involves decoupling the target attribute parameters of the central server (such as computing power, bandwidth, and authentication level) through multi-dimensional features. This extracts the node computing power threshold (reflecting decryption processing capability), bandwidth fluctuation coefficient (reflecting data transmission stability), and access authentication level (reflecting node security qualifications). A dynamic weighted matrix is constructed by combining the confidentiality weights of electronic files (e.g., "Top Secret" weight 1.0, "Public" weight 0.3). Specifically, the matrix quantifies the influence of each parameter on key generation. The matrix is then iteratively optimized using a particle swarm optimization algorithm (finding the optimal solution for parameter combinations) to generate a basic key factor set (e.g., "computing power factor 0.8, authentication factor 1.0").
[0053] The second step is to generate the initial encryption key: XOR the basic factor set of the key with the hash fragment of the core encryption block (the randomness of the XOR operation increases the key complexity), and at the same time, introduce the timestamp seed from the target smart contract (the dynamic nature of the timestamp ensures that the same factor set will generate different keys). Specifically, the two are combined to generate the initial encryption key, which is both adapted to the node attributes and dynamic, avoiding the security risks of fixed keys.
[0054] The third step is to complete key verification and determination: the initial encryption key is verified in the distributed nodes (such as verifying the decryption validity and security of the key through multiple trusted nodes), and abnormal keys that fail verification (such as keys that cannot decrypt the corresponding sub-blocks) are eliminated. Finally, a unique encryption key is generated for each target storage node. Specifically, the unique performance of the key ensures the isolation of access permissions between nodes. Only the node holding the corresponding key can read and write the stored data, thus completing the closed loop of secure management of electronic archives.
[0055] Furthermore, the step of performing distributed verification on the initial encryption key to generate the corresponding encryption key for the target storage node includes: A target adaptation matrix is constructed based on the security threshold of the electronic archive and the access authentication level of the target storage node, and the corresponding verification cluster is selected from the initial encryption key based on the target adaptation matrix. A verification proposal corresponding to the verification cluster is generated using the PBFT algorithm, and the target encryption key is selected from the verification cluster according to the verification proposal. The target encryption key is set to the encryption key of the target storage node.
[0056] It should be noted that the first step is to screen and verify the cluster: based on the security threshold of the electronic file (such as the "top secret" threshold of 0.95) and the access authentication level of the target storage node, a target adaptation matrix is constructed (the matrix elements represent the node's qualification for security level verification); nodes that meet the qualification standards are selected according to the matrix to form a verification cluster. Specifically, it is ensured that the nodes participating in the verification have sufficient security level to avoid interference from malicious nodes in the verification process.
[0057] The second step involves generating a verification proposal and selecting the key: A verification proposal is generated for the verification cluster using the PBFT algorithm (Practical Byzantine Fault Tolerance, a commonly used consensus algorithm in blockchain). Specifically, the proposal includes an initial encryption key, the hash value of the corresponding sub-block, and decryption verification rules. Nodes in the cluster independently verify the initial encryption key based on the proposal (e.g., decrypting a sub-block with the key and comparing the hash value of the decrypted data with the original hash value). The target encryption key that passes verification is selected through consensus voting. Specifically, the PBFT algorithm can tolerate some node failures or malicious behavior, ensuring the consistency and reliability of the verification results.
[0058] The third step is to determine the node-specific key: The target encryption key, agreed upon through consensus, is bound to the identifier of the corresponding target storage node (such as the node ID), and written into the target smart contract for notarization. Specifically, the automatic execution feature of the smart contract ensures that the binding relationship between the key and the node is tamper-proof. Finally, the bound target encryption key is set as the node's exclusive encryption key, achieving "one node, one key" security control. This ensures the end-to-end security of electronic records during storage, access, and transmission, completing the entire blockchain-based electronic record management process.
[0059] Please see Figure 2 The third embodiment of the present invention provides: A blockchain-based electronic records management system, wherein the system includes: The splitting module is used to split the electronic files to be managed into core data and redundant data according to the file security level, so as to generate a core encryption block based on the core data and a redundant encryption block based on the redundant data. The association module is used to associate and concatenate the hash values of the core encrypted block and the redundant encrypted block to generate a corresponding file feature code. The core encrypted block is uploaded to a preset blockchain platform to associate the storage address of the core encrypted block with the file feature code. At the same time, it is written into the initial smart contract of the preset blockchain platform to generate a corresponding target smart contract. The generation module is used to generate several corresponding target storage nodes according to the target smart contract, and import the several target storage nodes into the central server. The acquisition module is used to acquire target attribute parameters of the central server and generate encryption keys adapted to each target storage node based on the target attribute parameters, so as to complete the management of the electronic archives.
[0060] Furthermore, the association module is specifically used for: Add a data type label to the hash value of the core encrypted block, and add an associated index identifier to the hash value of the redundant encrypted block. Create a corresponding attribute differentiation tag based on the data type label and the associated index identifier. Based on the attribute differentiation marker, and combined with the creation timestamp of the electronic archive, a dynamic association factor is generated that is compatible with the core encryption block and the redundant encryption block. The core encryption block and the redundant encryption block are then concatenated and encrypted according to the dynamic association factor to generate the corresponding initial association hash string. The first 16 bits of the initial associated hash string are extracted as a verification benchmark for verification processing and corresponding file feature codes are generated.
[0061] Furthermore, the association module is specifically used for: The first 16-bit hash fragment is merged with the data type label and a cyclic shift is performed to generate the first bound fragment. The last 16-bit hash fragment is mapped with the associated index identifier to generate the last bound fragment. The first and last binding segments are combined to generate an enhanced verification benchmark. A temporary verification key is generated based on the dynamic association factor. The temporary verification key is then XORed with the enhanced verification benchmark to remove abnormal segments and then concatenate them to form a verification-passed sequence. The core feature fragment is generated by fusing the verification sequence and the enhanced verification benchmark. The core feature fragment is then concatenated with the hash value of the dynamic association factor to be encoded into the file feature code.
[0062] Furthermore, the generation module is specifically used for: Based on the target smart contract, the access subject permissions, data update cycle and cross-chain call requirements of the core encrypted block are parsed out to construct the corresponding node requirement vector and call up the distributed node index library. Based on the node demand vector, a candidate node set is selected from the distributed node index. The candidate node set is then traced through the target smart contract to extract historical working parameters. This is combined with homomorphic encryption algorithm for encryption detection to extract a corresponding set of trusted nodes. The set of trusted nodes is sharded using the target smart contract to generate several target storage nodes.
[0063] Furthermore, the generation module is specifically used for: The hardware encryption capabilities, network latency thresholds, and storage security level labels of each node in the trusted node set are extracted through the target smart contract to construct the corresponding node-security level adaptation matrix, and the data fields of the core encryption block are split into several sub-blocks. The sub-blocks are grouped using the node-security level adaptation matrix to form several primary fragments, and the access permission lists of each primary fragment are extracted synchronously. The access permission list is bound to the security level of the electronic file to generate a corresponding target storage node list, and several target storage nodes are generated according to the target storage node list.
[0064] Furthermore, the acquisition module is specifically used for: The target attribute parameters are decoupled into multi-dimensional features to extract the node computing power threshold, bandwidth fluctuation coefficient and access authentication level. The corresponding dynamic weighting matrix is constructed by combining the confidentiality weight of the electronic file. The dynamic weighting matrix is then iteratively optimized by the particle swarm optimization algorithm to generate the corresponding key basic factor set. The key base factor set is XORed with the hash fragment of the core encryption block, and a timestamp seed from the target smart contract is introduced to generate the corresponding initial encryption key. The initial encryption key is distributed for verification to generate the corresponding encryption key for the target storage node.
[0065] Furthermore, the acquisition module is specifically used for: A target adaptation matrix is constructed based on the security threshold of the electronic archive and the access authentication level of the target storage node, and the corresponding verification cluster is selected from the initial encryption key based on the target adaptation matrix. A verification proposal corresponding to the verification cluster is generated using the PBFT algorithm, and the target encryption key is selected from the verification cluster according to the verification proposal. The target encryption key is set to the encryption key of the target storage node.
[0066] The fourth embodiment of the present invention provides a computer, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the blockchain-based electronic record management method as described above.
[0067] The fifth embodiment of the present invention provides a readable storage medium on which a computer program is stored, wherein the program, when executed by a processor, implements the blockchain-based electronic record management method as described above.
[0068] In summary, the blockchain-based electronic record management method and system provided by the above embodiments of the present invention can reasonably handle the storage relationship between the blockchain and the data center, thereby improving the management efficiency of electronic records.
[0069] It should be noted that the above modules can be functional modules or program modules, and can be implemented through software or hardware. For modules implemented through hardware, the above modules can reside in the same processor; or the above modules can be located in different processors in any combination.
[0070] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-including system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device.
[0071] More specific examples of computer-readable media (a non-exhaustive list) include: electrical connections (electronic devices) having one or more wires, portable computer disk drives (magnetic devices), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Furthermore, computer-readable media can even be paper or other suitable media on which the program can be printed, because the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in computer memory.
[0072] It should be understood that various parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.
[0073] In the description of this specification, references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.
[0074] The embodiments described above are merely illustrative of several implementations of the present invention, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of the invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these modifications and improvements all fall within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the appended claims.
Claims
1. A blockchain-based electronic records management method, characterized in that, The method includes: The electronic files to be managed are divided into core data and redundant data according to the file security level, and core encryption blocks are generated based on the core data and redundant encryption blocks are generated based on the redundant data. The hash values of the core encrypted block and the redundant encrypted block are associated, marked, and concatenated to generate a corresponding file feature code. The core encrypted block is uploaded to a preset blockchain platform to associate the storage address of the core encrypted block with the file feature code. At the same time, it is written into the initial smart contract of the preset blockchain platform to generate a corresponding target smart contract. Based on the target smart contract, generate several corresponding target storage nodes and import the target storage nodes into the central server. The target attribute parameters of the central server are collected, and an encryption key adapted to each target storage node is generated according to the target attribute parameters to complete the management of the electronic archives.
2. The blockchain-based electronic records management method according to claim 1, characterized in that, The step of associating and concatenating the hash values of the core encryption block and the redundant encryption block to generate the corresponding file feature code includes: Add a data type label to the hash value of the core encrypted block, and add an associated index identifier to the hash value of the redundant encrypted block. Create a corresponding attribute differentiation tag based on the data type label and the associated index identifier. Based on the attribute differentiation marker, and combined with the creation timestamp of the electronic archive, a dynamic association factor is generated that is compatible with the core encryption block and the redundant encryption block. The core encryption block and the redundant encryption block are then concatenated and encrypted according to the dynamic association factor to generate the corresponding initial association hash string. The first 16 bits of the initial associated hash string are extracted as a verification benchmark for verification processing and corresponding file feature codes are generated.
3. The blockchain-based electronic records management method according to claim 2, characterized in that, The step of extracting the first 16 bits of the initial associated hash string as a verification benchmark for verification processing and generating the corresponding file feature code includes: The first 16-bit hash fragment is merged with the data type label and a cyclic shift is performed to generate the first bound fragment. The last 16-bit hash fragment is mapped with the associated index identifier to generate the last bound fragment. The first and last binding segments are combined to generate an enhanced verification benchmark. A temporary verification key is generated based on the dynamic association factor. The temporary verification key is then XORed with the enhanced verification benchmark to remove abnormal segments and then concatenate them to form a verification-passed sequence. The core feature fragment is generated by fusing the verification sequence and the enhanced verification benchmark. The core feature fragment is then concatenated with the hash value of the dynamic association factor to be encoded into the file feature code.
4. The blockchain-based electronic records management method according to claim 1, characterized in that, The step of generating several corresponding target storage nodes based on the target smart contract includes: Based on the target smart contract, the access subject permissions, data update cycle and cross-chain call requirements of the core encrypted block are parsed out to construct the corresponding node requirement vector and call up the distributed node index library. Based on the node demand vector, a candidate node set is selected from the distributed node index. The candidate node set is then traced through the target smart contract to extract historical working parameters. This is combined with homomorphic encryption algorithm for encryption detection to extract a corresponding set of trusted nodes. The set of trusted nodes is sharded using the target smart contract to generate several target storage nodes.
5. The blockchain-based electronic records management method according to claim 4, characterized in that, The step of sharding the trusted node set through the target smart contract to generate a plurality of target storage nodes includes: The hardware encryption capabilities, network latency thresholds, and storage security level labels of each node in the trusted node set are extracted through the target smart contract to construct the corresponding node-security level adaptation matrix, and the data fields of the core encryption block are split into several sub-blocks. The sub-blocks are grouped using the node-security level adaptation matrix to form several primary fragments, and the access permission lists of each primary fragment are extracted synchronously. The access permission list is bound to the security level of the electronic file to generate a corresponding target storage node list, and several target storage nodes are generated according to the target storage node list.
6. The blockchain-based electronic records management method according to claim 1, characterized in that, The step of generating encryption keys adapted to each of the target storage nodes based on the target attribute parameters to complete the management of the electronic archives includes: The target attribute parameters are decoupled into multi-dimensional features to extract the node computing power threshold, bandwidth fluctuation coefficient and access authentication level. The corresponding dynamic weighting matrix is constructed by combining the confidentiality weight of the electronic file. The dynamic weighting matrix is then iteratively optimized by the particle swarm optimization algorithm to generate the corresponding key basic factor set. The key base factor set is XORed with the hash fragment of the core encryption block, and a timestamp seed from the target smart contract is introduced to generate the corresponding initial encryption key. The initial encryption key is distributed for verification to generate the corresponding encryption key for the target storage node.
7. The blockchain-based electronic records management method according to claim 6, characterized in that, The step of performing distributed verification on the initial encryption key to generate the corresponding encryption key for the target storage node includes: A target adaptation matrix is constructed based on the security threshold of the electronic archive and the access authentication level of the target storage node, and the corresponding verification cluster is selected from the initial encryption key based on the target adaptation matrix. A verification proposal corresponding to the verification cluster is generated using the PBFT algorithm, and the target encryption key is selected from the verification cluster according to the verification proposal. The target encryption key is set to the encryption key of the target storage node.
8. A blockchain-based electronic records management system, characterized in that, The system includes: The splitting module is used to split the electronic files to be managed into core data and redundant data according to the file security level, so as to generate a core encryption block based on the core data and a redundant encryption block based on the redundant data. The association module is used to associate and concatenate the hash values of the core encrypted block and the redundant encrypted block to generate a corresponding file feature code. The core encrypted block is uploaded to a preset blockchain platform to associate the storage address of the core encrypted block with the file feature code. At the same time, it is written into the initial smart contract of the preset blockchain platform to generate a corresponding target smart contract. The generation module is used to generate several corresponding target storage nodes according to the target smart contract, and import the several target storage nodes into the central server. The acquisition module is used to acquire target attribute parameters of the central server and generate encryption keys adapted to each target storage node based on the target attribute parameters, so as to complete the management of the electronic archives.
9. A computer comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the blockchain-based electronic record management method as described in any one of claims 1 to 7.
10. A readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the program implements the blockchain-based electronic record management method as described in any one of claims 1 to 7.