Data element right and fine-grained access control system and method based on blockchain distributed digital identity did

Abstract

The application provides a data element right confirmation and fine-grained access control system and method based on a blockchain distributed digital identity DID, a symmetric key is used by a system data owner terminal to encrypt data into ciphertext.A contract obtains a public key through a DID resolver to verify a signature and a CID uniqueness.After a credential issuing node verifies a qualification, an attribute private key bound with a DID private key proof is generated.An access control contract extracts an attribute matching strategy.If verification and matching are passed, a CID and a key ciphertext are returned.A data user terminal uses an attribute private key thereof to unpack the key ciphertext to recover a symmetric key, and decrypts data ciphertext obtained from an IPFS to obtain original data.The application binds a VC attribute, a DID private key proof and a CP-ABE attribute private key, dynamically verifies a state and a strategy by an access control contract, realizes fine-grained access control based on AND, OR or a k / n threshold, and reduces risks of credential forgery, key misuse and authorization lag.

Description

Technical Field

[0001] This invention relates to the fields of computer networks, blockchain data security, and cryptographic access control technology, and in particular to a data element ownership confirmation and fine-grained access control system and method based on blockchain distributed digital identity (DID). Background Technology

[0002] The cross-domain flow of data elements typically requires addressing four core issues: identity authentication, data ownership verification, secure data storage, and access authorization. Existing systems often employ centralized public key infrastructure / certificate authorities, centralized identity databases, access control lists, or role-based access control as their infrastructure. Data ownership records are maintained by the platform operator, while access permission determination is performed by the platform server. While such solutions are relatively simple to implement, in scenarios involving interconnected multiple institutions, it is necessary to pre-establish certificate mutual recognition and account mapping relationships among the institutions, leading to high costs for cross-domain expansion.

[0003] With the improvement of data infrastructure and the advancement of market-based allocation of data elements, data resources are gradually shifting from internal organizational applications to cross-departmental, cross-industry, and cross-regional circulation. Data providers typically expect to complete ownership registration, authorization management, and transaction auditing without disclosing the original data content; data users, after obtaining legal authorization, need to efficiently verify the source, integrity, and availability of data; and regulatory auditors need the ability to retrospectively trace data access behavior, verify authorization basis, and identify abnormal use. These shared needs place demands on the system to simultaneously possess the capabilities of trusted identity, trusted ownership confirmation, trusted authorization, and trusted auditing.

[0004] Existing centralized platforms typically have the platform operator uniformly maintaining the account system, data directory, permission table, and access logs. This model is relatively easy to deploy within a single organization, but in multi-organizational collaboration scenarios, it faces the challenge of expanding trust boundaries: the account systems of different organizations are difficult to mutually recognize, data owners cannot independently prove their data ownership, platform administrators may become potential risk points for permission abuse or log tampering, and access control policies are often tightly coupled with the platform's business code, making it difficult to flexibly express complex attribute combinations.

[0005] Blockchain, distributed digital identity, verifiable credentials, the InterPlanetary File System (IPFS), and ciphertext policy attribute-based encryption (CP-ABE) can each address specific aspects of the aforementioned problems. Blockchain is suitable for recording immutable state summaries and transaction logs; DID helps establish entity identifiers that do not rely on a single identity service provider; VC can transform real-world qualifications into verifiable digital attributes; IPFS is suitable for storing large-scale encrypted data and ensuring its integrity through content addressing; and CP-ABE can encapsulate access permissions as cryptographic policy constraints. The core of this solution lies in the collaborative design of these technological capabilities, enabling them to jointly serve the evidence preservation, ownership verification, and fine-grained access control of data elements.

[0006] Blockchain technology provides an immutable distributed ledger that can be used to record data summaries, timestamps, and transaction logs; DID technology enables entities to verify their public keys and identity status through on-chain DID documents; VC technology can bind real-world qualifications to DIDs in the form of digital signatures; content-addressed storage systems such as IPFS can store large-volume encrypted files off-chain; CP-ABE can encapsulate data keys in the form of attribute policy trees, ensuring that the data key can only be recovered when the entity's attributes meet the preset policy.

[0007] In existing technical solutions, some only use blockchain as a log storage tool. While it can record access flows, it cannot effectively verify the authenticity of the visitor's identity attributes, the validity of credentials, or whether the attribute key is correctly bound to the principal's private key. Other solutions only use CP-ABE technology to protect data keys, but their attribute private keys are usually statically issued by a centralized institution, making it difficult to respond promptly to dynamic needs such as credential revocation, changes in principal status, or cross-institutional attribute updates. This invention uses smart contracts to dynamically verify the DID status, VC validity status, and policy matching results on the blockchain, thereby transforming access control from a single static authorization into a continuous authorization process with auditability, revocability, and traceability. Summary of the Invention

[0008] This invention aims to at least solve the technical problems existing in the prior art, and innovatively proposes a data element ownership confirmation and fine-grained access control system and method based on blockchain distributed digital identity (DID).

[0009] To achieve the above-mentioned objectives of the present invention, the present invention provides a data element ownership confirmation and fine-grained access control system based on blockchain distributed digital identity (DID). The system includes a data owner terminal, a data user terminal, a certificate issuance node, a regulatory audit node, a cryptographic engine, a verifiable certificate / verifiable display management module, a DID parser, a blockchain network, and an IPFS off-chain encrypted storage network. DID management contracts, data ownership verification and storage contracts, and access control contracts are deployed on the blockchain network; The DID management contract is used to receive DID registration requests, update requests, or cancellation requests from participating entities, verify the DID documents submitted by participating entities, and write the status of the verified DID documents into the blockchain network. The data owner terminal is used to generate a data symmetric key through a cryptographic engine, use the data symmetric key to symmetrically encrypt the original data to obtain the data ciphertext, upload the data ciphertext to the IPFS off-chain ciphertext storage network to obtain the content identifier CID, and submit the ownership confirmation request including the owner DID, identifier CID, timestamp, digital signature and metadata to the data ownership confirmation and storage contract. The data ownership confirmation and storage contract is used to obtain the public key corresponding to the owner's DID through the DID parser, verify the digital signature based on the public key, verify the uniqueness of the identifier CID, generate the asset identifier AssetID based on the owner's DID, identifier CID and timestamp, and write the AssetID, identifier CID, owner's DID, timestamp, digital signature and asset status into the blockchain network. The credential issuance node is used to issue a verifiable credential VC containing a set of attributes, an expiration date, and a revocation identifier to the owner DID corresponding to the participating entity after verifying the entity's qualifications, and to generate an attribute private key that is bound to the corresponding DID's private key holding certificate; The data owner terminal is also used to establish access policies for the original data corresponding to AssetID, and to encapsulate the data symmetric key using ciphertext policy attribute base encryption CP-ABE through a cryptographic engine to obtain the key ciphertext associated with AssetID. The data user terminal is used to submit a verifiable random challenge signature that displays the VP and owner DID for the AssetID; The access control contract is used to verify the credential issuer signature, VC validity period, VC revocation status, DID status, and DID private key holding proof represented by the DID random challenge signature of the VP based on the verifiable credential / verifiable display management module and DID parser. It extracts the attribute set from the verified VP and determines whether the attribute set meets the access policy. When all verifications pass and the attribute set meets the access policy, it returns the identifier CID and key ciphertext to the data user terminal. When any verification fails or the attribute set does not meet the access policy, access is denied and an audit log is generated. The data user terminal is also used to decapsulate the key ciphertext using the attribute private key bound to its own DID to recover the data symmetric key, and to decrypt the data ciphertext obtained from the IPFS off-chain ciphertext storage network according to the identifier CID to obtain the original data. The regulatory audit node is used to audit and query the access requests and results of data user terminals based on audit logs.

