Trusted data hosting method and device, equipment, storage medium and product

Abstract

The invention discloses a trusted data hosting method and device, equipment, a storage medium and a product, and relates to the technical field of blockchains, the method comprises the following steps: segmenting to-be-hosted data submitted by a data hosting party into data blocks, and carrying out error correction coding on the data blocks to obtain coded data blocks; encrypting the coded data block based on a private key corresponding to the decentralized identifier of the data hosting party, and constructing an encrypted Merkel tree; adding Merkel proof into the coded data block to generate an encrypted data block, and storing the encrypted data block into a trusted data storage cluster; and constructing metadata of the trusteeship data, and writing the metadata into the metadata block chain. The technical effects that encrypted storage and encrypted circulation of the data in a credible state are achieved, and the data demander can obtain corresponding original data after passing ownership verification are achieved, and the technical problem that the data demander is difficult to obtain the original data under the encryption condition is solved.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular, to a method, device, equipment, storage medium and product for trusted data hosting. Background Art

[0002] Currently, it is possible to implement the function of encrypted data circulation on the premise of privacy protection based on a data sandbox. In terms of data source management, a many-to-many access control policy is set with users / user groups, structured data resources, and unstructured data resources as the core elements. Based on the principle of least privilege, strict control is carried out on the access rights of data at the table level, row level, and field level. Full-life cycle logging is performed on all data encryption circulation operations of all users, while ensuring that the original data is not leaked and ensuring the normal progress of data encryption circulation. However, the data requester does not obtain the ownership of the data, but conducts data analysis and calculation in the data sandbox to obtain the data analysis results. Since the data requester does not truly obtain all the data, each data analysis and calculation requires an application and purchase of data usage rights. When not satisfied with the data analysis results, it is impossible to quickly view the original data, and the data encryption circulation lacks credibility and is not a real data element encryption circulation system.

[0003] The above content is only used to assist in understanding the technical solution of the present invention, and does not represent an admission that the above content is prior art. Summary of the Invention

[0004] The main purpose of this application is to provide a method, device, equipment, storage medium and product for trusted data hosting, aiming to solve the technical problem that it is difficult for data requesters to obtain original data in an encrypted situation in the prior art.

[0005] To achieve the above purpose, this application provides a method for trusted data hosting, and the method includes:

[0006] Obtain the data to be hosted submitted by the data host, divide the data to be hosted into corresponding data blocks, and perform error correction coding on the data blocks to obtain coded data blocks;

[0007] Based on a random number and the private key corresponding to the decentralized identifier of the data host, encrypt the coded data blocks and construct an encrypted Merkle tree;

[0008] Add the corresponding Merkle proof to the coded data blocks, generate encrypted data blocks, and store the encrypted data blocks in a trusted data storage cluster;

[0009] Construct the metadata of the escrowed data and write the metadata to the metadata blockchain. The metadata at least includes the hash data of the encrypted data block, the root of the encrypted Merkle tree, the random number commitment, the decentralized identifier of the data escrow party, the number of data blocks, and the data identifier.

[0010] In one embodiment, the step of encrypting the encoded data block based on the random number and the private key corresponding to the decentralized identifier of the data escrow party to construct the encrypted Merkle tree includes:

[0011] Generate a master key based on the random number and the private key corresponding to the decentralized identifier of the data escrow party;

[0012] Derive a key for the encoded data block from the master key based on the number of the encoded data block;

[0013] Encrypt the encoded data block based on the key of the encoded data block to obtain an initial encrypted data block;

[0014] Construct the encrypted Merkle tree based on the number of the initial encrypted data block.

[0015] In one embodiment, the step of storing the encrypted data block into the trusted data storage cluster includes:

[0016] Obtain the node information of the data nodes in the trusted data storage cluster, and calculate the logical distance between the encrypted data block and the data nodes;

[0017] Based on the logical distance between the encrypted data block and the data nodes, determine the target data node with the smallest logical distance, and write the encrypted data block to the corresponding target data node.

[0018] In one embodiment, the method further includes:

[0019] Receive the data identifier of the data to be retrieved and the data ownership proof submitted by the data escrow party. The data ownership proof is generated based on the data identifier of the data to be retrieved and the private key and public key corresponding to the decentralized identifier of the data escrow party;

[0020] Obtain the target metadata in the metadata blockchain based on the data identifier of the data to be retrieved;

[0021] Verify the data ownership proof based on the decentralized identifier in the target metadata and the data identifier of the data to be retrieved;

[0022] After the data ownership proof is verified, determine the target data block and the key of the target data block based on the target metadata;

[0023] Decrypt the target data block based on the key of the target data block to obtain the plaintext data;

[0024] Recover the data to be obtained based on the error correction code for the plaintext data, and return the data to be obtained to the data trustee.

[0025] In one embodiment, the step of determining the target data block and the key of the target data block based on the target metadata after the data ownership proof verification passes includes:

[0026] After the data ownership proof verification passes, read the initial target data block based on the hash data in the target metadata;

[0027] Verify the legality of the initial target data block based on the Merkle proof in the initial target data block and the tree root in the target metadata, and determine the target data block that passes the legality verification;

[0028] When the number of the target data blocks meets the number of data blocks in the target metadata, recover the target master key based on the private key corresponding to the decentralized identifier of the data trustee and the random number commitment in the target metadata;

[0029] Derive the key of the target data block based on the target master key.

[0030] In one embodiment, the method further includes:

[0031] When receiving an authorization request for the data to be authorized sent by another data user, return a randomly generated challenge value to the other data user;

[0032] Receive the authorization credential expression generated by the other data user, where the authorization credential expression at least includes the authorization credential sent by the data trustee, the challenge value, and the private key corresponding to the decentralized identifier of the other data user, and the authorization credential at least includes the data identifier of the data to be authorized, the decentralized identifier of the other data user, and the current master key;

[0033] Verify the authorization credential expression and the authorization credential in the authorization credential expression based on the public keys corresponding to the decentralized identifiers of the data trustee and the other data user;

[0034] After the authorization credential expression and the authorization credential are verified, read the current master key in the authorization credential and derive the key of the data block corresponding to the data to be authorized;

[0035] Read the to-be-authorized data based on the key corresponding to the data block of the to-be-authorized data, and send the to-be-authorized data to the other data users.

[0036] In addition, to achieve the above object, the present application also proposes a trusted data hosting device, which includes:

[0037] An encoding module, configured to obtain the to-be-hosted data submitted by the data host, split the to-be-hosted data into corresponding data blocks, and perform error correction encoding on the data blocks to obtain encoded data blocks;

