Private data security sharing method and system based on block chain

Abstract

The invention provides a privacy data security sharing method and system based on a block chain, and the method comprises the steps: carrying out the encryption and under-chain storage of obtained original privacy data, and generating a data identifier; constructing dynamic access control metadata based on the data identifier, and registering the dynamic access control metadata to the block chain to generate an initial version certificate; generating a new permission policy and derived key parameters in response to the permission change request; submitting an update transaction containing the new permission policy and the derived key parameter to the block chain, and generating an update version certificate; based on the access request, verifying the authority of the visitor through the version updating certificate, and when the verification is passed, generating a decryption parameter based on the derived key parameter and returning the data identifier; and in response to the data update request, generating update encrypted data based on the update version credential, and binding the historical version credential to generate a cross-version association proof. By adopting the method, the privacy data access authority management level can be provided.

Description

Technical Field

[0001] The present invention belongs to the field of data transmission security technology, and in particular relates to a method and system for securely sharing private data based on blockchain. Background Art

[0002] In the digital age, the secure sharing of private data has become a critical area for protecting individual rights and facilitating data circulation. Blockchain technology, with its decentralized and tamper-proof nature, provides a trusted infrastructure for private data sharing and is widely used in healthcare, finance, supply chains, and other scenarios. However, existing approaches have significant limitations in achieving both data privacy protection and dynamic management. Traditional blockchain systems typically rely on static access control mechanisms. Once data is uploaded to the blockchain, access rights are difficult to flexibly adjust, resulting in insufficient control over shared data by data owners. Furthermore, while existing solutions ensure the blockchain's immutability, they struggle to efficiently support data updates or permission changes, limiting the flexibility and practicality of private data sharing.

[0003] The core challenge lies in dynamically managing data access rights while maintaining the blockchain's immutable nature. While blockchain's immutability ensures data integrity, it also makes it difficult to directly modify on-chain data. When data owners need to update private data or adjust access permissions, the system requires a mechanism to record the new authorization status without compromising on-chain data integrity. This requirement further necessitates another technical challenge: how to upload new access control information to the blockchain through an efficient transaction mechanism while ensuring transparency and traceability of data versions. Failure to address this issue could lead to data owners losing effective control over their data due to lagging permission management, compromising the system's credibility and application value. Summary of the Invention

[0004] Based on this, it is necessary to provide a blockchain-based privacy data security sharing method and system to address the above technical problems, which can achieve dynamic and refined regulation of privacy data access rights while maintaining the essential advantages of the blockchain's tamper-proof characteristics.

[0005] In the first aspect, this application provides a method for securely sharing private data based on blockchain, including:

[0006] Encrypt and store the acquired original private data off-chain to generate a data identifier;

[0007] Build dynamic access control metadata based on the data identifier and register the dynamic access control metadata to the blockchain to generate the initial version certificate;

[0008] In response to a permission change request, generating a new permission policy and derived key parameters based on the current version of the dynamic access control metadata;

[0009] Submit an update transaction containing the new permission policy and derived key parameters to the blockchain to generate an updated version certificate;

[0010] Based on the access request, the accessor's authority is verified by updating the version credential. When the verification is successful, the decryption parameter is generated based on the derived key parameter and the data identifier is returned;

[0011] In response to a data update request, updated encrypted data is generated based on the updated version credential, and the historical version credential is bound to generate a cross-version association certificate.

[0012] In one embodiment, the obtained original private data is encrypted and stored off-chain to generate a data identifier, including:

[0013] The original private data is encrypted using the master symmetric key to generate encrypted data;

[0014] Upload the encrypted data to the off-chain distributed storage system and generate a CID as the data identifier;

[0015] A hash operation is performed on the master symmetric key and the CID to generate a key binding identifier, where the key binding identifier serves as the data identifier.

[0016] In one embodiment, dynamic access control metadata is constructed based on the data identifier and registered in a blockchain to generate an initial version of the credential, including:

[0017] Construct a metadata structure containing the hash value of the CID, the initial authorized public key group, and the hash value of the initial permission policy as dynamic access control metadata;

[0018] Write the key binding identifier into the dynamic access control metadata;

[0019] Dynamic access control metadata is registered to the blockchain through smart contracts, generating an initial Merkle root hash as the initial version certificate.

[0020] In one embodiment, in response to a permission change request, generating a new permission policy and derived key parameters based on a current version of dynamic access control metadata includes:

[0021] Generate an intermediate key seed using a key derivation function based on the key binding identifier and the current permission policy version number;

[0022] Input the intermediate key seed and the changed permission policy into the BLS threshold signature algorithm to generate the derived private key component;

[0023] A public key extraction operation is performed on the derived private key component to generate derived key parameters, where the derived key parameters are used for decryption authorization.

[0024] In one embodiment, submitting an update transaction containing a new permission policy and derived key parameters to a blockchain to generate an updated version of a credential includes:

[0025] Perform hash operation on the new permission policy to generate a new policy hash value;

[0026] Add the new policy hash value as a leaf node to the versioned Merkle tree on the blockchain to generate a new Merkle root hash;

[0027] Extract the Merkle path node sequence from the obtained historical Merkle root hash to the new Merkle root hash;

[0028] The new Merkle root hash and Merkle path node sequence are encoded into a lightweight version proof as the updated version certificate.

[0029] In one embodiment, in response to a data update request, generating updated encrypted data based on the updated version credential and binding the historical version credential to generate a cross-version association certificate includes:

[0030] Obtain the historical version credential associated with the data update request, where the historical version credential includes the historical Merkle root hash;

[0031] Verify the validity of historical version certificates through the zero-knowledge proof protocol and generate verification results;

[0032] If the verification result is valid, the off-chain ciphertext is incrementally updated based on the proxy re-encryption algorithm to generate updated encrypted data;

[0033] The updated encrypted data is bound to the historical version certificate to generate a version association tuple, where the version association tuple is used to generate a cross-version association certificate.

[0034] In one embodiment, generating a cross-version association certificate includes:

[0035] Extract the historical data hash and updated data hash from the version association tuple and construct a double-hash leaf node;

[0036] Based on the audit Merkle tree on the blockchain, double-hash leaf nodes are inserted as new leaves to generate an updated tree structure;

[0037] Compute the Merkle path proof from the historical Merkle root hash to the newly added leaf in the updated tree structure;

[0038] The Merkle path proof and the update operation timestamp are digitally signed to generate a cross-version association proof, which is used to verify the legitimacy of data version evolution on the chain.

[0039] Secondly, this application also provides a blockchain-based privacy data security sharing system, including:

[0040] The data encryption module is used to encrypt and store the acquired original private data off-chain and generate a data identifier;

[0041] The metadata registration module is used to construct dynamic access control metadata based on the data identifier and register the dynamic access control metadata to the blockchain to generate the initial version certificate;

[0042] A policy generation module, configured to generate a new permission policy and derived key parameters based on the current version of the dynamic access control metadata in response to a permission change request;

[0043] The credential update module is used to submit an update transaction containing new permission policies and derived key parameters to the blockchain to generate an updated version of the credential;

[0044] The access control module is used to verify the visitor's authority based on the access request by updating the version credential, and when the verification is passed, generate a decryption parameter based on the derived key parameter and return a data identifier;

[0045] The data version management module is used to respond to data update requests, generate updated encrypted data based on the updated version certificate, and bind the historical version certificate to generate a cross-version association certificate.

[0046] In a third aspect, the present application also provides a computer device comprising a memory and a processor, wherein the memory stores a computer program, and the processor implements the above-mentioned blockchain-based privacy data security sharing method when executing the computer program.

[0047] Fourthly, the present application also provides a computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, it implements the above-mentioned blockchain-based privacy data security sharing method.

[0048] The blockchain-based method and system for securely sharing private data encrypts and stores raw private data off-chain to generate a data identifier. Based on this data identifier, dynamic access control metadata is constructed and registered on the blockchain to generate an initial version certificate, thereby establishing a trusted permissions management foundation within the blockchain's immutable framework. When permissions change, a new permissions policy and derived key parameters are generated based on the current version of the dynamic access control metadata. An update transaction containing these parameters is submitted to the blockchain to generate an updated version certificate, enabling dynamic adjustment of permissions policies while safeguarding the blockchain's immutable nature. During data access, the updated version certificate verifies accessor permissions and generates decryption parameters based on the derived key parameters, enabling refined control of access rights. Furthermore, when data is updated, updated encrypted data is generated based on the updated version certificate and linked to previous version certificates to generate a cross-version association certificate, ensuring the synchronization and traceability of data changes and permission versions. This technical solution effectively enables dynamic and refined control of private data access rights while maintaining the inherent immutability of the blockchain. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the following briefly introduces the drawings required for use in the embodiments or related technical descriptions. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0050] Figure 1 A flowchart of a blockchain-based method for securely sharing private data provided by an embodiment of the present invention;

[0051] Figure 2 A schematic diagram of the structure of a blockchain-based private data security sharing system provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0052] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0053] First, a brief introduction is given to the terms involved in the embodiments of this application.

[0054] Blockchain is a distributed ledger technology whose core principle is to use cryptographic methods to encapsulate data in chronological order into continuous data blocks. These blocks are then verified and maintained by multiple nodes in the network, forming a tamper-proof, transparent, and traceable chain-like data structure. This technology leverages a decentralized consensus mechanism to ensure data integrity and credibility, enabling reliable storage and verification of information without relying on centralized institutions. This provides the underlying infrastructure for building a trusted data exchange environment.

[0055] A CID (Content Identifier) ​​is a unique data identifier generated using a cryptographic hash algorithm, enabling self-verifying data addressing in decentralized storage systems. Its core principle is to generate a fixed-length string by hashing the data content. This string is strictly bound to the data content, and any minor data change will result in a change in the CID value. This mechanism enables CID to independently verify data integrity and consistency without relying on centralized directories, providing a reliable content addressing foundation for blockchain and distributed storage systems.

[0056] A Key Derivation Function (KDF) is a cryptographic primitive that uses a deterministic algorithm to generate one or more cryptographically strong derived keys from a master key and auxiliary parameters (such as salt and context information). This function uses a one-way calculation to ensure that the output key is strictly bound to the input parameters and that the original master key cannot be reversed. This allows for the secure derivation of multiple subkeys from a single key source, providing a verifiable key management foundation for scenarios such as dynamic access control and key rotation.

[0057] The Versioned Merkle Tree is an extended tree-like data structure characterized by the introduction of a version identification mechanism based on the standard Merkle tree. By dynamically generating an independent root hash associated with each data state change operation, it achieves an unalterable record of historical states. Its technical core lies in embedding the version number or timestamp as additional metadata into the node hash calculation process, so that each update to the tree structure produces a verifiable new version root hash while preserving the complete Merkle path from the current version back to any historical version. By cryptographically binding the tree state differences between different versions, this structure provides blockchain systems with efficient multi-version data traceability and a foundation for incremental update verification, meeting the version audit requirements in dynamic permission management scenarios.

[0058] Based on the above explanations, the blockchain-based private data secure sharing method provided in the embodiments of this application is described. Schematically, the implementation environment includes: a terminal and a processor. The terminal is connected to the processor via a network signal; the processor can be a central processing unit, a neural network processor, or a multi-core processor, without limitation here.

[0059] In conjunction with the above explanations and implementation environments, the application scenarios of the embodiments of this application are described. The blockchain-based privacy data security sharing method provided in the embodiments of this application can be applied to, but not limited to, the following scenarios:

[0060] In the medical data sharing scenario, when a hospital obtains a patient's original private medical data, such as medical records and examination reports, it first encrypts this data, then stores it off-chain and generates a unique data identifier. Based on this data identifier, dynamic access control metadata is constructed and registered on the blockchain to generate an initial version certificate. When a patient changes their attending physician or needs to share medical data between different hospitals, a permission change request is responded to, a new permission policy and derived key parameters are generated based on the current version of the dynamic access control metadata, and an update transaction is submitted to the blockchain to generate an updated version certificate. For new access requests, the visitor's permissions are verified using the updated version certificate. If approved, decryption parameters are generated based on the derived key parameters and a data identifier is returned, allowing doctors to legally and compliantly access all relevant medical data of the patient. This not only protects patient privacy, but also enables the effective sharing of medical data among different entities, improving the quality and efficiency of medical services.

[0061] In the field of enterprise data management, a large amount of private data involving commercial secrets, such as product development materials and customer information, exists within enterprises. This method encrypts the original private data, stores it off-chain, and generates a data identifier. Dynamic access control metadata is then registered on the blockchain to generate an initial version of the certificate. When employee positions change or inter-departmental data collaboration requires a change in permissions, a new permission policy and derived key parameters are generated in response to the request, and an update transaction is submitted to generate an updated version of the certificate. When employees need to access relevant data, secure data sharing is achieved through permission verification. This not only protects the enterprise's core data assets, but also meets the company's internal data circulation needs, promoting efficient operations and innovative development.

[0062] In government services, government departments hold a large amount of private citizen data, such as household registration information and tax records. This method encrypts the original data, stores it off-chain, and generates a data identifier. Dynamic access control metadata is then registered on the blockchain to generate an initial version of the certificate. When different government departments need to share data or adjust data permissions due to business needs, new permission policies and derived key parameters are generated in response to the request, and an update transaction is submitted to generate an updated version of the certificate. When processing government service access requests, strict permission verification is performed to achieve secure sharing of government data, break down data barriers between departments, improve government service efficiency, and facilitate public services.

[0063] Illustratively, the blockchain-based privacy data security sharing method provided in the embodiments of the present application can also be applied to other application scenarios. This is only used as an example and is not limited to specific application scenarios.

[0064] In an exemplary embodiment, Figure 1 As shown, a method for securely sharing private data based on blockchain is provided. This embodiment uses the method applied to a terminal in the aforementioned implementation environment as an example. It is understood that the method can also be applied to a server, or to a system including a terminal and a server, and implemented through interaction between the terminal and the server. In this embodiment, the method includes the following steps 101 to 106:

[0065] Step 101: Encrypt and store the acquired original private data off-chain to generate a data identifier.

[0066] Specifically, the source of raw private data can be personal information submitted by users, medical records, financial statements, or environmental data such as temperature, humidity, and location collected by various sensors, as well as operating status information generated by IoT devices during operation. After obtaining this raw data, it is encrypted using a symmetric encryption algorithm (such as the Advanced Encryption Standard (AES)). The data is scrambled and replaced using the AES algorithm's key to convert it into ciphertext, preventing the data from being stolen and cracked during storage and transmission. The encrypted data is stored in an off-chain storage system, such as a distributed file system (such as IPFS) or a traditional centralized database. Off-chain storage systems offer high capacity and fast read and write speeds, enabling efficient storage of large amounts of encrypted private data. Generating a data identifier gives each piece of encrypted private data a unique "identity card." This identifier can be calculated using a hash algorithm (such as SHA-256) on the original or encrypted data, ensuring that each data identifier is accurately associated with the corresponding private data, facilitating subsequent retrieval and management. For example, in a medical information system, when a patient completes a series of examinations in a hospital and generates original medical record data containing detailed information such as the patient's basic information, examination items, and examination results, the above-mentioned encryption and storage measures are taken for this medical record data to generate a corresponding data identifier so that subsequent medical staff can quickly locate and access the patient's relevant private medical record data with authorization.

[0067] Step 102: construct dynamic access control metadata based on the data identifier and register the dynamic access control metadata to the blockchain to generate an initial version certificate.

[0068] Specifically, dynamic access control metadata describes the detailed permissions granted to private data, encompassing a wide range of information, including the subject of access (e.g., specific individuals, organizations, departments, or system roles), access timeframe (e.g., weekdays only), access operation type (e.g., read-only, read-write, execute), and data classification and grading (e.g., normal private data, highly sensitive private data). The process of constructing this metadata essentially involves customizing a flexible and adaptable set of access rules for each data identifier, based on the data's sensitivity, usage scenario, and pre-defined security policies. Subsequently, leveraging blockchain's smart contract technology, the dynamic access control metadata is registered with the blockchain network, where it is jointly verified and recorded by all blockchain nodes to ensure the metadata's integrity and immutability. An initial version certificate is then generated, documenting the initial registration of the dynamic access control metadata on the blockchain. This certificate includes key elements such as the metadata's hash value, registration timestamp, and data identifier association information, providing a trusted benchmark for subsequent permission changes and data access verification.

[0069] Step 103 : In response to the permission change request, a new permission policy and derived key parameters are generated based on the current version of the dynamic access control metadata.

[0070] Specifically, permission change requests may arise from a variety of situations, such as when data owners (such as individual users, enterprise administrators, data controllers, etc.) discover that the current access permission settings no longer meet actual needs, or when business scenarios change (such as employee position adjustments, changes in partnerships, updates to legal and regulatory requirements, etc.), resulting in the need to readjust the access scope, access time, and access operation type of private data. When a permission change request is received, the legitimacy of the request is verified. The verification content may include whether the requester's identity is legal and whether they have sufficient authority to submit the change request. After the verification is passed, the system analyzes and adjusts the current version of the dynamic access control metadata based on the specific content of the change request, and generates a new permission policy. The policy clarifies the detailed rules such as the access subject, time, and operation type after the change. Furthermore, to ensure secure access to data after the permission change, a key derivation function can be used based on the new permission policy to generate derived key parameters. The derived key parameters are closely related to the original encryption key, but are independent and targeted. They can make subsequent decryption operations comply with the new permission requirements, thereby achieving a smooth transition and precise control of access permissions.

[0071] Step 104: Submit an update transaction containing the new permission policy and derived key parameters to the blockchain to generate an updated version certificate.