[0010] On the other hand, the present invention also provides a method for data element ownership confirmation and fine-grained access control based on blockchain distributed digital identity (DID), applied to the system; the method includes: S1. Configure blockchain nodes and off-chain distributed storage nodes, deploy DID management contracts, data ownership confirmation and storage contracts and access control contracts on blockchain nodes, and generate public parameters and master keys for ciphertext policy attribute base encryption CP-ABE; S2. Participating entities generate public-private key pairs locally, generate DID identifiers and construct DID documents based on the public key in the public-private key pair, digitally sign the DID documents using the private key corresponding to the public key, and submit the signed DID documents to the DID management contract. The DID management contract verifies the digital signature and anchors the verified DID documents to the blockchain node. S3. After verifying the entity qualifications of the participating entities, the credential issuing node issues a verifiable credential VC containing an attribute set, validity period and revocation identifier for the DID of the participating entities in step S2. Based on the CP-ABE master key, attribute set and private key holding certificate of the corresponding DID generated in step S1, an attribute private key bound to the DID is generated. S4. The data owner terminal generates a data symmetric key, uses the data symmetric key to symmetrically encrypt the original data to obtain the data ciphertext, uploads the data ciphertext to the off-chain distributed storage node to obtain the content identifier CID, and generates a digital signature for the identifier CID. S5. The data owner terminal submits the identifier CID obtained in step S4, along with the owner DID, timestamp, digital signature, and metadata of the data owner terminal, to the data ownership confirmation and storage contract. The data ownership confirmation and storage contract parses the DID document corresponding to the owner DID anchored in step S2 to obtain the public key, verifies the digital signature and the uniqueness of the identifier CID based on the public key, generates the asset identifier AssetID based on the owner DID, identifier CID, and timestamp, and writes the AssetID, identifier CID, owner DID, timestamp, digital signature, and asset status into the blockchain node. S6. The data owner terminal establishes an access policy for the AssetID generated in step S5, and encapsulates the data symmetric key generated in step S4 using CP-ABE according to the access policy to obtain the key ciphertext associated with the AssetID. S7. The data user submits a verifiable VP and DID random challenge signature for the AssetID generated in step S5. The access control contract verifies the VP and DID random challenge signature, extracts the attribute set from the verified VP, and determines whether the attribute set meets the access policy established in step S6. If the verification is successful and the attribute set meets the access policy, the identifier CID obtained in step S4 and the key ciphertext obtained in step S6 are returned to the data user. If the verification fails or the attribute set does not meet the access policy, the data user's access request is rejected and an audit log is generated. S8. The data user uses the attribute private key generated in step S3 and bound to its own DID to perform CP-ABE decapsulation on the key ciphertext returned in step S7 to recover the data symmetric key generated in step S4. Based on the identifier CID returned in step S7, the user obtains the data ciphertext from the off-chain distributed storage node and uses the recovered data symmetric key to decrypt the data ciphertext to obtain the original data.

[0011] The beneficial effects of this invention are as follows: This invention, through the collaborative design of blockchain, distributed digital identity (DID), verifiable credential (VC), IPFS off-chain encrypted storage, and encrypted policy attribute base encryption (CP-ABE), establishes a trusted processing mechanism for data element identity authentication, ownership verification, confidential storage, access authorization, and audit traceability. Specifically, the DID management contract manages the DID documents and identity status of participating entities on-chain, reducing single points of failure and cross-institutional certificate recognition and account mapping costs inherent in centralized identity systems. By associating the owner's DID, identifier (CID), and timestamp to generate an asset identifier (AssetID), and writing ownership-related information into the blockchain network, an immutable and verifiable ownership association is established between the encrypted data content address and the data owner without needing to put the original data on-chain. Simultaneously, the IPFS off-chain encrypted storage network is used to store symmetrically encrypted encrypted data, thus balancing data confidentiality and on-chain storage efficiency. The access control contract binds the attribute set, DID private key holding proof, and CP-ABE attribute private key in the verifiable credential VC. The access control contract dynamically verifies the credential issuer's signature, VC validity period, VC revocation status, DID status, and DID private key holding proof. It then matches the attribute set with the access policy tree, enabling fine-grained expression of access permissions based on AND, OR, or k / n threshold logic. This reduces the risks of credential misuse, attribute key abuse, and authorization not expiring in time after changes in subject identity. Simultaneously, the access control contract releases the identifier CID and key ciphertext associated with AssetID only when identity verification, credential status verification, and policy matching all pass. It also generates an audit log for the reason for access denial and access request information. This gives the data access process the technical effects of dynamic authorization, revocation, traceability, and auditability, thereby improving the credibility of identity, ownership, authorization security, and audit reliability in the flow of data elements across institutions and domains.

[0012] 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

[0013] The above and / or additional aspects and advantages of the present invention will become apparent and readily understood from the description of the embodiments taken in conjunction with the following drawings, in which: Figure 1 This is a schematic diagram of the structure of a data element ownership confirmation and fine-grained access control system based on blockchain distributed digital identity (DID) according to the present invention. Figure 2 This is a flowchart of the entity identity initialization, DID registration and VC issuance process of the present invention; Figure 3This is a flowchart of the dual-channel process of off-chain encrypted storage and on-chain evidence storage and rights confirmation in this invention; Figure 4 This is a flowchart of the fine-grained access control based on VC and CP-ABE of the present invention. Detailed Implementation

[0014] Embodiments of the present invention are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0015] Example 1 like Figures 1 to 4 As shown, a data element ownership confirmation and fine-grained access control system based on blockchain distributed digital identity (DID) is disclosed. The system includes a data owner terminal, a data user terminal, a certificate issuance node, a regulatory audit node, a cryptographic engine, a verifiable certificate / verifiable display management module, a DID parser, a blockchain network, and an IPFS off-chain encrypted storage network. DID management contracts, data ownership verification and storage contracts, and access control contracts are deployed on the blockchain network; The DID management contract is used to receive DID registration requests, update requests, or cancellation requests from participating entities, verify the DID documents submitted by participating entities, and write the status of the verified DID documents into the blockchain network. The data owner terminal is used to generate a data symmetric key through a cryptographic engine, use the data symmetric key to symmetrically encrypt the original data to obtain the data ciphertext, upload the data ciphertext to the IPFS off-chain ciphertext storage network to obtain the content identifier CID, and submit the ownership confirmation request including the owner DID, identifier CID, timestamp, digital signature and metadata to the data ownership confirmation and storage contract. The data ownership confirmation and storage contract is used to obtain the public key corresponding to the owner's DID through the DID parser, verify the digital signature based on the public key, verify the uniqueness of the identifier CID, generate the asset identifier AssetID based on the owner's DID, identifier CID and timestamp, and write the AssetID, identifier CID, owner's DID, timestamp, digital signature and asset status into the blockchain network. The credential issuance node is used to issue a verifiable credential VC containing a set of attributes, an expiration date, and a revocation identifier to the owner DID corresponding to the participating entity after verifying the entity's qualifications, and to generate an attribute private key that is bound to the corresponding DID's private key holding certificate; The data owner terminal is also used to establish access policies for the original data corresponding to AssetID, and to encapsulate the data symmetric key using ciphertext policy attribute base encryption CP-ABE through a cryptographic engine to obtain the key ciphertext associated with AssetID. The data user terminal is used to submit a verifiable random challenge signature that displays the VP and owner DID for the AssetID; The access control contract is used to verify the credential issuer signature, VC validity period, VC revocation status, DID status, and DID private key holding proof represented by the DID random challenge signature of the VP based on the verifiable credential / verifiable display management module and DID parser. It extracts the attribute set from the verified VP and determines whether the attribute set meets the access policy. When all verifications pass and the attribute set meets the access policy, it returns the identifier CID and key ciphertext to the data user terminal. When any verification fails or the attribute set does not meet the access policy, access is denied and an audit log is generated. The data user terminal is also used to decapsulate the key ciphertext using the attribute private key bound to its own DID to recover the data symmetric key, and to decrypt the data ciphertext obtained from the IPFS off-chain ciphertext storage network according to the identifier CID to obtain the original data. The regulatory audit node is used to audit and query the access requests and results of data user terminals based on audit logs.