[0038] An encryption module, configured to encrypt the encoded data blocks based on a random number and the private key corresponding to the decentralized identifier of the data host, and construct an encrypted Merkle tree;

[0039] The encryption module is further configured to add corresponding Merkle proofs to the encoded data blocks, generate encrypted data blocks, and store the encrypted data blocks in a trusted data storage cluster;

[0040] A hosting module, configured to construct metadata of the hosted data and write the metadata into a metadata blockchain, where the metadata at least includes hash data of the encrypted data blocks, the root of the encrypted Merkle tree, a random number commitment, the decentralized identifier of the data host, the number of data blocks, and data identifiers.

[0041] In addition, to achieve the above object, the present application also proposes a trusted data hosting device, which includes: a memory, a processor, and a computer program stored on the memory and executable on the processor, where the computer program is configured to implement the steps of the trusted data hosting method as described above.

[0042] In addition, to achieve the above object, the present invention also proposes a storage medium, which is a computer-readable storage medium, and a computer program is stored on the storage medium, and when the computer program is executed by a processor, the steps of the trusted data hosting method as described above are implemented.

[0043] In addition, to achieve the above object, the present application also provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, the steps of the trusted data hosting method as described above are implemented.

[0044] The present application provides a method for trusted data hosting. The method includes: obtaining the data to be hosted submitted by the data host, splitting the data to be hosted into corresponding data blocks, and performing error correction coding on the data blocks to obtain encoded data blocks; encrypting the encoded data blocks based on a random number and the private key corresponding to the decentralized identifier of the data host to construct an encrypted Merkle tree; adding corresponding Merkle proofs to the encoded data blocks to generate encrypted data blocks, and storing the encrypted data blocks in a trusted data storage cluster; constructing metadata of the hosted data and writing the metadata into a metadata blockchain, where the metadata at least includes the hash data of the encrypted data blocks, the root of the encrypted Merkle tree, the random number commitment, the decentralized identifier of the data host, the number of data blocks, and the data identifier. A trusted distributed file system is established by using the metadata blockchain and the trusted data storage cluster. At the same time, the user's original data is split into multiple data blocks with a redundant recovery mechanism by using error correction coding and organized into a Merkle tree. After each data block is encrypted respectively, verifiable data blocks are generated and stored in the trusted data storage cluster to ensure that the data is encrypted and stored in a trusted state, and the encrypted data has data ownership. Users who pass the verification can obtain the original data, solving the technical problem that it is difficult for data requesters to obtain the original data in an encrypted situation. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] The accompanying drawings are incorporated herein and form a part of this specification, showing embodiments consistent with the present application and, together with the specification, are used to explain the principles of the present application.

[0046] To more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the accompanying drawings required for use in the description of the embodiments or the prior art. Obviously, for those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0047] Figure 1 It is a schematic flowchart of Embodiment 1 of the trusted data hosting method of the present application;

[0048] Figure 2 It is a schematic diagram of the encrypted Merkle tree of the trusted data hosting method provided in Embodiment 1 of the present application;

[0049] Figure 3 It is a schematic diagram of node selection of the trusted data hosting method provided in Embodiment 1 of the present application;

[0050] Figure 4 It is a schematic flowchart of Embodiment 2 of the trusted data hosting method of the present application;

[0051] Figure 5 It is a schematic flowchart of Embodiment 3 of the trusted data hosting method of the present application;

[0052] Figure 6 Schematic diagram of authorization credentials for the trusted data hosting method provided in the third embodiment of this application;

[0053] Figure 7 Schematic representation diagram of authorization credentials for the trusted data hosting method provided in the third embodiment of this application;

[0054] Figure 8 Schematic diagram of the brief process of the trusted data hosting method provided in the third embodiment of this application;

[0055] Figure 9 Schematic diagram of the module structure of the trusted data hosting device in the embodiment of this application;

[0056] Figure 10 Schematic diagram of the device structure of the hardware operating environment involved in the trusted data hosting method in the embodiment of this application.

[0057] The realization, functional characteristics, and advantages of the purpose of this application will be further described with reference to the embodiments and the accompanying drawings. Detailed implementation manners

[0058] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of this application and are not used to limit this application.

[0059] To better understand the technical solutions of this application, the following will be described in detail in combination with the accompanying drawings of the specification and specific implementation manners.

[0060] The main solution of the embodiment of this application is: obtaining the data to be hosted submitted by the data host, splitting the data to be hosted into corresponding data blocks, and performing error correction coding on the data blocks to obtain encoded data blocks; encrypting the encoded data blocks based on a random number and the private key corresponding to the decentralized identifier of the data host to construct an encrypted Merkle tree; adding the corresponding Merkle proof to the encoded data blocks to generate encrypted data blocks, and storing the encrypted data blocks in a trusted data storage cluster; constructing metadata of the hosted data and writing the metadata into a metadata blockchain, where the metadata at least includes the hash data of the encrypted data blocks, the root of the encrypted Merkle tree, the random number commitment, the decentralized identifier of the data host, the number of data blocks, and the data identifier.

[0061] Currently, the data requester does not obtain the ownership of the data, but performs data analysis and calculation in a data sandbox to obtain the data analysis result. Since the data requester does not truly obtain all the data, each data analysis and calculation requires applying for and purchasing the data usage right. When not satisfied with the data analysis result, it is impossible to quickly view the original data, and the encrypted data circulation lacks credibility, which is not a real encrypted data element circulation system.

[0062] The present application provides a solution. A trusted distributed file system is established by using a metadata blockchain and a trusted data storage cluster. At the same time, the original user data is split into multiple data blocks with a redundant recovery mechanism by using error correction coding, and organized into a Merkle tree. After each data block is encrypted separately, a verifiable data block is generated and stored in the trusted data storage cluster to ensure the encrypted storage of the data. The encrypted data has data ownership, and users who pass the verification can obtain the original data, solving the technical problem that it is difficult for data demanders to obtain the original data in an encrypted situation.

[0063] It should be noted that the execution subject of this embodiment can be a computing service device with data processing, network communication, and program running functions, such as the controller of a trusted data hosting system. This embodiment does not make specific limitations on this. Hereinafter, taking the controller of the trusted data hosting system as an example, this embodiment and the following embodiments will be described.

[0064] An embodiment of the present application provides a trusted data hosting method. Refer to Figure 1 , Figure 1 which is a schematic flowchart of the first embodiment of the trusted data hosting method of the present application.

[0065] In this embodiment, the trusted data hosting method includes steps S10 to S40:

[0066] Step S10, obtain the data to be hosted submitted by the data host, split the data to be hosted into corresponding data blocks, and perform error correction coding on the data blocks to obtain encoded data blocks;

[0067] It should be noted that before data hosting, the trusted data hosting system needs to be initialized, and various system parameters are set. For example: the size K of the data blocks in the trusted data storage, the redundancy factor N of the error correction coding (Reed-Solomon coding). At the same time, each participating party (data host and other data users) applies to the DID (Data Identifier, decentralized identity) system for its unique digital identity, that is, the DID identifier (DID identifier), to ensure the credibility of each participating party's identity. Each DID identifier will correspond to a DID document (DID Document). The DID document includes the DID identifier, public key, private key, identity authentication, authorization, service endpoint, and timestamp. Among them, the private key sk DID and the public key PK DID can be used for authorization and authentication.

[0068] Additionally, it should be noted that the data to be entrusted, that is, the data that the data trustee needs to entrust, is usually submitted by the data trustee to the client. The data to be entrusted is divided into multiple data blocks according to the size K of the pre-set data blocks, and the number of data blocks is M. At this time, each data block can be denoted as

[0069] It can be understood that error correction coding is performed on the data blocks according to the set redundancy factor N. The error correction coding used in this embodiment is Reed-Solomon coding. Reed-Solomon coding can improve the reliability of data transmission. By adding redundant information to the data blocks, even if some data is lost or damaged, the original data can still be accurately restored. The encoded data blocks are the data blocks obtained after encoding. Since the redundancy factor is N, after Reed-Solomon coding, M + N encoded data blocks can be generated, denoted as

[0070] Step S20: Encrypt the encoded data blocks based on a random number and the private key corresponding to the decentralized identifier of the data trustee, and construct an encrypted Merkle tree;

[0071] In a feasible implementation manner, step S20 may include: generating a master key based on a random number and the private key corresponding to the decentralized identifier of the data trustee; performing key derivation on the master key based on the number of the encoded data block to generate the key of the encoded data block; encrypting the encoded data block based on the key of the encoded data block to obtain an initial encrypted data block; constructing the encrypted Merkle tree based on the number of the initial encrypted data block.

[0072] It should be noted that the private key corresponding to the decentralized identifier of the data trustee is the private key bound to the digital identity of the data trustee, that is, the private key sk corresponding to the DID DID .

[0073] It can be understood that a random number s is generated, and a master key m for data encryption is generated based on the public key PK DID of the data trustee and the random number s, and a key m i for encrypting each encoded data block is derived based on the number i of the encoded data block, i = 1, 2,..., M + N. The generated key m i is used to encrypt the encoded data block to generate a preliminary encrypted data block, that is, an initial encrypted data block.

[0074] Exemplarily, assume that the data trustee uses an elliptic curve group for encryption, the generator of the group is G, and the scalar field is F q (with order q), and the private key corresponding to its DID is sk DID , sk DID∈F q , the public key is PK DID = sk DID ·G, the data identifier is ID data , in F q select a random number s, s ∈ F q , calculate the commitment of s (i.e., the discrete logarithm on the elliptic curve group) S = s·G and SPK = s·PK DID , at the same time, save S in the metadata and destroy s. Calculate the master key m = Hash(SPK, ID data ) mod q, and derive the corresponding key for each encrypted data block, that is, the key for the i-th encrypted data block is m i = [m + HMAC(ID data , m, i)] mod q.

[0075] Step S30, add the corresponding Merkle proof to the encoded data block, generate an encrypted data block, and store the encrypted data block in the trusted data storage cluster;

[0076] It can be understood that the corresponding Merkle proof is added to each initial encrypted data block to obtain the final encrypted data block. Then find the storage node of the encrypted data block in the trusted data storage cluster and store the encrypted data block. Exemplarily, refer to Figure 2 , perform Reed - Solomon encoding on the data block to obtain the encoded data block Use the generated key m i to encrypt the encoded data block to generate the initial encrypted data block and construct a Merkle tree according to this number to form an encrypted Merkle tree. At this time, the root of the encrypted Merkle tree is Root B , and at the same time, add the corresponding Merkle proof to each initial encrypted data block to obtain the encrypted data block

[0077] In a feasible implementation manner, the step of storing the encrypted data block in the trusted data storage cluster includes: obtaining the node information of the data nodes in the trusted data storage cluster, and calculating the logical distance between the encrypted data block and the data nodes; based on the logical distance between the encrypted data block and the data nodes, determine the target data node with the smallest logical distance, and write the encrypted data block into the corresponding target data node.

[0078] It should be noted that read the list of data nodes in the trusted data storage cluster, and the node information of each data node is generated by calculating the hash, that is, NODE_ID i = Hash(NODE_INFOi ) Encrypted data block The logical distance between the encrypted data block and the data node is calculated using the following calculation formula:

[0079]

[0080] In the formula, D ij represents the encrypted data block and the logical distance between the data node NODE_ID j NODE_ID j represents the data node ID i , represents the encrypted data block 's hash data.

[0081] Additionally, it should be noted that consistent hashing is a hashing algorithm in a distributed system. By considering the hash value space as a ring and mapping data and nodes to this ring, when adding or removing nodes, only a small amount of data needs to be reallocated, which can greatly reduce the cost of data migration. At the same time, when nodes are added or removed, data only transfers between adjacent nodes, which can ensure the smooth expansion and high availability of the system.

[0082] It can be understood that the target data node is the node storing the encrypted data block, that is, the storage node of the encrypted data block. Referring to Figure 3 , NODE1, NODE2,..., NODE j are all data nodes. Calculate the logical distances D between the encrypted data block and these data nodes i1 , D i2 ,..., D ij . Based on the principle of consistent hashing, the data node with the smallest logical distance is used as the target data node of the encrypted data block . If the logical distance between the encrypted data block and the data node NODE1 is the smallest, then the target data node of the encrypted data block is NODE1.

[0083] Step S40, construct the metadata of the escrowed data and write the metadata into the metadata blockchain. The metadata at least includes the hash data of the encrypted data block, the root of the encrypted Merkle tree, the random number commitment, the decentralized identifier of the data escrower, the number of data blocks, and the data identifier.

[0084] It should be noted that the commitment of a random number is the commitment S of the random number s, where S = s·G and G is the generator. The data identifiers are organized in the form of a directory, for example: / dir1 / dir2 / … / DataName. The number of data blocks is the number of original data blocks, that is, the number of data blocks obtained by the initial division.