[0072] Specifically, an update transaction encapsulates the new permission policy and derived key parameters into a data packet conforming to the blockchain transaction format. This data packet contains not only the specific permissions policy and derived key parameters, but also key elements such as a reference to the previous version of the credential (such as its hash value), a detailed description of the change (such as the reason for the change and an overview of the change), and the digital signature of the initiator. Once this transaction is submitted to the blockchain network, each blockchain node verifies and confirms it according to the established consensus mechanism. This verification process ensures the legitimacy, integrity, and authenticity of the transaction, preventing malicious or erroneous update transactions from being recorded. Once the transaction has been confirmed by a sufficient number of nodes and added to the latest block of the blockchain, an update certificate is generated. This complete record of all key information about the update transaction on the blockchain includes the hash value of the new permission policy, associated information about the derived key parameters, the updated access control metadata status, and the update timestamp. It replaces the previous version of the credential and serves as authoritative proof of the current access control status of private data, providing a solid basis for subsequent data access and permission tracing.

[0073] Step 105: Based on the access request, the visitor's authority is verified by updating the version credential. When the verification is successful, a decryption parameter is generated based on the derived key parameter and a data identifier is returned.

[0074] Specifically, an access request is usually initiated by a subject that wishes to obtain private data (such as an individual user, an application, or another system). The request content includes the identifier of the data to be accessed, the identity information of the visitor, the type of operation to be performed (such as read, write, delete, etc.), and the time of access. After receiving the request, the corresponding updated version of the credential is located based on the data identifier in the request, and the dynamic access control metadata is extracted from the updated version of the credential. According to the access rules defined therein, the identity of the visitor, the type of operation, the access time, etc. are verified item by item. For example, it checks whether the visitor is in the list of allowed access subjects, whether the current time is within the authorized access time period, and whether the requested operation type is within the scope of the granted permissions. If the access request passes the verification, the derived key parameters are used in combination with the decryption algorithm (corresponding to the algorithm used for encryption, such as the AES decryption algorithm) to generate decryption parameters. The decryption parameter is the key to unlocking encrypted private data. It can restore the ciphertext data to its original readable and usable format. The decryption parameter is returned together with the data identifier to the verified visitor, allowing the visitor to locate the encrypted private data stored off-chain based on the data identifier, and use the decryption parameter to successfully decrypt and obtain the required data content.

[0075] Step 106: In response to the data update request, generate updated encrypted data based on the updated version credential, and bind the historical version credential to generate a cross-version association certificate.