[0016] The aforementioned data element ownership confirmation and fine-grained access control system based on blockchain distributed digital identity (DID) needs to be explained as follows: In this system, all participating entities can independently generate and manage their own distributed digital identity (DID), without relying on a centralized third-party identity authority for registration and verification. This effectively reduces the cost of establishing mutual trust in cross-institutional and cross-domain data flow scenarios, while avoiding the single point of failure and identity information leakage risks inherent in centralized identity systems. This invention encrypts the original data and stores it in an off-chain encrypted storage network (IPFS). Only ownership-related metadata, signature information, and asset identifiers are written to the blockchain. This leverages the immutability of the blockchain to achieve reliable data ownership verification and traceability, while avoiding excessive on-chain storage resources due to large amounts of original data being uploaded to the chain, effectively balancing ownership reliability and system storage efficiency. Furthermore, this system combines verifiable credentials (VC) with ciphertext policy attribute-based encryption (CP-ABE) to achieve fine-grained control over access permissions. During the access process, multiple verifications are required, including DID identity validity, verifiable credential status, and access policy matching. Only after all verification steps are passed can the key ciphertext and storage address required for decryption be obtained, effectively reducing the risk of credential misuse and permission abuse. At the same time, all access requests and verification results generate audit logs for retention, supporting full traceability auditing by regulatory audit nodes and meeting the regulatory requirements for compliant circulation of data elements.

[0017] The system described in this embodiment provides a data element ownership confirmation and fine-grained access control system based on blockchain DID. This system includes a user and application layer, a business service layer, a smart contract layer, and a storage and ledger layer. The user and application layer includes the data owner (DO), data user (DC), credential issuer (Issuer), and regulatory auditor; the business service layer includes a cryptographic engine, a VC / VP management module, and a DID parser; the smart contract layer includes a DID management contract, a data ownership confirmation and storage contract, and an access control contract; the storage and ledger layer includes a blockchain network and an IPFS off-chain encrypted storage network. The modules are connected via data / control signals through transaction requests, DID parsing requests, credential verification requests, encrypted upload requests, and audit query requests.

[0018] The user and application layers are used to handle business initiation and result reception. Data owners (DOs) can initiate data registration requests through clients, business systems, or data catalog platforms, submitting data summaries, data descriptions, owner DIDs, and access policies; data users (DCs) can submit access requests, VPs, and random challenge signatures through application interfaces; credential issuers (Issuers) can verify the qualifications of entities and issue, update, or revoke VCs; regulatory auditors can query on-chain rights confirmation records, access records, and abnormal rejection records according to the authorized scope.

[0019] The business service layer shields the underlying cryptography and blockchain interaction complexities. The cryptographic engine includes at least a random number generation unit, a symmetric encryption unit, a hash calculation unit, a digital signature unit, a CP-ABE key generation unit, a key encapsulation unit, and a key decapsulation unit. The VC / VP management module stores credential templates, generates credential statements, verifies the issuer's signature, and checks the validity period and revocation status. The DID parser queries the on-chain DID document based on the DID, extracts the public key, server endpoint, and status identifier, and returns a standardized parsing result to the upper layer.

[0020] The smart contract layer is used to solidify identity status, ownership status, and authorization status into verifiable on-chain logic. The DID management contract must maintain at least the DID identifier, DID document hash, public key set, server endpoint, status field, and update time; the data ownership verification and notarization contract must maintain at least the AssetID, CID, owner DID, data digest, timestamp, signature, access policy digest, and asset status; and the access control contract must maintain at least the access request number, applicant DID, target AssetID, credential verification result, policy matching result, key ciphertext release status, and audit event.

[0021] The storage and ledger layers are responsible for recording trusted state and storing encrypted data, respectively. The blockchain network can be deployed as a consortium blockchain, with nodes jointly maintained by data providers, data users, credential issuers, regulators, or platform operators. An off-chain distributed storage network stores symmetrically encrypted encrypted data; any node that reads the encrypted data cannot recover the plaintext without obtaining the legitimate key. A mapping relationship is established between on-chain records and off-chain encrypted data through CIDs and digital signatures.

[0022] The DID management contract connects to the blockchain state database to receive registration, update, and deregistration requests and store DID document states. The data ownership verification and notarization contract connects to the DID parser, the blockchain state database, and the CID returned by IPFS, verifying the owner's signature, checking CID uniqueness, and generating an asset identifier (AssetID). The access control contract connects to the VC / VP management module, the DID parser, the revocation status record, and the key ciphertext record, verifying the VP, determining access policies, and controlling whether to release the symmetric key ciphertext encapsulated in CP-ABE. The cryptographic engine connects to the user terminal and performs key generation, AES encryption and decryption, ECDSA signature verification, CP-ABE key encapsulation and decapsulation.

[0023] When receiving a registration request, the DID management contract preferentially verifies whether the public key, DID identifier, and subject signature carried in the registration transaction are consistent. When receiving an update request, it preferentially verifies whether the requesting party holds the private key corresponding to the original DID or meets the preset recovery conditions. When receiving a deregistration request, it preferentially marks the DID status as unavailable rather than deleting the historical record to maintain audit continuity. After reading this status, the DID resolver can return a status such as valid, suspended, revoked, or expired to the access control contract.

[0024] When generating AssetID, the data ownership confirmation and storage contract preferably uses the owner's DID, CID, timestamp, and data metadata digest as input for hash calculation. This reduces the possibility of conflicts when different owners register the same CID or different versions of data by the same owner. The contract can also set logic such as CID uniqueness checks, owner signature verification, asset status transitions, duplicate registration alerts, and confirmation event broadcasting to ensure that registration activities are traceable and verifiable.

[0025] When executing access decisions, the access control contract preferably divides the process into five stages: credential authenticity verification, credential status verification, DID status verification, DID private key holding proof verification, and policy tree matching verification. If any stage fails, the contract does not release the key ciphertext and records the reason for rejection; if all stages pass, the contract only returns the off-chain ciphertext CID and the symmetric key ciphertext encapsulated by CP-ABE, without directly returning plaintext data or the plaintext key.

[0026] Participating entities generate elliptic curve public-private key pairs locally through a cryptographic engine, perform hash calculations on the public key in the elliptic curve public-private key pairs to generate DID identifiers, and construct DID documents based on the DID identifiers and public keys; Participating entities use the private key corresponding to the public key to digitally sign the DID document and submit the signed DID document to the DID management contract. After verifying the digital signature, the DID management contract anchors the DID document to the blockchain network. The credential issuing node generates an attribute private key based on the attribute set in the verifiable credential VC, and uses the signature proof generated by the public key of the corresponding DID to the random challenge as the key derivation factor or blinding factor of the attribute private key, so that the attribute private key and the corresponding DID private key are bound together.