[0085] It can be understood that the metadata of the constructed escrow data includes at least the hash data of the encrypted data blocks The root Root of the encrypted Merkle tree B , the commitment S of the random number, the decentralized identifier DID of the data escrow party own , the number of data blocks M, and the data identifier ID data , in the following form:

[0086]

[0087] It should be understood that after writing the metadata into the metadata blockchain and after the block is confirmed, the relevant information in the controller is updated, and the data escrow party is notified of the completion of storage. The metadata is stored on the blockchain, supporting data anti-tampering verification and data redundancy recovery mechanisms.

[0088] This embodiment provides a trusted data escrow method, which obtains the data to be escrowed submitted by the data escrow party, divides the data to be escrowed into corresponding data blocks, and performs error correction coding on the data blocks to obtain encoded data blocks; encrypts the encoded data blocks based on a random number and the private key corresponding to the decentralized identifier of the data escrow party, and constructs an encrypted Merkle tree; adds the corresponding Merkle proof to the encoded data blocks to generate encrypted data blocks, and stores the encrypted data blocks in a trusted data storage cluster; constructs the metadata of the escrow data and writes the metadata into the metadata blockchain. The metadata includes at least the hash data of the encrypted data blocks, the root of the encrypted Merkle tree, the commitment of the random number, the decentralized identifier of the data escrow party, the number of data blocks, and the data identifier. A trusted distributed file system is established using the metadata blockchain and the trusted data storage cluster. At the same time, the user's original data is split into multiple data blocks with a redundancy recovery mechanism using error correction coding, and organized into a Merkle tree. After each data block is encrypted separately, verifiable data blocks are generated and stored in the trusted data storage cluster to ensure the encrypted storage of the data. The encrypted data has data ownership, and users who pass the verification can obtain the original data.

[0089] Based on the first embodiment of the present application, in the second embodiment of the present application, the same or similar content as in the above-mentioned first embodiment can be referred to the above introduction and will not be repeated hereinafter. On this basis, please refer to Figure 4 , after step S40, steps S501 to S506 may be included:

[0090] Step S501: Receive the data identifier of the data to be obtained and the data ownership certificate submitted by the data trustee.

[0091] It should be noted that the data to be obtained is the relevant data that the data trustee wants to obtain. The data trustee (i.e., the data owner) reads the data it has entrusted.

[0092] It can be understood that the data ownership certificate is generated based on the data identifier of the data to be obtained and the private key and public key corresponding to the decentralized identifier of the data trustee. The data trustee will use the public key and private key corresponding to the DID and the data identifier of the data to be obtained to generate a non-interactive SIGMA zero-knowledge proof, that is, the data ownership certificate, to prove its ownership of the data. The data identifier of the data to be obtained and the data ownership certificate are submitted by the data trustee to the trusted data trusteeship system through the client.

[0093] Exemplarily, assume that the data trustee uses an elliptic curve group for encryption The generator of the group is G, and the scalar field is F q (with order q), the private key corresponding to its DID is sk DID , sk DID ∈F q , and the public key is PK DID = sk DID ·G, the data identifier is ID data , and the request ID for data acquisition is ID req . Among them, ID req is different for each request, and it is put into the data ownership certificate to prevent replay attacks after the proof is intercepted by an attacker. Select a random number r on F q , r ∈ F q , calculate the commitment of r (i.e., the discrete logarithm on the elliptic curve group) R = r·G. According to the Fiat-Shamir principle, calculate the challenge value c = Hash(PK DID , R, ID data , ID req ) mod q, calculate the response z = (r + c·sk DID ) mod q, and serialize (R, z) to generate the data ownership certificate.

[0094] Step S502: Based on the data identifier of the data to be obtained, obtain the target metadata in the metadata blockchain.

[0095] It should be noted that at this time, according to the data identifier of the data to be obtained, the metadata information corresponding to the data to be obtained, that is, the target metadata, can be obtained in the metadata blockchain. The target metadata includes the corresponding hash data, tree root, random number commitment, decentralized identifier, number of data blocks, and data identifier.

[0096] Step S503: Verify the data ownership proof based on the decentralized identifier in the target metadata and the data identifier of the data to be retrieved.

[0097] It should be noted that by using the decentralized identifier in the target metadata, the public key associated with the DID can be obtained, that is, the associated public key PK. DID . Use the associated public key PK DID Combine with the data identifier to verify the data ownership proof, so as to confirm the data trustee's ownership of the data.

[0098] In a specific implementation, obtain ID data , ID req , (R, z) from the request, and deserialize (R, z). According to the identifier ID data of the data to be retrieved, obtain its corresponding target metadata, and find the DID of its owner, that is, the data trustee. Obtain its public key PK DID in the DID system according to the DID of the data trustee, and calculate the challenge value c = Hash(PK DID , R, ID data , ID req ) mod q. Verify whether the equation z·G == R + c·PK DID holds. If the equation holds, it means that the data trustee has the data ownership and the verification passes.

[0099] Step S504: After the data ownership proof is verified, determine the target data block and the key of the target data block based on the target metadata.

[0100] In a feasible implementation manner, step S504 includes: after the data ownership proof is verified, read the initial target data block based on the hash data in the target metadata; verify the legality of the initial target data block based on the Merkle proof in the initial target data block and the root of the tree in the target metadata, and determine the target data block that passes the legality verification; when the number of the target data blocks meets the number of data blocks in the target metadata, recover the target master key based on the private key corresponding to the decentralized identifier of the data trustee and the random number commitment in the target metadata; derive the key of the target data block based on the target master key.

[0101] It should be noted that if the verification is passed, it indicates that the data trustee has the ownership of the data to be obtained, and the data to be obtained can be returned to the data trustee. Read the hash data in the target metadata, calculate the logical distance between the data node and the data block where the data to be obtained is located by using the hash data, and find the node with the smallest logical distance, that is, the target acquisition node. The data block where the data to be obtained is located exists in the data blocks stored in the target acquisition node. Since there may be data blocks corresponding to other data in the target acquisition node, all the data blocks of this node are used as the initial target data blocks, and after further judgment, the final target data blocks are determined.

[0102] It can be understood that an initial target data block is read from the target acquisition node Use the Merkle proof in the initial target data block and the root Root in the target metadata B , to verify the legality of the initial target data block. If the verification is passed, the initial target data block is considered as the target data block. After collecting any M target data blocks, the target data blocks are packaged and sent to the client. Use the private key sk of the data trustee DID and the random number commitment S in the target metadata to recover the encrypted master key m, that is, the target master key, and derive the key m of each target data block i .