[0076] Specifically, a data update request may be due to a change in the private data itself (such as an update to a user's personal information or new environmental data detected by sensors), or due to the need to revise or supplement the data based on new business rules. Upon receiving a data update request, the new or revised private data is re-encrypted, referencing the latest access control metadata and encryption-related parameters recorded in the updated version credential, to generate updated encrypted data. This step ensures that the data remains encrypted after the update, meeting the requirements for secure storage and sharing. Furthermore, to establish correlation between data before and after the update, the updated encrypted data is bound to the historical version credential to generate a cross-version association certificate. This cross-version association certificate contains information such as the hash value of the previous version of the data, the hash value of the current version of the data, the update timestamp, a description of the update operation (such as which fields were modified and what content was added), and the relevant digital signature. This information is recorded through blockchain technology, allowing each data version to trace its historical evolution and ensuring data integrity and credibility.

[0077] This blockchain-based method for securely sharing private data encrypts and stores raw private data off-chain to generate a data identifier. Based on this data identifier, dynamic access control metadata is constructed and registered on the blockchain to generate an initial version certificate, thereby establishing a trusted permissions management foundation within the blockchain's immutable framework. When permissions change, a new permissions policy and derived key parameters are generated based on the current version of the dynamic access control metadata. An update transaction containing these parameters is submitted to the blockchain to generate an updated version certificate, enabling dynamic adjustment of permissions policies while maintaining the blockchain's immutable nature. During data access, the updated version certificate verifies accessor permissions and generates decryption parameters based on the derived key parameters, enabling refined control of access rights. Furthermore, when data is updated, updated encrypted data is generated based on the updated version certificate and linked to previous version certificates to generate a cross-version association certificate, ensuring the synchronization and traceability of data changes and permission versions. This technical solution effectively enables dynamic and refined control of private data access rights while maintaining the inherent advantages of blockchain's immutability.

[0078] In one embodiment, the obtained original private data is encrypted and stored off-chain to generate a data identifier, including:

[0079] The original private data is encrypted using the master symmetric key to generate encrypted data.

[0080] Specifically, the source of raw private data can be personal information proactively uploaded by users, internal business confidential documents, and patient physiological data collected by medical devices. After acquiring this raw data, a master symmetric key encryption algorithm is used to encrypt it to ensure the confidentiality of the data content. For example, the Advanced Encryption Standard (AES) algorithm is used to perform a byte-by-byte encryption conversion of the raw data using a pre-generated and securely stored master symmetric key, converting the plaintext data into ciphertext data and generating the encrypted data. With its high encryption performance and fast encryption and decryption speeds, the AES algorithm can effectively prevent data from being illegally stolen and cracked during storage and transmission, thereby providing a fundamental security guarantee for the subsequent storage and sharing of data.

[0081] Upload the encrypted data to the off-chain distributed storage system and generate a CID as the data identifier.

[0082] For example, there are many ways to implement an off-chain distributed storage system, such as a storage network built on the InterPlanetary File System (IPFS) and a distributed hash table (DHT), or a distributed storage platform based on a modified traditional cloud storage architecture. Taking IPFS as an example, after uploading the encrypted data to the IPFS network, IPFS will automatically generate a unique CID based on the hash value of the data content. The CID is closely bound to the data content, and as long as the data content remains unchanged, the CID remains unique and unchanged. This content-addressed storage method not only ensures the integrity and non-tamperability of the data during storage, but also facilitates the subsequent rapid and accurate retrieval and positioning of the corresponding encrypted data through the CID, thereby improving the efficiency of data storage and access.

[0083] A hash operation is performed on the master symmetric key and the CID to generate a key binding identifier, where the key binding identifier serves as the data identifier.

[0084] Furthermore, a hash operation is performed on the master symmetric key and the CID to generate a key-binding identifier, which serves as a data identifier. After the encrypted data is stored off-chain and the CID is obtained, to further enhance the security and relevance of the data, the master symmetric key and the CID are used as inputs and hashed together. For example, using the secure hash algorithm (SHA-256), the master symmetric key and the CID are concatenated and hashed to generate a fixed-length hash value, the key-binding identifier. This key-binding identifier combines the key information of the master symmetric key and the CID, including both the key characteristics of data encryption and the location identifier of the data stored off-chain. Using it as a data identifier allows for the simultaneous binding of the data's encryption key and storage location information during subsequent data access and permission verification processes, ensuring that only legitimate accessors who hold the correct key and can locate the data via the CID can decrypt and use the data, thereby establishing a more stringent security protection mechanism for data storage and access.

[0085] In one embodiment, dynamic access control metadata is constructed based on the data identifier and registered in a blockchain to generate an initial version of the credential, including:

[0086] A metadata structure including the hash value of the CID, the initial authorized public key group, and the hash value of the initial permission policy is constructed as dynamic access control metadata.

[0087] Specifically, data owners can construct a dynamic access control metadata structure consisting of three core fields: a hash value of the CID, an initial authorized public key group, and a hash value of the initial permission policy. For example, a SHA-256 operation is performed on the CID to generate a 64-bit hexadecimal hash value; the authorized party's public keys (such as RSA-2048 or Ed25519 public keys) are organized into an ordered list; and further, a Keccak-256 digest is calculated for the initial permission policy in JSON format. This triple structure cryptographically binds the data identifier, the authorized subject, and the policy rules to form an indivisible verification unit.

[0088] Write the key binding identifier to the dynamic access control metadata.

[0089] Furthermore, the key binding identifier is written into the metadata structure as a verification factor. For example, a new "KB_ID" field is added to the metadata to store the binding identifier generated by the master symmetric key and the CID. This allows the metadata to carry the dual functions of data integrity verification (CID hash) and key legitimacy verification (KB_ID), which is different from traditional metadata solutions that only store public keys.

[0090] Dynamic access control metadata is registered to the blockchain through smart contracts, generating an initial Merkle root hash as the initial version certificate.

[0091] Specifically, a smart contract is a self-executing contractual clause pre-written in a computer program on the blockchain. When dynamic access control metadata is passed as input to a smart contract, it verifies and processes the metadata according to pre-set rules. For example, it verifies whether the metadata is formatted correctly and whether the signature is valid. Once verified, the smart contract records the metadata in a new block on the blockchain and calculates the Merkle root hash value for the block. The Merkle root hash is calculated by hashing all transaction data in the block. It uniquely represents the data content of the entire block. This initial Merkle root hash is securely stored on the blockchain as the initial version certificate, ensuring the metadata's immutability and traceability, providing a trusted foundation for subsequent permission changes and data access verification. This embodiment integrates the cryptographic fingerprints of data, permissions, and policies through a triple metadata structure to achieve atomic verification of permission elements; the embedded writing of key binding identifiers binds key verification to metadata to prevent key replacement attacks; and the initial Merkle root certificate generated by the blockchain provides a trusted anchor for the dynamic permission system, laying the technical foundation for subsequent real-time updates of permissions, which is superior to traditional static metadata registration solutions.

[0092] In one embodiment, in response to a permission change request, generating a new permission policy and derived key parameters based on a current version of dynamic access control metadata includes:

[0093] Generate an intermediate key seed using a key derivation function based on the key binding identifier and the current permission policy version number;

[0094] Input the intermediate key seed and the changed permission policy into the BLS threshold signature algorithm to generate the derived private key component;

[0095] A public key extraction operation is performed on the derived private key component to generate derived key parameters, where the derived key parameters are used for decryption authorization.

[0096] For example, in response to a permission change request (such as a permission adjustment instruction initiated by a data owner or authorized administrator), an operator can perform key derivation and signing operations based on the current version of the dynamic access control metadata to generate a new permission policy and derived key parameters. Specifically, the operator extracts the key binding identifier and the current permission policy version number from the metadata as input, performs deterministic calculations using a key derivation function (such as HKDF-SHA256 or PBKDF2), and generates an intermediate key seed. This seed serves as the foundation of cryptographic security, ensuring the irreversibility and collision resistance of the derivation process. For example, in a medical data sharing scenario, the HKDF algorithm combines a salt value to enhance entropy and output a fixed-length seed value to prevent brute force attacks. Furthermore, the operator inputs the intermediate key seed and the changed permission policy (such as an updated access rule list) into a BLS threshold signature algorithm (such as a threshold scheme based on the BLS12-381 curve) to generate a set of derived private key components. This process supports distributed key generation and is only effective when a threshold number of component combinations are met, achieving fine-grained permission control. For example, the algorithm outputs multiple private key components and assigns them to different authorization nodes to ensure fault tolerance and decentralized verification of permission changes. The operator performs a public key extraction operation (such as elliptic curve point multiplication) on the derived private key component to generate a derived key parameter. This parameter serves as a publicly verifiable encryption credential for subsequent decryption authorization operations to ensure dynamic decryption capabilities during data access. This embodiment generates an intermediate key seed through a key derivation function and combines it with the BLS threshold signature algorithm to generate a derived private key component, and then extracts the public key to form a derived key parameter, thereby achieving dynamic key updates and secure management during permission changes, and providing high-strength tamper resistance and real-time policy effectiveness capabilities.

[0097] In one embodiment, submitting an update transaction containing a new permission policy and derived key parameters to a blockchain to generate an updated version of a credential includes:

[0098] Perform hash operation on the new permission policy to generate a new policy hash value;

[0099] Add the new policy hash value as a leaf node to the versioned Merkle tree on the blockchain to generate a new Merkle root hash;

[0100] Extract the Merkle path node sequence from the obtained historical Merkle root hash to the new Merkle root hash;

[0101] The new Merkle root hash and Merkle path node sequence are encoded into a lightweight version proof as the updated version certificate.

[0102] Exemplarily, the operator submits an update transaction containing a new permission policy and derived key parameters to the blockchain to generate an updated version of the credential. Specifically, the operator first performs a hash operation on the new permission policy (such as using the SHA-3 algorithm) to generate a new policy hash value of fixed length. This operation ensures that the policy content cannot be tampered with and can be efficiently verified. For example, in a financial data sharing scenario, the policy hash value is stored in the form of a 32-byte hexadecimal string as a cryptographic fingerprint of the permission change. Furthermore, the operator adds the new policy hash value as a leaf node to a preset versioned Merkle tree (such as an Ethereum state tree variant), and generates a new Merkle root hash by recursively calculating the hash values ​​of the sibling nodes, thereby achieving incremental updates to the tree structure. For example, an insertion operation triggers a reorganization of the tree nodes, generating a root hash value containing the new policy while retaining the historical node relationship. The operator extracts the Merkle path node sequence from the historical Merkle root hash to the new Merkle root hash. Specifically, the operator traverses the chain of intermediate hash nodes connecting the old and new root nodes in the tree structure to form a complete chain of state change evidence. The operator encodes the new Merkle root hash and the path node sequence into a lightweight version proof (such as using RLP encoding or Protobuf binary format) as the update version certificate. This embodiment uses hash operations and Merkle tree structure updates, combined with the encoding method of lightweight version proofs, to achieve efficient submission and verification of update transactions on the blockchain, ensuring the credibility and traceability of the update version certificate, and effectively improving the security and efficiency of data sharing.

[0103] In one embodiment, in response to a data update request, generating updated encrypted data based on the updated version credential and binding the historical version credential to generate a cross-version association certificate includes:

[0104] Obtain the historical version credential associated with the data update request, where the historical version credential includes the historical Merkle root hash;

[0105] Verify the validity of historical version certificates through the zero-knowledge proof protocol and generate verification results;

[0106] If the verification result is valid, the off-chain ciphertext is incrementally updated based on the proxy re-encryption algorithm to generate updated encrypted data;

[0107] The updated encrypted data is bound to the historical version certificate to generate a version association tuple, where the version association tuple is used to generate a cross-version association certificate.

[0108] Exemplarily, in response to a data update request, an operator performs a data update and version binding operation based on the updated version credential. Specifically, the operator obtains a historical version credential associated with the data update request. This credential contains a historical Merkle root hash value, which serves as a cryptographic anchor for the data's historical state. Exemplarily, in an electronic medical record update scenario, the credential contains the root hash and path nodes of the previous version of the patient's medical record. Furthermore, the operator can perform version validity verification on the historical version credential using a zero-knowledge proof protocol (such as zk-SNARKs or Bulletproofs): generating a proof circuit to verify the consistency of the Merkle path with the current blockchain state and outputting a binary verification result. This process ensures that the data update operation does not violate historical permission constraints. If the verification is valid, the operator performs an incremental update on the original ciphertext stored off-chain using a proxy re-encryption algorithm: preserving the historical data ciphertext structure and modifying only the changed fields to generate the updated encrypted data. For example, when updating a financial transaction record, only the amount field is re-encrypted, leaving other information unchanged. The operator binds the updated encrypted data to the historical version credential to generate a version association tuple. Specifically, the operator calculates the concatenation value of the updated data hash and the historical version credential hash to form a structured tuple (such as {"new_data_hash":"0x...","old_version_proof":"0x..."}), which serves as the basis for generating a cross-version association proof. This embodiment verifies the validity of the historical version credential through zero-knowledge proof, combines the proxy re-encryption algorithm to achieve secure incremental updates, and generates a version association tuple to construct a cross-version association proof, ensuring the security and traceability of data updates and effectively improving the reliability and transparency of private data in multi-version management.

[0109] Furthermore, generating a cross-version association certificate may include:

[0110] Extract the historical data hash and updated data hash from the version association tuple and construct a double-hash leaf node;

[0111] Based on the audit Merkle tree on the blockchain, double-hash leaf nodes are inserted as new leaves to generate an updated tree structure;

[0112] Compute the Merkle path proof from the historical Merkle root hash to the newly added leaf in the updated tree structure;

[0113] The Merkle path proof and the update operation timestamp are digitally signed to generate a cross-version association proof, which is used to verify the legitimacy of data version evolution on the chain.

[0114] Specifically, the historical data hash and the updated data hash in the version-associated tuple are extracted to construct a double-hash leaf node. For example, the historical data hash and the updated data hash represent the states before and after the data is updated, respectively. These two hash values ​​are concatenated and hashed again to obtain a new hash value as a double-hash leaf node to ensure the association between the old and new data versions. Exemplarily, based on the audit Merkle tree on the blockchain, the double-hash leaf node is inserted as a new leaf to generate an updated tree structure. The audit Merkle tree is a special Merkle tree structure that uses a specific algorithm to insert the new double-hash leaf node into the appropriate position of the tree, and recalculate the hash value of the parent node to obtain an updated tree structure, thereby ensuring that the entire audit Merkle tree can reflect the evolution of the data version. Furthermore, the Merkle path proof from the historical Merkle root hash to the new leaf in the updated tree structure is calculated. By traversing the audit Merkle tree, the hash values ​​of all sibling nodes on the path from the historical Merkle root hash to the newly added leaf are extracted and arranged in sequence to form a Merkle path proof, which can verify whether the newly added leaf node actually exists in the current audit Merkle tree, thereby ensuring the non-tamperability of the data version evolution. Finally, the Merkle path proof and the update operation timestamp are digitally signed to generate a cross-version association proof. For example, the RSA digital signature algorithm is used to jointly sign the Merkle path proof and the update operation timestamp to generate a signature value. The signature value, together with the Merkle path proof and the timestamp, constitutes a cross-version association proof for on-chain verification of the legitimacy of the data version evolution. The entire embodiment ensures the verifiability and non-tamperability of the data version evolution by constructing a double-hash leaf node and generating a path proof using the audit Merkle tree, and then combining it with digital signature technology, effectively improving the security and credibility of the data sharing process.

[0115] In summary, the blockchain-based method for securely sharing private data provided by this application generates a data identifier by encrypting the original private data and storing it off-chain. Dynamic access control metadata is constructed based on this identifier and registered on the blockchain to generate an initial version credential. When permissions change, a new permission policy and derived key parameters are generated based on the current dynamic access control metadata, and an update transaction is submitted to the blockchain to generate an updated version credential. For data update requests, updated encrypted data is generated based on the updated version credential, and the historical version credential is bound to generate a cross-version association certificate. This technical solution achieves dynamic and refined control of private data access rights while maintaining the essential advantage of the blockchain's immutable nature through a collaborative verification mechanism of off-chain encrypted storage and on-chain dynamic metadata, effectively meeting the needs for secure sharing of private data in multiple scenarios.

[0116] It should be understood that, although the various steps in the flowcharts involved in the various embodiments described above are displayed in sequence according to the instructions of the arrows, these steps are not necessarily executed in sequence in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order restriction on the execution of these steps, and these steps can be executed in other orders. Moreover, at least a portion of the steps in the flowcharts involved in the various embodiments described above can include multiple steps or multiple stages, and these steps or stages are not necessarily executed and completed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a portion of steps or stages in other steps.

[0117] Based on the same inventive concept, embodiments of the present application also provide a blockchain-based private data secure sharing system 10 for implementing the aforementioned blockchain-based private data secure sharing method. The solution provided by this system is similar to the solution described in the aforementioned method. Therefore, the specific limitations of one or more embodiments of the blockchain-based private data secure sharing system 10 provided below can be found in the above-mentioned limitations of the blockchain-based private data secure sharing method and will not be further elaborated here.

[0118] In an exemplary embodiment, Figure 2 As shown, a blockchain-based privacy data security sharing system 10 is provided, comprising:

[0119] Data encryption module 11, used to encrypt and store the acquired original private data off-chain and generate a data identifier;

[0120] A metadata registration module 12 is used to construct dynamic access control metadata based on the data identifier and register the dynamic access control metadata to the blockchain to generate an initial version certificate;

[0121] a policy generation module 13 for generating a new permission policy and derived key parameters based on the current version of the dynamic access control metadata in response to a permission change request;

[0122] The credential update module 14 is used to submit an update transaction containing the new permission policy and derived key parameters to the blockchain to generate an updated version of the credential;

[0123] The access control module 15 is used to verify the visitor's authority based on the access request by updating the version credential, and when the verification is successful, generate a decryption parameter based on the derived key parameter and return a data identifier;

[0124] The data version management module 16 is used to generate updated encrypted data based on the updated version certificate in response to a data update request, and bind the historical version certificate to generate a cross-version association certificate.

[0125] In one embodiment, the data encryption module 11 includes:

[0126] The encryption processing unit is used to encrypt the original private data using the master symmetric key to generate encrypted data.

[0127] The storage upload unit is used to upload encrypted data to the off-chain distributed storage system and generate a CID as a data identifier.

[0128] The binding identifier generation unit is used to perform a hash operation on the master symmetric key and the CID to generate a key binding identifier, wherein the key binding identifier serves as a data identifier.

[0129] In one embodiment, the metadata registration module 12 includes:

[0130] The metadata structure unit is used to construct a metadata structure containing the hash value of the CID, the initial authorized public key group, and the initial permission policy hash value as dynamic access control metadata.

[0131] The identifier writing unit is used to write the key binding identifier into the dynamic access control metadata.

[0132] The on-chain registration unit is used to register dynamic access control metadata to the blockchain through smart contracts and generate an initial Merkle root hash as the initial version certificate.

[0133] In one embodiment, the policy generation module 13 includes:

[0134] The key derivation unit is used to generate an intermediate key seed through a key derivation function based on the key binding identifier and the current permission policy version number.

[0135] The signature generation unit is used to input the intermediate key seed and the changed permission policy into the BLS threshold signature algorithm to generate a derived private key component.

[0136] The parameter generation unit is used to perform a public key extraction operation on the derived private key component to generate a derived key parameter, wherein the derived key parameter is used for decryption authorization.

[0137] In one embodiment, the credential update module 14 includes:

[0138] The policy hash unit is used to perform a hash operation on the new permission policy to generate a new policy hash value.

[0139] The Merkle tree update unit is used to add the new policy hash value as a leaf node to the versioned Merkle tree on the blockchain to generate a new Merkle root hash.

[0140] The path extraction unit is used to extract the Merkle path node sequence from the acquired historical Merkle root hash to the new Merkle root hash.

[0141] The certificate encoding unit is used to encode the new Merkle root hash and Merkle path node sequence into a lightweight version proof as the update version certificate.

[0142] In one embodiment, the data version management module 16 includes:

[0143] The credential acquisition unit is used to obtain a historical version credential associated with the data update request, wherein the historical version credential includes a historical Merkle root hash.

[0144] The zero-knowledge verification unit is used to verify the validity of historical version certificates through the zero-knowledge proof protocol and generate verification results.

[0145] The re-encryption unit is used to perform incremental updates on the off-chain ciphertext based on the proxy re-encryption algorithm to generate updated encrypted data if the verification result is valid.

[0146] The tuple generation unit is used to bind the updated encrypted data with the historical version certificate to generate a version association tuple, wherein the version association tuple is used to generate a cross-version association certificate.

[0147] In one embodiment, the data version management module 16 further includes:

[0148] The double hash construction unit is used to extract the historical data hash and the updated data hash in the version associated tuple and construct a double hash leaf node.

[0149] The tree structure update unit is used to insert double hash leaf nodes as new leaves based on the audit Merkle tree on the blockchain to generate an updated tree structure.

[0150] The path proof unit is used to calculate the Merkle path proof from the historical Merkle root hash to the newly added leaves in the updated tree structure.

[0151] The association proof generation unit is used to digitally sign the Merkle path proof and the update operation timestamp to generate a cross-version association proof, where the cross-version association proof is used to verify the legitimacy of data version evolution on the chain.

[0152] In one embodiment, a computer device is provided, comprising a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the steps of the aforementioned method for securely sharing private data based on blockchain are implemented.

[0153] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments are implemented.

[0154] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to the partial description of the method embodiments. The device embodiments described above are merely illustrative, wherein the components described as separate parts may or may not be physically separated, and the parts displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the disclosed solution. A person of ordinary skill in the art can understand and implement it without expending creative work.

[0155] The above-described embodiments merely represent several implementation methods of the embodiments of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the patent application. It should be noted that a person skilled in the art may make various modifications and improvements without departing from the concept of the embodiments of the present application, and these modifications and improvements fall within the scope of protection of the embodiments of the present application.

Claims

1. A method for securely sharing private data based on blockchain, characterized in that: The method comprises: Encrypt and store the acquired original private data off-chain to generate a data identifier; constructing dynamic access control metadata based on the data identifier and registering the dynamic access control metadata to the blockchain to generate an initial version credential; In response to the permission change request, generating a new permission policy and derived key parameters based on the current version of the dynamic access control metadata; Submitting an update transaction including the new permission policy and the derived key parameters to the blockchain to generate an updated version certificate; Based on the access request, verify the visitor's authority through the updated version credential, and when the verification is successful, generate a decryption parameter based on the derived key parameter and return the data identifier; In response to a data update request, updated encrypted data is generated based on the updated version credential, and the historical version credential is bound to generate a cross-version association certificate.

2. The method according to claim 1, characterized in that The process of encrypting and storing the acquired original private data off-chain and generating a data identifier includes: Encrypting the original private data using a master symmetric key to generate encrypted data; Upload the encrypted data to the off-chain distributed storage system and generate a CID as the data identifier; A hash operation is performed on the master symmetric key and the CID to generate a key binding identifier, wherein the key binding identifier serves as the data identifier.

3. The method according to claim 2, characterized in that The step of constructing dynamic access control metadata based on the data identifier and registering the dynamic access control metadata in the blockchain to generate an initial version credential includes: Constructing a metadata structure including a hash value of the CID, an initial authorization public key group, and a hash value of an initial permission policy as the dynamic access control metadata; Writing the key binding identifier into the dynamic access control metadata; The dynamic access control metadata is registered to the blockchain through a smart contract, and an initial Merkle root hash is generated as the initial version certificate.

4. The method according to claim 3, characterized in that The step of generating a new permission policy and derived key parameters based on the current version of the dynamic access control metadata in response to the permission change request includes: Generate an intermediate key seed through a key derivation function based on the key binding identifier and the current permission policy version number; Input the intermediate key seed and the changed permission policy into the BLS threshold signature algorithm to generate a derived private key component; A public key extraction operation is performed on the derived private key component to generate the derived key parameters, wherein the derived key parameters are used for decryption authorization.

5. The method according to claim 1, wherein Submitting an update transaction including the new permission policy and the derived key parameters to the blockchain to generate an updated version credential includes: Performing a hash operation on the new permission policy to generate a new policy hash value; Add the new policy hash value as a leaf node to the versioned Merkle tree on the blockchain to generate a new Merkle root hash; Extracting a Merkle path node sequence from the obtained historical Merkle root hash to the new Merkle root hash; The new Merkle root hash and the Merkle path node sequence are encoded into a lightweight version proof as the updated version certificate.

6. The method according to claim 5, characterized in that The step of generating updated encrypted data based on the updated version credential and binding the updated version credential to generate a cross-version association certificate in response to the data update request includes: Obtaining the historical version credential associated with the data update request, wherein the historical version credential includes the historical Merkle root hash; Verify the validity of the historical version certificate using a zero-knowledge proof protocol to generate a verification result; If the verification result is valid, an incremental update is performed on the off-chain ciphertext based on the proxy re-encryption algorithm to generate the updated encrypted data; The updated encrypted data is bound to the historical version credential to generate a version association tuple, wherein the version association tuple is used to generate the cross-version association certificate.

7. The method according to claim 6, characterized in that Generating the cross-version association certificate includes: Extracting the historical data hash and the updated data hash in the version-associated tuple to construct a double-hash leaf node; Based on the audit Merkle tree on the blockchain, insert the double hash leaf node as a new leaf to generate an updated tree structure; Calculating a Merkle path proof from the historical Merkle root hash to the newly added leaf in the updated tree structure; The Merkle path proof and the update operation timestamp are digitally signed to generate the cross-version association proof, wherein the cross-version association proof is used to verify the legitimacy of data version evolution on the chain.

8. A privacy data security sharing system based on blockchain, characterized by: The system comprises: The data encryption module is used to encrypt and store the acquired original private data off-chain and generate a data identifier; A metadata registration module, configured to construct dynamic access control metadata based on the data identifier and register the dynamic access control metadata in the blockchain to generate an initial version credential; a policy generation module, configured to generate a new permission policy and derived key parameters based on the current version of the dynamic access control metadata in response to a permission change request; A credential update module, configured to submit an update transaction including the new permission policy and the derived key parameters to the blockchain to generate an updated version of the credential; An access control module is configured to verify the visitor's authority based on the access request using the updated version of the credential, and when the verification is successful, generate a decryption parameter based on the derived key parameter and return the data identifier; The data version management module is used to generate updated encrypted data based on the updated version certificate in response to a data update request, and bind the historical version certificate to generate a cross-version association certificate.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the method according to any one of claims 1 to 7 is implemented.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method according to any one of claims 1 to 7 is implemented.

Images