[0027] The data symmetric key is a randomly generated 256-bit data symmetric key. The cryptographic engine uses the AES-256 algorithm to encrypt the original data using the data symmetric key. The IPFS off-chain encrypted storage network is a content-addressable IPFS distributed storage network. After the encrypted data is uploaded to the IPFS distributed storage network, it obtains an identifier (CID) corresponding to the encrypted data. The digital signature is generated using the ECDSA digital signature algorithm, and the verification object of the digital signature includes a combination of owner DID, identifier CID and timestamp information; The data ownership confirmation and storage contract performs a hash operation on the combination of owner DID, identifier CID and timestamp to generate AssetID, thereby establishing an on-chain ownership confirmation association between the content address of the encrypted data and the owner DID through AssetID.

[0028] The access strategy is an access strategy tree. The leaf nodes of the access strategy tree are the attribute conditions in the verifiable credential VC, and the internal nodes of the access strategy tree are AND logical nodes, OR logical nodes, or k / n threshold logical nodes. The cryptographic engine uses CP-ABE to encapsulate the data symmetric key according to the access policy tree to obtain the key ciphertext, and associates the key ciphertext with the corresponding AssetID. CP-ABE is used to encapsulate the data symmetric key, and the original data is symmetrically encrypted using the data symmetric key.

[0029] The access control contract is associated with the record of the revocation status of the verifiable credential (VC) and the record of the key ciphertext, respectively. The access control contract releases the CID and key ciphertext associated with the AssetID only when the signature verification of the credential issuer is successful, the verifiable credential VC is within its validity period, the verifiable credential VC has not been revoked, the DID corresponding to the data user terminal is in a valid state, the DID private key holding proof is verified, and the attribute set extracted from the VP satisfies the access policy tree. When a data user terminal performs CP-ABE decapsulation on the key ciphertext, it uses the attribute private key bound to its own DID and the corresponding DID private key to recover the data symmetric key. When an access control contract denies access, it writes the corresponding denial reason and access request information to the audit log.

[0030] Example 2 A method for data element ownership confirmation and fine-grained access control based on blockchain-based distributed digital identity (DID) is applied to the system; the method includes: S1. Configure blockchain nodes and off-chain distributed storage nodes, deploy DID management contracts, data ownership confirmation and storage contracts and access control contracts on blockchain nodes, and generate public parameters and master keys for ciphertext policy attribute base encryption CP-ABE; S2. Participating entities generate public-private key pairs locally, generate DID identifiers and construct DID documents based on the public key in the public-private key pair, digitally sign the DID documents using the private key corresponding to the public key, and submit the signed DID documents to the DID management contract. The DID management contract verifies the digital signature and anchors the verified DID documents to the blockchain node. S3. After verifying the entity qualifications of the participating entities, the credential issuing node issues a verifiable credential VC containing an attribute set, validity period and revocation identifier for the DID of the participating entities in step S2. Based on the CP-ABE master key, attribute set and private key holding certificate of the corresponding DID generated in step S1, an attribute private key bound to the DID is generated. S4. The data owner terminal generates a data symmetric key, uses the data symmetric key to symmetrically encrypt the original data to obtain the data ciphertext, uploads the data ciphertext to the off-chain distributed storage node to obtain the content identifier CID, and generates a digital signature for the identifier CID. S5. The data owner terminal submits the identifier CID obtained in step S4, along with the owner DID, timestamp, digital signature, and metadata of the data owner terminal, to the data ownership confirmation and storage contract. The data ownership confirmation and storage contract parses the DID document corresponding to the owner DID anchored in step S2 to obtain the public key, verifies the digital signature and the uniqueness of the identifier CID based on the public key, generates the asset identifier AssetID based on the owner DID, identifier CID, and timestamp, and writes the AssetID, identifier CID, owner DID, timestamp, digital signature, and asset status into the blockchain node. S6. The data owner terminal establishes an access policy for the AssetID generated in step S5, and encapsulates the data symmetric key generated in step S4 using CP-ABE according to the access policy to obtain the key ciphertext associated with the AssetID. S7. The data user submits a verifiable VP and DID random challenge signature for the AssetID generated in step S5. The access control contract verifies the VP and DID random challenge signature, extracts the attribute set from the verified VP, and determines whether the attribute set meets the access policy established in step S6. If the verification is successful and the attribute set meets the access policy, the identifier CID obtained in step S4 and the key ciphertext obtained in step S6 are returned to the data user. If the verification fails or the attribute set does not meet the access policy, the data user's access request is rejected and an audit log is generated. S8. The data user uses the attribute private key generated in step S3 and bound to its own DID to perform CP-ABE decapsulation on the key ciphertext returned in step S7 to recover the data symmetric key generated in step S4. Based on the identifier CID returned in step S7, the user obtains the data ciphertext from the off-chain distributed storage node and uses the recovered data symmetric key to decrypt the data ciphertext to obtain the original data.

[0031] In step S2, the public key generated by the participating entities is hashed to obtain the DID identifier; In step S3, the VC also includes the subject DID corresponding to the participating entity. The credential issuing node digitally signs the VC and, when generating the attribute private key, uses the public key of the corresponding DID or the signature proof generated by the corresponding DID for the random challenge as the key derivation factor or blinding factor, so that the generated attribute private key can only be used in conjunction with the private key of the corresponding DID to decapsulate the key ciphertext using CP-ABE.

[0032] In step S4, the data symmetric key is a 256-bit random data symmetric key, and the original data is symmetrically encrypted using the AES-256 algorithm. The off-chain distributed storage node is an IPFS node, and the digital signature is generated using the ECDSA digital signature algorithm. In step S5, a hash operation is performed on the combination of owner DID, identifier CID and timestamp to generate AssetID, so that owner DID, identifier CID representing the address of encrypted data content and timestamp are associated through AssetID, and neither the original data nor the encrypted data is written into the blockchain as the original data content.

[0033] In step S6, the access strategy is represented by an access strategy tree. The leaf nodes of the access strategy tree correspond to the attribute conditions in VC, and the internal nodes of the access strategy tree are AND logical nodes, OR logical nodes, or k / n threshold logical nodes. In step S7, the access control contract sequentially verifies the credential issuer signature corresponding to the VP, the VC validity period, the VC revocation status, the DID status corresponding to the data user, and the DID private key holding proof represented by the DID random challenge signature, and uses the attribute set extracted from the VP to match the access policy tree in step S6. Only when the credential issuer's signature, VC validity period, VC revocation status, DID status, and DID private key holding proof are all verified, and the attribute set satisfies the access policy tree, will the identifier CID and key ciphertext be returned to the data user.

[0034] In step S7, when any verification fails or the attribute set does not meet the access policy tree, the reason for the access denial and the corresponding access request information are written into the audit log. In step S8, the data user uses the attribute private key bound to its own DID and the corresponding DID private key to perform CP-ABE decapsulation on the key ciphertext, recover the data symmetric key, and obtain the data ciphertext from the IPFS node based on the identifier CID. The recovered data symmetric key is then used to perform AES decryption on the data ciphertext to obtain the original data. The regulatory audit node performs audit queries on access requests, access decision results, and reasons for access denial based on audit logs.

[0035] The steps outlined above require detailed explanation, particularly step S1, system initialization: configuring blockchain nodes, IPFS nodes, and three types of smart contracts, and generating CP-ABE public parameters. and the master key MSK.

[0036] System initialization also includes configuring call permissions, event names, status fields, error codes, and audit log formats for each contract. During blockchain network initialization, channels or namespaces corresponding to DID management, data ownership confirmation, and access control can be created, or business types can be distinguished by contract names within the same channel. CP-ABE public parameters are generated by a trusted initialization process and made public to system participants. The master key (MSK) is securely stored by the Issuer or threshold issuer set and is not written to the blockchain plaintext ledger.