[0103] Exemplarily, the data trustee recovers the target master key based on its private key sk DID and the random number commitment S in the target metadata, and the calculation formula is as follows:

[0104] m = Hash(SPK,ID data ) mod q = Hash(s·PK DID ,ID data ) mod q

[0105] = Hash(s·sk DID ·G,ID data ) mod q

[0106] = Hash(sk DID ·S,ID data ) mod q

[0107] In the formula, m is the recovered target master key, q is the order of the scalar field F q , ID data is the data identifier of the data to be obtained, sk DID is the private key of the data trustee, and S is the random number commitment in the target metadata. Furthermore, the key m of each target data block is derived i = [m + HMAC(ID data , m, i)] mod q.

[0108] Step S505: Decrypt the target data block based on the key of the target data block to obtain plaintext data;

[0109] It can be understood that by using the key m of each target data block i , the plaintext data of the target data block can be decrypted

[0110] Step S506: Recover the plaintext data based on the error correction coding to obtain the data to be acquired, and return the data to be acquired to the data trustee.

[0111] It can be understood that the plaintext data of M target data blocks is used to recover the original data by using Reed-Solomon coding, so as to obtain the data to be acquired required by the data trustee, and then return it to the data trustee.

[0112] This embodiment provides a trusted data trusteeship method, which receives the data identifier of the data to be acquired submitted by the data trustee and the data ownership proof. The data ownership proof is generated based on the data identifier of the data to be acquired and the private key and public key corresponding to the decentralized identifier of the data trustee; based on the data identifier of the data to be acquired, obtain the target metadata in the metadata blockchain; based on the decentralized identifier in the target metadata and the data identifier of the data to be acquired, verify the data ownership proof; after the data ownership proof is verified, determine the target data block and the key of the target data block based on the target metadata; decrypt the target data block based on the key of the target data block to obtain plaintext data; recover the plaintext data based on the error correction coding to obtain the data to be acquired, and return the data to be acquired to the data trustee. The data user applies for using the data with the data identifier and zero-knowledge proof. After verifying the usage permission of the data user's DID, the data is decrypted, and the trusted node sends the original data to the data user, which can ensure that the data is encrypted and stored, the encrypted data has data ownership, and the verified user can obtain the original data.

[0113] Based on the above embodiments of the present application, in the third embodiment of the present application, the same or similar content as the above embodiments can be referred to the above introduction and will not be repeated hereinafter. On this basis, please refer to Figure 5 , after step S40, steps S501' to S505' may be included:

[0114] Step S501': When receiving an authorization request for the data to be authorized sent by other data users, return a randomly generated challenge value to the other data users;

[0115] It should be noted that other data users refer to the participants who need to use the data hosted by the data trustee except the data trustee. The data to be authorized refers to the data that other data users want to obtain and requires authorization from the data trustee. The data trustee (i.e., the data owner) authorizes the data it has hosted to other data users.

[0116] It can be understood that other data users send an authorization request through the client. After receiving the authorization request, the controller of the trusted data trusteeship system will return a randomly generated challenge value e to other data users.

[0117] Step S502', receive the authorization credential presentation generated by the other data user;

[0118] It can be understood that other data users generate an authorization credential presentation (Verifiable Presentation, VP) based on the authorization credential (Verifiable Credentials, VC), the returned challenge value e, and their own private key, and send it to the controller of the trusted data trusteeship system.

[0119] It should be noted that the authorization credential presentation at least includes the authorization credential sent by the data trustee, the challenge value, and the private key corresponding to the decentralized identifier of the other data user. The authorization credential at least includes the data identifier of the data to be authorized, the decentralized identifier of the other data user, and the current master key.

[0120] It should be understood that if other data users want to obtain data, they need to first obtain the authorization credential VC generated by the data trustee based on the DID. Exemplarily, let the private key of the data trustee be sk DID , the public key be PK DID , the DID be DID own ; the private key of the other data user be sk' DID , the public key be PK' DID , the DID be DID use , the data identifier of the data to be authorized be ID data . The data trustee obtains the metadata of the data to be authorized, obtains the random number commitment S therein, and generates the current master key m = Hash(sk DID ·S, ID data ) mod q. Refer to Figure 6 , the data trustee encapsulates the current master key m, the data identifier ID data , the root Root of the encrypted Merkle tree in the metadata B , the DID of the other data user use to generate a credential Merkle tree, and for the root Root of the credential Merkle tree VCSign them and assemble this information into an authorization credential VC. The data trustee sends the generated authorization credential VC to other data users.

[0121] It can be understood that other data users generate an authorization credential presentation VP based on the authorization credential VC and send it to the system for authorization verification. Exemplarily, let the private key of the data trustee be sk DID , and the public key be PK DID , and the DID be DID own ; the private key of other data users is sk′ DID , the public key is PK′ DID , and the DID is DID use , and the data identifier of the data to be authorized is ID data . Other data users send an authorization request for the data to be authorized to the system, and the controller returns a random number e as the challenge value for generating the VP. Refer to Figure 7 , other data users generate a verifiable VP based on the VC and the challenge value e, where the current master key m in the VC is privacy data and is replaced with the hash value Hash(m). Due to the characteristics of the Merkle tree, this operation does not affect the VC validity verification. Sign the VC and e and assemble them into the VP. Send the VP to the trusted data trustee system through the authorization request.

[0122] In a specific implementation, the data trustee reads the metadata of the data to be authorized in the metadata blockchain through the client, uses its own private key and the random number commitment S in the metadata to generate the current master key m, and generates an authorization credential based on the data identifier of the data to be authorized, the DID of other data users, and the current master key m, and sends it to other data users.

[0123] Step S503', verify the authorization credential presentation and the authorization credential in the authorization credential presentation based on the public keys corresponding to the decentralized identifiers of the data trustee and the other data users;

[0124] It should be noted that the system controller reads the data identifier ID data and the DID of the authorized party (i.e., other data users), i.e., DID use in the authorization credential presentation VP, and uses the data identifier ID data to read the DID of the data owner (i.e., the data trustee) in the metadata blockchain, i.e., DID own .

[0125] It can be understood that the system controller obtains the public key PK own corresponding to the DID DID , and the public key PK′ own corresponding to the DID DID, that is, obtain the public keys of the data trustee and other data users through the DID system, verify the received VP and the VC contained in the VP, so as to verify the permissions of other data users.