[0037] During the initialization phase, VC attribute namespaces and access policy syntax can be predefined. For example, attributes can include organization type, business role, credit rating, regulatory permission, data usage purpose, geographic scope, and validity period; policy trees can be represented using AND, OR, k / n thresholds, and nested parentheses expressions. By using a unified attribute namespace, inconsistencies in policy interpretation caused by different organizations using different field names for the same attribute can be avoided.

[0038] Step S2, DID Registration: Participating entity i generates an elliptic curve public / private key pair locally. ,calculate Construct DID documents and use The signature is submitted to the DID management contract; after the contract verifies the signature, it anchors the DID document to the blockchain.

[0039] During the DID registration process, participating entities preferably generate public-private key pairs in a local trusted environment, without uploading the private key to the server or blockchain node. Entities generate a DID identifier based on the public key hash and construct a DID document containing authentication methods, public key materials, server endpoints, controller information, and state information. The registration transaction is signed by the entity's private key and submitted to the DID management contract. The contract verifies the signature to confirm that the submitter controls the public key, and then writes the DID document digest and state into the ledger.

[0040] If an entity needs to change its key or update its server endpoint, it can submit a DID update transaction. The update transaction must be signed with the original private key, or authorized by a preset recovery key, a multisignature controller, or a regulatory recovery process. This supports key rotation and business system migration while preventing attackers from maliciously taking over the DID. When a DID is revoked, the contract records the revocation time and reason, and retains the historical state for subsequent auditing.

[0041] Step S3, VC Issuance and Attribute Key Binding: Issuer issues the VC after verifying entity qualifications. (Validity period, cancellation mark), among which For a set of attributes; when the Issuer generates the attribute private key, it includes... Public key Alternatively, a random challenge signature proof can be used as a key derivation or blinding factor, ensuring that the attribute private key must be used in conjunction with the corresponding DID private key.

[0042] During the VC issuance phase, the Issuer first verifies the entity's true identity and attribute set based on offline qualification materials or existing business system data. Upon successful verification, the Issuer generates a VC containing a credential number, entity DID, attribute set, issuer DID, issuance time, validity period, revocation flag, and signature value. The VC can be stored locally by the entity, or in a credential wallet, institutional credential repository, or verifiable data warehouse; however, its integrity can be verified using the Issuer's public key.

[0043] To bind attribute keys to DIDs, Issuer uses the subject DID, public key, or random challenge signature proof as key derivation factors when generating attribute private keys. This ensures that the generated attribute private key cannot be used independently of the corresponding DID private key. Even if the same subject holds multiple VCs, or multiple subjects attempt to merge their attributes, they cannot bypass the DID private key holding proof to complete decryption, thus improving the anti-collusion capability of fine-grained authorization.

[0044] The VC revocation status can be maintained by the Issuer through on-chain revocation registration, off-chain verifiable status lists, or accumulators. During adjudication, the access control contract verifies not only the VC signature but also whether the credential is valid, whether it has been revoked, whether it matches the applicant's DID, and whether the VP was generated by the applicant for this random challenge, preventing the abuse of old credentials, duplicate credentials, or replay requests.

[0045] Step S4, Data Encryption and Off-Chain Storage: Data owner DO generates a 256-bit random symmetric key K, and calculates... and will Upload to IPFS to obtain CID; DO to During the data encryption and off-chain storage phase, the data owner can first perform format verification, sensitive field processing, and metadata extraction on the original data, and then the cryptographic engine generates a random symmetric key K. The original data M is encrypted using AES-256 or an algorithm of equivalent security strength to obtain the ciphertext Cdata. Since only the ciphertext is stored off-chain, even if the storage node is accessed without authorization, attackers cannot directly obtain the plaintext data.

[0046] After encrypted data is uploaded to IPFS or other content-addressed distributed storage networks, the storage network calculates a CID based on the encrypted content. The CID has a content fingerprint attribute; any change to the encrypted content will result in a change to the CID. The data owner then combines the CID, timestamp T, data digest, and necessary metadata digest, and signs it with their private key to form a non-repudiable claim of ownership. This signature proves that the registration request was indeed initiated by the corresponding DID controller.

[0047] Step S5, On-chain Rights Confirmation: DO Submission CID, timestamp ,sign And metadata. Data ownership confirmation and storage contract analysis. Obtain the public key, verify the uniqueness of the signature and CID, and calculate... It also writes the AssetID, CID, owner DID, timestamp, signature, and status to the ledger.

[0048] During the on-chain rights confirmation phase, the data rights confirmation and storage contract first calls the DID resolver to obtain the public key and status corresponding to the owner's DID. If the DID does not exist, has been revoked, or is in an unavailable state, the contract rejects the rights confirmation request; if the DID status is valid, the contract uses the parsed public key to verify the owner's signature. After the signature is verified, the contract further checks whether the CID has been registered, whether the asset status conflicts, and whether the metadata format meets the preset requirements.

[0049] The contract preferably calculates the AssetID based on the owner's DID, CID, timestamp, and metadata digest, and writes the AssetID as the key to the status database. This record can include the asset name, data type, data digest, CID, owner's DID, ownership confirmation time, signature value, policy digest, version number, and current status. The status can include registered, updated, frozen, revoked, etc., to support the full lifecycle management of data assets.

[0050] When the same data asset undergoes a version update, the data owner can submit a new CID and version relationship. The contract then associates the new AssetID with the original AssetID, thus preserving the data version evolution path. Regulatory auditors can use this to track the entire process of an asset from initial registration to authorized access, status changes, and revocation.

[0051] Step S6, Policy Formulation and Key Encapsulation: DO establishes an access policy tree T, with leaf nodes representing VC attribute conditions and internal nodes representing AND, OR, or k / n threshold nodes; K is encapsulated using CP-ABE to obtain... and will Associated with AssetID.

[0052] During the strategy formulation phase, the data owner constructs an access policy tree T based on data sensitivity levels, business purposes, regulatory requirements, and transaction conditions. Leaf nodes of the policy tree can be attribute conditions such as "Institution Type = Financial Institution," "Credit Rating = A," "Role = Auditor," "Purpose = Risk Assessment," and "Regulatory Permit = Valid." Internal nodes can be AND, OR, or k / n threshold nodes. This policy tree can express both strict conditions requiring multiple attributes to be met simultaneously and alternative authorization paths.

[0053] During the key encapsulation phase, the DO does not directly hand over the symmetric key K to the data user. Instead, it uses CP-ABE to encapsulate K with a policy tree T as the access policy, obtaining the key ciphertext CTK. CTK is stored in association with the AssetID and can be written to the on-chain state or stored off-chain with its digest written on-chain. Regardless of the storage method, only the user holding the attribute private key that satisfies the policy and has completed the DID binding verification can decapsulate and obtain K.

[0054] Step S7, Access Decision: The DC submits a random challenge signature for AssetID, VP, and DID. The access control contract verifies the Issuer signature, VC validity period, revocation status, DID status, and proof of private key holding, and extracts the attribute set. And calculate Only when And when all verifications pass, the contract returns the CID and Otherwise, access will be denied and written to the audit log.

[0055] During the access adjudication phase, the DC first generates a VP based on its own VC and signs the random challenge or transaction context provided by the access control contract to prove that it controls the DID private key consistent with the VC entity. The access request includes at least the AssetID, applicant DID, VP, random challenge signature, and necessary business purpose statement. The access control contract then reads the target asset's access policy, key encryption state, and asset status.