[0126] When verifying the Verifiable Presentation VP and Verifiable Credential VC of the authorization credential, use the PK DID Verify the signature of the VC in the VP and verify the PK DID , Root B , DID use , Hash(m) and the corresponding relationship with Root VC , use the PK' DID Verify the signature of the VP, verify whether the challenge value e in the VP is consistent with that sent by the data trustee system to other data users. If all the above verifications are successful, the VP and VC are verified successfully. At this time, the data to be authorized can be sent to other data users.

[0127] Step S504', after the Verifiable Presentation and the Verifiable Credential are verified, read the current master key in the Verifiable Credential and derive the key for the data block corresponding to the data to be authorized;

[0128] It can be understood that after the permissions are verified, the system controller reads the master key m in the VC and derives the keys m1, m2,..., m of each data block M+N .

[0129] Step S505', based on the key of the data block corresponding to the data to be authorized, read the data to be authorized and send the data to be authorized to the other data user.

[0130] It can be understood that using the derived keys m1, m2,..., m M+N , decrypt the corresponding data block plaintext, and use Reed-Solomon coding to recover the original data to obtain the data to be authorized, and return it to other data users.

[0131] This embodiment provides a trusted data hosting method. When receiving an authorization request for data to be authorized sent by other data users, a randomly generated challenge value is returned to the other data users; receive the authorization credential expression generated by other data users. The authorization credential expression at least includes the authorization credential sent by the data host, the challenge value, and the private key corresponding to the decentralized identifier of other data users. The authorization credential at least includes the data identifier of the data to be authorized, the decentralized identifier of other data users, and the current master key; based on the public keys corresponding to the decentralized identifiers of the data host and other data users, verify the authorization credential expression and the authorization credential in the authorization credential expression; after the authorization credential expression and the authorization credential are verified, read the current master key in the authorization credential, and derive the key corresponding to the data block of the data to be authorized; based on the key corresponding to the data block of the data to be authorized, read the data to be authorized, and send the data to be authorized to other data users. Data users apply for data using the data identifier and the data authorization credential, decrypt the data after verifying the usage rights of the data user's DID, and the trusted node sends the original data to the data user, which can ensure that the data is encrypted and stored, the encrypted data has data ownership, and the verified user can obtain the original data.

[0132] Exemplarily, to help understand the implementation process of the trusted data hosting method obtained by combining this embodiment with the above Embodiment 3, please refer to Figure 8 , Figure 8 which provides an overall architecture diagram of a trusted data hosting method. Specifically:

[0133] The overall architecture includes parts such as a data host, other data users, a DID system, a system controller, a client, a metadata blockchain, and a trusted data storage cluster. Data host: The party that provides data and stores the data in the data hosting system in this proposal. The data host is the owner of the data and can authorize other users. Other data users: The parties that obtain authorization and use the data, not the data owners. Client: The application and interface for users to operate. System controller: Responsible for request processing and module coordination of the trusted data hosting system, and manages and maintains data nodes. DID system: A digital identity system that provides the generation and verification of identities and credentials for each party, and is used for authorization and authentication of hosted data. Metadata blockchain: Stores the meta-information related to the hosted data (including directory, owner DID, data hash, etc.). Trusted data storage cluster: A data storage cluster composed of multiple server nodes, and organizes the data into a directory-based file system. When storing, the file is split into data blocks of the same size and stored in different server nodes, and the data blocks are organized in the form of a Merkle tree. The data-related meta-information is stored on the blockchain, supporting data anti-tampering verification and data redundancy recovery mechanisms.

[0134] It should be noted that the above examples are only for understanding the present application and do not constitute a limitation on the trusted data hosting method of the present application. Based on this technical concept, more forms of simple transformations are within the protection scope of the present application.

[0135] The present application also provides a trusted data hosting device. Please refer to Figure 9 , the trusted data hosting device includes:

[0136] An encoding module 10, configured to obtain the data to be hosted submitted by the data host, split the data to be hosted into corresponding data blocks, and perform error correction encoding on the data blocks to obtain encoded data blocks;

[0137] An encryption module 20, configured to encrypt the encoded data blocks based on a random number and the private key corresponding to the decentralized identifier of the data host, and construct an encrypted Merkle tree;

[0138] The encryption module 20 is further configured to add corresponding Merkle proofs to the encoded data blocks, generate encrypted data blocks, and store the encrypted data blocks in a trusted data storage cluster;

[0139] A hosting module 30, configured to construct metadata of the hosted data and write the metadata into a metadata blockchain. The metadata at least includes hash data of the encrypted data blocks, the root of the encrypted Merkle tree, a random number commitment, the decentralized identifier of the data host, the number of data blocks, and data identifiers.

[0140] In a feasible implementation manner, the encryption module 20 is further configured to generate a master key based on a random number and the private key corresponding to the decentralized identifier of the data host;

[0141] Derive a key of the encoded data block from the master key based on the number of the encoded data block;

[0142] Encrypt the encoded data block based on the key of the encoded data block to obtain an initial encrypted data block;

[0143] Construct the encrypted Merkle tree based on the number of the initial encrypted data block.

[0144] In a feasible implementation manner, the encryption module 20 is further configured to obtain node information of data nodes in the trusted data storage cluster and calculate a logical distance between the encrypted data block and the data node;

[0145] Based on the logical distance between the encrypted data block and the data node, determine a target data node with the smallest logical distance, and write the encrypted data block into the corresponding target data node.

[0146] In a feasible implementation manner, the hosting module 30 is further configured to receive the data identifier of the data to be obtained and the data ownership proof submitted by the data trustee, where the data ownership proof is generated based on the data identifier of the data to be obtained and the private key and public key corresponding to the decentralized identifier of the data trustee;

[0147] Based on the data identifier of the data to be obtained, obtain the target metadata in the metadata blockchain;

[0148] Based on the decentralized identifier in the target metadata and the data identifier of the data to be obtained, verify the data ownership proof;

[0149] After the verification of the data ownership proof passes, determine the target data block and the key of the target data block based on the target metadata;

[0150] Based on the key of the target data block, decrypt the target data block to obtain the plaintext data;

[0151] Based on the error correction coding, recover the plaintext data to obtain the data to be obtained, and return the data to be obtained to the data trustee.

[0152] In a feasible implementation manner, the hosting module 30 is further configured to, after the verification of the data ownership proof passes, read the initial target data block based on the hash data in the target metadata;

[0153] Based on the Merkle proof in the initial target data block and the tree root in the target metadata, perform a legality verification on the initial target data block to determine the target data block that passes the legality verification;

[0154] When the number of the target data blocks meets the number of data blocks in the target metadata, recover the target master key based on the private key corresponding to the decentralized identifier of the data trustee and the random number commitment in the target metadata;

[0155] Derive the key of the target data block based on the target master key.

[0156] In a feasible implementation manner, the hosting module 30 is further configured to, when receiving an authorization request for the data to be authorized sent by another data user, return a randomly generated challenge value to the other data user;

[0157] Receive the authorization credential expression generated by the other data user. The authorization credential expression at least includes the authorization credential sent by the data trustee, the challenge value, and the private key corresponding to the decentralized identifier of the other data user. The authorization credential at least includes the data identifier of the data to be authorized, the decentralized identifier of the other data user, and the current master key;

[0158] Based on the public key corresponding to the decentralized identifier of the data trustee and the other data user, verify the authorization credential expression and the authorization credential in the authorization credential expression;

[0159] After the authorization credential expression and the authorization credential pass the verification, read the current master key in the authorization credential and derive the key for the data block corresponding to the data to be authorized;

[0160] Based on the key for the data block corresponding to the data to be authorized, read the data to be authorized and send the data to be authorized to the other data user.

[0161] The trusted data trusteeship device provided in this application adopts the trusted data trusteeship method in the above embodiment, and can solve the technical problem that it is difficult for data demanders to obtain original data in an encrypted situation. Compared with the prior art, the beneficial effects of the trusted data trusteeship device provided in this application are the same as those of the trusted data trusteeship method provided in the above embodiment, and other technical features in the trusted data trusteeship device are the same as those disclosed in the method of the above embodiment, and will not be elaborated here.

[0162] This application provides a trusted data trusteeship device. The trusted data trusteeship device includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein, the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the trusted data trusteeship method in the first embodiment above.

[0163] Refer to the following Figure 10 , which shows a schematic structural diagram of a trusted data trusteeship device suitable for implementing the embodiments of the present application. The trusted data trusteeship device in the embodiments of the present application may include, but is not limited to, mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions: tablet computers), PMPs (Portable Media Players), in-vehicle terminals (such as in-vehicle navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 10The illustrated trusted data hosting device is merely an example and should not impose any limitations on the functions and usage scope of the embodiments of this application.

[0164] As Figure 10 shown, the trusted data hosting device may include a processing device 1001 (such as a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM: Read Only Memory) 1002 or the program loaded from the storage device 1003 into the random access memory (RAM: Random Access Memory) 1004. In the RAM 1004, various programs and data required for the operation of the trusted data hosting device are also stored. The processing device 1001, the ROM 1002, and the RAM 1004 are connected to each other through a bus 1005. The input / output (I / O) interface 1006 is also connected to the bus. Generally, the following systems may be connected to the I / O interface 1006: an input device 1007 including, for example, a touch screen, a touch pad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; an output device 1008 including, for example, a liquid crystal display (LCD: Liquid Crystal Display), a speaker, a vibrator, etc.; a storage device 1003 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 1009. The communication device 1009 can allow the trusted data hosting device to communicate with other devices wirelessly or wiredly to exchange data. Although the figure shows a trusted data hosting device with various systems, it should be understood that it is not required to implement or have all the shown systems. Instead, more or fewer systems may be implemented or had.

[0165] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, the embodiments disclosed in this application include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program contains program codes for executing the methods shown in the flowcharts. In such an embodiment, the computer program can be downloaded and installed from the network through the communication device, or installed from the storage device 1003, or installed from the ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the methods of the embodiments disclosed in this application are executed.

[0166] The trusted data hosting device provided by this application adopts the trusted data hosting method in the above embodiments, which can solve the technical problem that it is difficult for data requesters to obtain the original data in an encrypted situation. Compared with the prior art, the beneficial effects of the trusted data hosting device provided by this application are the same as those of the trusted data hosting method provided by the above embodiments, and other technical features in this trusted data hosting device are the same as those disclosed in the method of the previous embodiment, which will not be elaborated here.

[0167] It should be understood that each part disclosed in this application can be implemented by hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in a suitable manner in any one or more embodiments or examples.

[0168] The above are only the specific implementation manners of this application, but the protection scope of this application is not limited thereto. Any person skilled in the art can easily think of changes or substitutions within the technical scope disclosed in this application, and all should be covered by the protection scope of this application. Therefore, the protection scope of this application should be subject to the protection scope of the claims.

[0169] This application provides a computer-readable storage medium with computer-readable program instructions (i.e., computer programs) stored thereon, and the computer-readable program instructions are used to execute the trusted data hosting method in the above embodiments.

[0170] The computer-readable storage medium provided by this application can be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination of the above. More specific examples of computer-readable storage media can include, but are not limited to: electrical connections with one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM) or flash memory, optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the above. In this embodiment, the computer-readable storage medium can be any tangible medium that contains or stores a program, and this program can be used by or combined with an instruction execution system, device, or device. The program code contained on the computer-readable storage medium can be transmitted by any appropriate medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination of the above.

[0171] The above-mentioned computer-readable storage medium may be included in a trusted data hosting device; or it may exist independently without being assembled into the trusted data hosting device.

[0172] The above-mentioned computer-readable storage medium carries one or more programs. When the above-mentioned one or more programs are executed by the trusted data hosting device, the trusted data hosting device is caused to: obtain the data to be hosted submitted by the data host, split the data to be hosted into corresponding data blocks, and perform error correction coding on the data blocks to obtain encoded data blocks; encrypt the encoded data blocks based on a random number and the private key corresponding to the decentralized identifier of the data host, and construct an encrypted Merkle tree; add the corresponding Merkle proof to the encoded data blocks, generate encrypted data blocks, and store the encrypted data blocks in the trusted data storage cluster; construct metadata of the hosted data and write the metadata into the metadata blockchain.

[0173] Computer program code for performing the operations of this application can be written in one or more programming languages or combinations thereof. The above-mentioned programming languages include object-oriented programming languages - such as Java, Smalltalk, C++; and also include conventional procedural programming languages - such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, executed as an independent software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer can be connected to the user's computer through any type of network - including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computer (for example, by using an Internet service provider to connect through the Internet).

[0174] The flowcharts and block diagrams in the accompanying drawings illustrate the possible architectures, functions, and operations of systems, methods, and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagram may represent a module, a segment of a program, or a part of code that contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than that marked in the accompanying drawings. For example, two consecutive blocks shown may actually be executed substantially in parallel, and they may sometimes be executed in the reverse order, depending on the functions involved. It should also be noted that each block in the block diagram and / or flowchart, as well as combinations of blocks in the block diagram and / or flowchart, may be implemented by a dedicated hardware-based system that performs the specified functions or operations, or may be implemented by a combination of dedicated hardware and computer instructions.