[0056] When executing a contract decision, the first step is to verify the correctness of the Issuer signature in the VP. Next, the validity period and revocation status of the VC are checked. Then, the applicant's DID is parsed, and the random challenge signature is verified. Once all identity and credential conditions are met, the contract extracts the attribute set ADC from the VC and calculates whether the policy tree T(ADC) holds true. If T(ADC) = 1 and the asset status allows access, the contract returns the CID and CTK; otherwise, the request is rejected and written to the audit log. The audit log includes at least the request number, applicant's DID, target AssetID, timestamp, failure stage, and error reason.

[0057] Step S8, Local Decryption: The DC executes the decryption using the attribute private key bound to its own DID. Then use K to pair IPFS Perform AES decryption to obtain the original data M.

[0058] During the local decryption phase, the DC first performs CP-ABE decryption using the attribute private key bound to its own DID to obtain the symmetric key K. This step requires the local DID private key to participate in deblinding or signature verification; therefore, a copied attribute private key or another party's VC cannot complete decryption independently. Subsequently, the DC downloads the encrypted data from IPFS based on the CID. The original data M is obtained by performing AES decryption using K. The decryption process is completed locally in the DC; blockchain nodes, storage nodes, and smart contracts do not access the plaintext data.

[0059] After a complete access is completed, the DC can submit an access completion event or data usage commitment to the blockchain. Regulatory auditors can also verify this based on on-chain request records, contract adjudication records, and asset status records. In the event of unauthorized access attempts, access with expired credentials, access with revoked credentials, or access with policy mismatch, the system can retain audit evidence without exposing the plaintext data.

[0060] By combining the owner's DID, CID, and timestamp in digital signature verification and AssetID generation, an inseparable ownership relationship is established between the off-chain encrypted content address and the on-chain ownership entity. This improvement avoids uploading the original data to the blockchain while preserving verifiable ownership evidence.

[0061] The essence of this key point lies in incorporating both "who owns the data" and "which data is stored off-chain" into the cryptographic proof. The CID is determined by the ciphertext content, the DID is controlled by the principal's public key, the timestamp reflects the point of ownership confirmation, and the digital signature proves the statement of non-repudiation. After all four are involved in the generation of the AssetID or ownership record, the replacement of any one of them will lead to verification failure, thereby preventing others from impersonating the CID to confirm ownership, tampering with the registration time, or replacing the owner's identity.

[0062] Compared to schemes that only record file hashes, this embodiment combines the file content address with DID identity status, signature, and contract verification processes, enabling the formation of a more complete chain of ownership evidence in cross-institutional scenarios. Data users and regulators do not need to trust a single platform database; they only need to verify on-chain records, DID documents, and signatures to confirm the relationship between the registered entity and the encrypted data.

[0063] The system binds the DID private key holding proof, the VC attribute set, and the CP-ABE attribute private key together. Visitors must not only possess a VC that meets the policy requirements, but also prove they control the corresponding DID private key and use the attribute private key bound to that DID to complete decryption, thus preventing credential theft and attribute collusion.

[0064] This key point addresses the issues of credential duplication and attribute collusion in fine-grained access control. A standard VC can prove that a subject has acquired certain attributes, but without binding to the decryption key, an attacker could intercept the VC's display or collect attribute private keys from multiple subjects to combine and satisfy a strategy. This embodiment requires the visitor to simultaneously meet the VC attribute conditions, the DID state validity condition, the DID private key possession condition, and the attribute private key binding condition; failure to meet any one of these conditions will prevent the recovery of the symmetric key.

[0065] In practice, DID private key holding proof can be accomplished using methods such as random challenge signature, transaction context signature, or hardware security module signature; attribute private key binding can be accomplished using key derivation, blinding, or access token binding methods based on DID, public key, or signature proof. These implementation methods differ, but all serve the same technical purpose, even though attribute capabilities cannot be independently transferred from the subject's identity.

[0066] Released by smart contracts Previously, the dynamic verification of VC signature, validity period, revocation status and policy tree matching results was used to move access control judgment from the central server to an automatic execution point on the chain, and write the failure reason and access flow into the audit log.

[0067] This key point enables access control to be automated, verifiable, and auditable. Traditional centralized server authorization decisions are typically completed internally, making it difficult for external organizations to verify the basis of those decisions. This embodiment embeds credential verification, revocation status checks, policy tree matching, and result recording into smart contracts. The contract execution process is guaranteed to be consistent by the blockchain consensus mechanism, and authorization results and reasons for failure can be traced afterward.

[0068] In regulatory audit scenarios, contract-recorded denial events are equally valuable. For example, if an entity attempts to access the system using an expired VC, or if an entity attempts to access the system despite having a revoked DID, the system can record the specific stages of the failure. Regulators can identify abnormal behavior patterns without viewing the plaintext data, thus achieving penetrating auditing while protecting privacy.

[0069] It employs a hybrid encryption structure that uses AES to encrypt the original data, IPFS to store the encrypted data, and CP-ABE to encapsulate the symmetric key. This structure balances the efficiency of large file encryption with fine-grained authorization capabilities, reducing on-chain storage and contract execution overhead.

[0070] This key point balances efficiency and security. AES is suitable for processing large volumes of raw data, reducing encryption and decryption computational overhead; content-addressed storage such as IPFS is suitable for storing large encrypted files, preventing the blockchain ledger from bloating; CP-ABE is suitable for protecting smaller symmetric keys, enforcing complex access policies at the key level. Therefore, this embodiment does not put all data directly on the blockchain, nor does it delegate all access control to a central server, but rather places different technologies in the most suitable positions.

[0071] The hybrid encryption structure also facilitates subsequent expansion. If the original data is small, the same process can be used directly for ciphertext storage; if the data is large, it can be fragmented for encryption, and a unified CID or list CID can be generated for the fragment set; if the data requires multi-level authorization, different policy trees can be configured for different keys or different data fragments. None of the above expansions change the basic concept of this embodiment, which controls access through on-chain authorization, off-chain ciphertext, and attribute keys.

[0072] This embodiment enables decentralized identity mutual recognition, tamper-proof data ownership verification, off-chain secure storage of raw data, and expression-level fine-grained access control. Since the raw data is not directly uploaded to the chain, only the CID, ownership digest, status, and key ciphertext are stored on the chain, which significantly reduces the ledger storage pressure compared to a fully on-chain solution.

[0073] Regarding data immutability, this embodiment utilizes the content addressing characteristics of IPFS and the immutable ledger of blockchain to form a dual guarantee. Once the off-chain encrypted text changes, the CID changes accordingly; once the on-chain record is confirmed, the correspondence between the owner's DID, CID, timestamp, and signature is difficult to modify unilaterally. Therefore, the system can prove that a certain subject has completed the registration of a certain encrypted content at a certain moment.

[0074] Regarding identity trust, this embodiment enables participating entities to prove their public key and identity status through DID documents, avoiding complete reliance on centralized account systems. The VC issued by the Issuer further binds real-world attributes such as institution type, credit rating, and regulatory approval to the DID, enabling access policies to be enforced based on real qualifications rather than just platform roles.

[0075] Regarding access control, this embodiment supports expression-level authorization, meaning that access policies can be composed of multiple attribute conditions combined through logical relationships. The system does not simply determine whether the applicant is on the list, but rather whether their valid set of VC attributes satisfies the policy tree defined by the data owner, releasing the encrypted key only after this condition is met. This mechanism enhances the flexibility and accuracy of authorization in an open environment.