[0175] The modules described in the embodiments of the present application can be implemented in software or in hardware. In some cases, the name of the module does not constitute a limitation on the unit itself.

[0176] The readable storage medium provided by the present application is a computer-readable storage medium that stores computer-readable program instructions (i.e., computer programs) for executing the above-mentioned trusted data hosting method, and can solve the technical problem that it is difficult for data requesters to obtain original data in an encrypted situation. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided by the present application are the same as those of the trusted data hosting method provided by the above embodiments, and will not be elaborated here.

[0177] The present application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the trusted data hosting method as described above.

[0178] The computer program product provided by the present application can solve the technical problem that it is difficult for data requesters to obtain original data in an encrypted situation. Compared with the prior art, the beneficial effects of the computer program product provided by the present application are the same as those of the trusted data hosting method provided by the above embodiments, and will not be elaborated here.

[0179] The above are only some embodiments of the present application, and do not limit the patent scope of the present application. Any equivalent structural transformation made under the technical concept of the present application by using the content of the specification and drawings of the present application, or any direct / indirect application in other related technical fields, is included in the patent protection scope of the present application.

Claims

1. A trusted data hosting method, characterized in that, The method described above includes: Obtain the data to be escrowed submitted by the data escrow party, split the data to be escrowed into corresponding data blocks, and perform error correction coding on the data blocks to obtain encoded data blocks; Based on a random number and the private key corresponding to the decentralized identifier of the data escrow party, encrypt the encoded data blocks and construct an encrypted Merkle tree; Add corresponding Merkle proofs to the encoded data blocks, generate encrypted data blocks, and store the encrypted data blocks in a trusted data storage cluster; Construct metadata of the escrowed data and write the metadata to a metadata blockchain. The metadata at least includes the hash data of the encrypted data blocks, the root of the encrypted Merkle tree, a random number commitment, the decentralized identifier of the data escrow party, the number of data blocks, and a data identifier.

2. The method according to claim 1, wherein The step of encrypting the encoded data blocks based on a random number and the private key corresponding to the decentralized identifier of the data escrow party to construct an encrypted Merkle tree includes: Generate a master key based on a random number and the private key corresponding to the decentralized identifier of the data escrow party; Derive a key for the encoded data block from the master key based on the number of the encoded data block; Encrypt the encoded data block based on the key of the encoded data block to obtain an initial encrypted data block; Construct the encrypted Merkle tree based on the number of the initial encrypted data block.

3. The method according to claim 1, wherein The step of storing the encrypted data blocks in a trusted data storage cluster includes: Obtain the node information of data nodes in the trusted data storage cluster, and calculate the logical distance between the encrypted data block and the data node; Based on the logical distance between the encrypted data block and the data node, determine the target data node with the smallest logical distance, and write the encrypted data block to the corresponding target data node.

4. The method according to claim 1, wherein The method described above further includes: Receive the data identifier of the data to be obtained submitted by the data escrow party and a data ownership proof, where the data ownership proof is generated based on the data identifier of the data to be obtained and the private key and public key corresponding to the decentralized identifier of the data escrow party; Based on the data identifier of the data to be obtained, obtain target metadata in the metadata blockchain; Verify the data ownership proof based on the decentralized identifier in the target metadata and the data identifier of the data to be obtained; After the data ownership proof is verified, determine the target data block and the key of the target data block based on the target metadata; Decrypt the target data block based on the key of the target data block to obtain plaintext data; Restore the plaintext data based on the error correction coding to obtain the data to be obtained, and return the data to be obtained to the data escrow party.

5. The method according to claim 4, wherein The step of determining the target data block and the key of the target data block based on the target metadata after the data ownership proof is verified includes: After the data ownership proof is verified, read the initial target data block based on the hash data in the target metadata; Based on the Merkle proof in the initial target data block and the root of the tree in the target metadata, perform a legality verification on the initial target data block to determine the target data block that passes the legality verification; When the number of the target data blocks meets the number of data blocks in the target metadata, based on the private key corresponding to the decentralized identifier of the data trustee and the random number commitment in the target metadata, recover the target master key; Based on the target master key, derive the key of the target data block.

6. The method according to claim 1, characterized in that, The method further includes: When receiving an authorization request for the data to be authorized sent by other data users, return a randomly generated challenge value to the other data users; Receive the authorization credential expression generated by the other data users, where the authorization credential expression at least includes the authorization credential sent by the data trustee, the challenge value, and the private key corresponding to the decentralized identifier of the other data users, and the authorization credential at least includes the data identifier of the data to be authorized, the decentralized identifier of the other data users, and the current master key; Based on the public keys corresponding to the decentralized identifiers of the data trustee and the other data users, verify the authorization credential expression and the authorization credential in the authorization credential expression; After the authorization credential expression and the authorization credential pass the verification, read the current master key in the authorization credential, and derive the key of the data block corresponding to the data to be authorized; Based on the key of the data block corresponding to the data to be authorized, read the data to be authorized, and send the data to be authorized to the other data users.

7. A trusted data hosting device, characterized in that, The trusted data trustee device includes: An encoding module, configured to obtain the data to be entrusted submitted by the data trustee, split the data to be entrusted into corresponding data blocks, and perform error correction encoding on the data blocks to obtain encoded data blocks; An encryption module, configured to encrypt the encoded data blocks based on a random number and the private key corresponding to the decentralized identifier of the data trustee, and construct an encrypted Merkle tree; The encryption module is further configured to add a corresponding Merkle proof to the encoded data blocks, generate encrypted data blocks, and store the encrypted data blocks in a trusted data storage cluster; A trusteeship module, configured to construct the metadata of the entrusted data, and write the metadata into a metadata blockchain, where the metadata at least includes the hash data of the encrypted data blocks, the root of the encrypted Merkle tree, a random number commitment, the decentralized identifier of the data trustee, the number of data blocks, and the data identifier.

8. A trusted data hosting device, characterized in that, The device includes: a memory, a processor, and a computer program stored on the memory and executable on the processor, where the computer program is configured to implement the steps of the trusted data trusteeship method according to any one of claims 1 to 6.

9. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium, and when the computer program is executed by a processor, it implements the steps of the trusted data trusteeship method according to any one of claims 1 to 6.

10. A computer program product, characterized in that, The computer program product includes a computer program which, when executed by a processor, implements the steps of the trusted data hosting method according to any one of claims 1 to 6.

Images