[0076] From an engineering implementation perspective, the prototype in this embodiment adopts a deployment method combining consortium blockchain and off-chain storage. This allows identity status, rights confirmation digests, and access rulings to be stored on-chain, while the original encrypted data is stored off-chain. This structure avoids the storage and synchronization pressure caused by uploading all data to the blockchain, while still retaining verifiable evidence on-chain. The execution logic of the smart contract is relatively clear, mainly including signature verification, status query, policy matching, and event logging, facilitating migration across different consortium blockchain platforms.

[0077] From a security perspective, this embodiment can defend against many common attacks. For identity spoofing attacks, attackers cannot complete signature verification without possessing the DID private key; for data tampering attacks, changes to the ciphertext will cause changes to the CID and make it incompatible with the on-chain record; for credential duplication attacks, the VP and random challenge signature can prove that the applicant controls the DID private key; for attribute collusion attacks, the binding of the attribute private key to the DID makes it difficult to simply concatenate and use attributes from different entities.

[0078] CP-ABE achieves approximately 80ms end-to-end cryptographic overhead with N=30 policy attributes and approximately 125ms with N=50 attributes. Under normal load, the system's average acknowledgment latency is approximately 0.78 to 0.85s, while its throughput remains stable at approximately 750 TPS under high load. On-chain storage overhead is reduced by over 98% compared to a fully on-chain solution. These results demonstrate that this embodiment enhances security while possessing engineering deployment feasibility.

[0079] From an application perspective, this embodiment is suitable for scenarios requiring "data usable but not visible, and authorization verifiable and auditable." Data owners can complete ownership registration and authorization policy configuration without disclosing the original data; data users can obtain controlled decryption capabilities after meeting certain conditions; and regulatory auditors can verify ownership confirmation and access behavior through on-chain records. Compared to solutions that rely solely on a central platform, this embodiment improves credibility and traceability in cross-entity collaboration.

[0080] Furthermore, this embodiment supports full lifecycle management of data assets. Data registration, version updates, policy adjustments, access requests, authorization success, authorization failure, asset freezing, and asset revocation can all be recorded on the blockchain. This recording system can serve both internal security management and provide technical evidence for data transactions, compliance audits, and dispute resolution.

[0081] In practical deployment, this embodiment can also reduce system integration difficulty. For existing data platforms, the original data catalog, business approval, and data transmission processes can be retained, with the module of this invention only integrated at the stages of rights registration, certificate verification, key encapsulation, and audit records. For newly created data spaces, DID can be used directly as the main identifier, VC as the qualification carrier, and smart contracts as the unified authorization and adjudication entry point. Since plaintext data is never written to the blockchain, the system can both meet privacy protection requirements and enhance multi-party trust by leveraging the immutable records provided by the blockchain.

[0082] This embodiment also boasts strong compliance adaptability. Data owners can configure different access policies based on data classification and grading requirements, employing more lenient attribute conditions for general data and imposing additional conditions such as regulatory permission, usage restrictions, validity periods, and multiple issuer endorsements for sensitive data. Regulatory auditors can verify whether visitors possess the appropriate qualifications, whether authorizations are valid, and whether access has been revoked without accessing the plaintext, thus balancing data flow efficiency with security and regulatory requirements.

[0083] The data elements addressed in this embodiment include, but are not limited to, government data, healthcare data, financial risk control data, scientific research data, industrial equipment operation data, supply chain collaboration data, and other data assets that require cross-entity transfer, ownership confirmation, and controlled use. These data typically exhibit characteristics such as high value density, low replication costs, complex transfer paths, and ownership status that changes with business operations. Relying solely on traditional database records or platform internal logs makes it difficult to generate ownership certificates that can be jointly verified by multiple parties.

[0084] From a system architecture perspective, this invention can be deployed as an independent data ownership confirmation and access control platform, or used as a security foundation component for existing data trading platforms, data sharing and exchange platforms, industry data spaces, or enterprise data middleware. Each participating entity submits identity, ownership confirmation, authorization, and audit transactions to the blockchain network through terminals or business systems. Blockchain nodes maintain an immutable state ledger, off-chain distributed storage nodes store the encrypted original data, and the cryptographic computation module is responsible for performing operations such as symmetric encryption, digital signatures, attribute-based key encapsulation, and decapsulation.

[0085] In the above context, DID stands for Decentralized Identifier; VC stands for Verifiable Credential; VP stands for Verifiable Presentation; IPFS stands for InterPlanetary File System; and CP-ABE stands for Ciphertext-Policy-Attribute-Based Encryption.

[0086] In this embodiment, DID represents a decentralized identity identifier that can be autonomously controlled by the subject and can be parsed and verified on-chain; VC represents a verifiable credential after a trusted issuer digitally signs the subject's attributes, qualifications, or roles; VP represents a verifiable display that the subject selectively discloses and proves to hold a valid VC during an access request; IPFS represents a content-addressed off-chain distributed storage network; and CP-ABE represents an attribute-based encryption mechanism where the key decapsulation conditions are controlled by the access policy. These technologies are not used in isolation, but rather form a closed-loop binding relationship between identity, attributes, ownership, and keys in this embodiment.

[0087] Although embodiments of the invention have been shown and described, those skilled in the art will understand that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the claims and their equivalents.

Claims

1. A data element ownership confirmation and fine-grained access control system based on blockchain distributed digital identity (DID), characterized in that, The system includes a data owner terminal, a data user terminal, a credential issuance node, a regulatory audit node, a cryptographic engine, a verifiable credential / verifiable display management module, a DID parser, a blockchain network, and an IPFS off-chain encrypted storage network. DID management contracts, data ownership verification and storage contracts, and access control contracts are deployed on the blockchain network; The DID management contract is used to receive DID registration requests, update requests, or cancellation requests from participating entities, verify the DID documents submitted by participating entities, and write the status of the verified DID documents into the blockchain network. The data owner terminal is used to generate a data symmetric key through a cryptographic engine, use the data symmetric key to symmetrically encrypt the original data to obtain the data ciphertext, upload the data ciphertext to the IPFS off-chain ciphertext storage network to obtain the content identifier CID, and submit the ownership confirmation request including the owner DID, identifier CID, timestamp, digital signature and metadata to the data ownership confirmation and storage contract. The data ownership confirmation and storage contract is used to obtain the public key corresponding to the owner's DID through the DID parser, verify the digital signature based on the public key, verify the uniqueness of the identifier CID, generate the asset identifier AssetID based on the owner's DID, identifier CID and timestamp, and write the AssetID, identifier CID, owner's DID, timestamp, digital signature and asset status into the blockchain network. The credential issuance node is used to issue a verifiable credential VC containing a set of attributes, an expiration date, and a revocation identifier to the owner DID corresponding to the participating entity after verifying the entity's qualifications, and to generate an attribute private key that is bound to the corresponding DID's private key holding certificate; The data owner terminal is also used to establish access policies for the original data corresponding to AssetID, and to encapsulate the data symmetric key using ciphertext policy attribute base encryption CP-ABE through a cryptographic engine to obtain the key ciphertext associated with AssetID. The data user terminal is used to submit a verifiable random challenge signature that displays the VP and owner DID for the AssetID; The access control contract is used to verify the credential issuer signature, VC validity period, VC revocation status, DID status, and DID private key holding proof represented by the DID random challenge signature of the VP based on the verifiable credential / verifiable display management module and DID parser. It extracts the attribute set from the verified VP and determines whether the attribute set meets the access policy. When all verifications pass and the attribute set meets the access policy, it returns the identifier CID and key ciphertext to the data user terminal. When any verification fails or the attribute set does not meet the access policy, access is denied and an audit log is generated. The data user terminal is also used to decapsulate the key ciphertext using the attribute private key bound to its own DID to recover the data symmetric key, and to decrypt the data ciphertext obtained from the IPFS off-chain ciphertext storage network according to the identifier CID to obtain the original data. The regulatory audit node is used to audit and query the access requests and results of data user terminals based on audit logs.

2. The data element ownership confirmation and fine-grained access control system based on blockchain distributed digital identity (DID) according to claim 1, characterized in that, Participating entities generate elliptic curve public-private key pairs locally through a cryptographic engine, perform hash calculations on the public key in the elliptic curve public-private key pairs to generate DID identifiers, and construct DID documents based on the DID identifiers and public keys; Participating entities use the private key corresponding to the public key to digitally sign the DID document and submit the signed DID document to the DID management contract. After verifying the digital signature, the DID management contract anchors the DID document to the blockchain network. The credential issuing node generates an attribute private key based on the attribute set in the verifiable credential VC, and uses the signature proof generated by the public key of the corresponding DID to the random challenge as the key derivation factor or blinding factor of the attribute private key, so that the attribute private key and the corresponding DID private key are bound together.

3. The data element ownership confirmation and fine-grained access control system based on blockchain distributed digital identity (DID) according to claim 1, characterized in that, The data symmetric key is a randomly generated 256-bit data symmetric key. The cryptographic engine uses the AES-256 algorithm to encrypt the original data using the data symmetric key. The IPFS off-chain encrypted storage network is a content-addressable IPFS distributed storage network. After the encrypted data is uploaded to the IPFS distributed storage network, it obtains an identifier (CID) corresponding to the encrypted data. The digital signature is generated using the ECDSA digital signature algorithm, and the verification object of the digital signature includes a combination of owner DID, identifier CID and timestamp information; The data ownership confirmation and storage contract performs a hash operation on the combination of owner DID, identifier CID and timestamp to generate AssetID, thereby establishing an on-chain ownership confirmation association between the content address of the encrypted data and the owner DID through AssetID.

4. The data element ownership confirmation and fine-grained access control system based on blockchain distributed digital identity (DID) according to claim 1, characterized in that, The access strategy is an access strategy tree. The leaf nodes of the access strategy tree are the attribute conditions in the verifiable credential VC, and the internal nodes of the access strategy tree are AND logical nodes, OR logical nodes, or k / n threshold logical nodes. The cryptographic engine uses CP-ABE to encapsulate the data symmetric key according to the access policy tree to obtain the key ciphertext, and associates the key ciphertext with the corresponding AssetID. CP-ABE is used to encapsulate the data symmetric key, and the original data is symmetrically encrypted using the data symmetric key.

5. The data element ownership confirmation and fine-grained access control system based on blockchain distributed digital identity (DID) according to claim 4, characterized in that, The access control contract is associated with the record of the revocation status of the verifiable credential (VC) and the record of the key ciphertext, respectively. The access control contract releases the CID and key ciphertext associated with the AssetID only when the signature verification of the credential issuer is successful, the verifiable credential VC is within its validity period, the verifiable credential VC has not been revoked, the DID corresponding to the data user terminal is in a valid state, the DID private key holding proof is verified, and the attribute set extracted from the VP satisfies the access policy tree. When a data user terminal performs CP-ABE decapsulation on the key ciphertext, it uses the attribute private key bound to its own DID and the corresponding DID private key to recover the data symmetric key. When an access control contract denies access, it writes the corresponding denial reason and access request information to the audit log.

6. A method for data element ownership confirmation and fine-grained access control based on blockchain distributed digital identity (DID), applied to the system described in any one of claims 1 to 5; characterized in that, The method includes: S1. Configure blockchain nodes and off-chain distributed storage nodes, deploy DID management contracts, data ownership confirmation and storage contracts and access control contracts on blockchain nodes, and generate public parameters and master keys for ciphertext policy attribute base encryption CP-ABE; S2. Participating entities generate public-private key pairs locally, generate DID identifiers and construct DID documents based on the public key in the public-private key pair, digitally sign the DID documents using the private key corresponding to the public key, and submit the signed DID documents to the DID management contract. The DID management contract verifies the digital signature and anchors the verified DID documents to the blockchain node. S3. After verifying the entity qualifications of the participating entities, the credential issuing node issues a verifiable credential VC containing an attribute set, validity period and revocation identifier for the DID of the participating entities in step S2. Based on the CP-ABE master key, attribute set and private key holding certificate of the corresponding DID generated in step S1, an attribute private key bound to the DID is generated. S4. The data owner terminal generates a data symmetric key, uses the data symmetric key to symmetrically encrypt the original data to obtain the data ciphertext, uploads the data ciphertext to the off-chain distributed storage node to obtain the content identifier CID, and generates a digital signature for the identifier CID. S5. The data owner terminal submits the identifier CID obtained in step S4, along with the owner DID, timestamp, digital signature, and metadata of the data owner terminal, to the data ownership confirmation and storage contract. The data ownership confirmation and storage contract parses the DID document corresponding to the owner DID anchored in step S2 to obtain the public key, verifies the digital signature and the uniqueness of the identifier CID based on the public key, generates the asset identifier AssetID based on the owner DID, identifier CID, and timestamp, and writes the AssetID, identifier CID, owner DID, timestamp, digital signature, and asset status into the blockchain node. S6. The data owner terminal establishes an access policy for the AssetID generated in step S5, and encapsulates the data symmetric key generated in step S4 using CP-ABE according to the access policy to obtain the key ciphertext associated with the AssetID. S7. The data user submits a verifiable VP and DID random challenge signature for the AssetID generated in step S5. The access control contract verifies the VP and DID random challenge signature, extracts the attribute set from the verified VP, and determines whether the attribute set meets the access policy established in step S6. If the verification is successful and the attribute set meets the access policy, the identifier CID obtained in step S4 and the key ciphertext obtained in step S6 are returned to the data user. If the verification fails or the attribute set does not meet the access policy, the data user's access request is rejected and an audit log is generated. S8. The data user uses the attribute private key generated in step S3 and bound to its own DID to perform CP-ABE decapsulation on the key ciphertext returned in step S7 to recover the data symmetric key generated in step S4. Based on the identifier CID returned in step S7, the user obtains the data ciphertext from the off-chain distributed storage node and uses the recovered data symmetric key to decrypt the data ciphertext to obtain the original data.

7. The method for data element ownership confirmation and fine-grained access control based on blockchain distributed digital identity (DID) according to claim 6, characterized in that, In step S2, the public key generated by the participating entities is hashed to obtain the DID identifier; In step S3, the VC also includes the subject DID corresponding to the participating entity. The credential issuing node digitally signs the VC and, when generating the attribute private key, uses the public key of the corresponding DID or the signature proof generated by the corresponding DID for the random challenge as the key derivation factor or blinding factor, so that the generated attribute private key can only be used in conjunction with the private key of the corresponding DID to decapsulate the key ciphertext using CP-ABE.

8. The method for data element ownership confirmation and fine-grained access control based on blockchain distributed digital identity (DID) according to claim 6, characterized in that, In step S4, the data symmetric key is a 256-bit random data symmetric key, and the original data is symmetrically encrypted using the AES-256 algorithm. The off-chain distributed storage node is an IPFS node, and the digital signature is generated using the ECDSA digital signature algorithm. In step S5, a hash operation is performed on the combination of owner DID, identifier CID and timestamp to generate AssetID, so that owner DID, identifier CID representing the address of encrypted data content and timestamp are associated through AssetID, and neither the original data nor the encrypted data is written to the blockchain node as the original data content.

Images