CN111523133A - Block chain and cloud data collaborative sharing method - Google Patents

Abstract

The invention relates to a block chain and cloud data collaborative sharing method, belongs to the technical field of secure cloud storage, and solves the problems of consistency and collaboration of uplink and downlink data in a chain; the method comprises the following steps: a block chain and cloud storage framework is adopted, a ciphertext of the original data file after encryption is stored in a cloud end, and metadata of the original data file is stored in the block chain in an encryption manner; the data owner DO acquires the encrypted metadata from the block chain, and decrypts the metadata to obtain a key used for encryption and a ciphertext storage position; carrying out proxy re-encryption on the ciphertext to generate a new key and a re-encrypted ciphertext storage position; sharing the new key and the storage position of the re-encrypted ciphertext to a data user DU; and the data user DU carries the encrypted ciphertext from the new storage position, and decrypts the encrypted ciphertext by using the new key to obtain the plaintext information of the cloud data. The invention expands the storage capacity of the block chain and improves the consensus efficiency; the consistency of the data is ensured, and the data privacy is protected during data sharing and transmission.

Description

Block chain and cloud data collaborative sharing method

Technical Field

The invention relates to the technical field of secure cloud storage, in particular to a block chain and cloud data collaborative sharing method.

Background

The information stored on the public chain is disclosed to all users, and all nodes can copy and share data on the blockchain. An attacker may obtain information about the balance of funds and details of the transaction for a particular account, the flow of particular funds, etc. by analyzing the transaction record. In the permission chain, although an identity admission mechanism is added, a channel for an unauthorized node to contact data is closed, and the privacy disclosure risk is reduced, the problem of data channel isolation is also faced. As the application scenario of the blockchain changes, the uplink data has semi/unstructured picture, voice, video, and file data in addition to the transaction information. Some uplink data, relating to security and privacy, such as banking financial transactions and medical health data, is not suitable for all nodes to view and verify. Further, as the number of users increases, the capacity of the blocks on the blockchain is limited, so that data needs to be stored on an external database or a cloud server, which in turn involves the problems of consistency and coordination of data on and off the chain, and how to ensure that data is not leaked when sharing data off the chain is a critical problem.

Disclosure of Invention

In view of the foregoing analysis, the present invention is directed to provide a method for cooperatively sharing blockchain and cloud data, so as to solve the problems of consistency and cooperation of uplink and downlink data in a chain and ensure that data is not leaked.

The purpose of the invention is mainly realized by the following technical scheme:

the invention discloses a block chain and cloud data collaborative sharing method, which comprises the following steps:

and (3) encryption storage: the method comprises the steps that a block chain and cloud storage framework is adopted, a ciphertext obtained by encrypting a data original file is stored in a cloud end, and metadata of the data original file is stored in the block chain in an encrypted mode; the metadata includes a key for encryption and ciphertext storage location information;

a data sharing step: the data owner DO acquires the encrypted metadata from the block chain, and decrypts the metadata to obtain a key used for encryption and a ciphertext storage position; carrying out proxy re-encryption on the ciphertext to generate a new key and a re-encrypted ciphertext storage position; sharing the new key and the storage position of the re-encrypted ciphertext to a data user DU; and the data user DU carries the encrypted ciphertext from the new storage position, and decrypts the encrypted ciphertext by using the new key to obtain the plaintext information of the cloud data.

Further, the step of storing the encrypted ciphertext of the data original file in the cloud includes:

dividing a data original file into data file blocks with the same size;

encrypting each data file block by using a symmetric encryption algorithm to obtain a block data file ciphertext; the symmetric encryption adopts a symmetric key as a first key;

storing the block data file ciphertext into a data storage node of a cloud;

the encrypting and storing the metadata of the data original file on the block chain comprises:

encrypting the first secret key by using a public key P1 of the data owner DO to generate a key ciphertext;

establishing metadata of each data file block based on the storage nodes of the key ciphertext and the block data file ciphertext; encrypting the metadata by using a public key P1 of a data owner DO to generate a metadata ciphertext;

and linking the metadata ciphertext to a block chain for storage.

Further, the metadata comprises lightweight data including the name of the data file block, the cloud storage node position, the key ciphertext, the Hash value and the URL address of the copy; and the metadata stored in the block chain corresponds to the data file blocks stored in the cloud one by one according to the positions of the cloud storage nodes.

Further, the proxy re-encrypting the ciphertext comprises:

step 1, the data owner DO sends a metadata access request to the block chain, and after the request passes, the data owner DO downloads a metadata ciphertext; the data owner DO decrypts the metadata ciphertext by using a private key P2 of the data owner DO to obtain a first key and a storage location of the block data file;

step 2, the data owner DO encrypts the first key to generate a second key, and then encrypts the first key and the second secret key to generate a third key for re-encryption;

step 3, the data owner DO transmits the third key to the file storage node through a safety channel, the block data file ciphertext in the file storage node is encrypted again, and the obtained ciphertext is called as a re-encrypted ciphertext;

step 4, the data owner DO sends the re-encrypted ciphertext to the data sharing node;

step 5, the data owner DO shares the second key and the position of the data sharing node to the data user DU through the secure channel;

and 6, downloading the re-encrypted ciphertext from the data sharing node by the DU, and decrypting the re-encrypted ciphertext by using the second key to obtain the plaintext information of the data file block.

Further, the second key is a symmetric key generated by the data owner DO by encrypting according to the first key by using a random algorithm, and a core of the random algorithm is specified by the data owner DO.

Further, the data sharing node is determined by random selection by the data owner DO.

Further, the metadata ciphertext is circulated by a transaction mechanism of the blockchain and is randomly stored on a node of the P2P network of the blockchain.

Further, integrity verification is carried out on the metadata ciphertext by using the Melkle tree.

Furthermore, the method also comprises the step of carrying out fault-tolerant processing on the metadata ciphertext by using a redundant file copy mode.

Further, cloud and block chain interaction is carried out by using the intelligent contract, so that cloud data and data on the block chain are ensured to be consistent.

The invention has the following beneficial effects:

the data access mode of the invention is to adopt a block chain + cloud storage architecture, save the lightweight metadata on the block chain, store the original file in the cloud, expand the storage capacity of the block chain, raise the consensus efficiency;

the data cooperation under the chain is realized, and the consistency of the data is ensured;

the cloud data is safely shared, and data privacy during data sharing and transmission is protected.

Additional features and advantages of the invention will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. The objectives and other advantages of the invention will be realized and attained by the structure particularly pointed out in the written description and claims hereof as well as the appended drawings.

Drawings

The drawings are only for purposes of illustrating particular embodiments and are not to be construed as limiting the invention, wherein like reference numerals are used to designate like parts throughout.

Fig. 1 is a flowchart of a method for cooperatively sharing a blockchain and cloud data according to an embodiment of the present invention;

fig. 2 is a flowchart of a file encryption storage method with cloud chain convergence in the embodiment of the present invention;

FIG. 3 is a schematic diagram of a permutation function in an embodiment of the invention;

FIG. 4 is a block chain structure in accordance with an embodiment of the present invention;

FIG. 5 is a schematic structural diagram of a Melkle tree according to an embodiment of the present invention;

fig. 6 is a schematic diagram of a block chain-based distributed cloud storage architecture in an embodiment of the present invention;

fig. 7 is a flowchart of a proxy re-encryption method in an embodiment of the present invention.

Detailed Description

The preferred embodiments of the present invention will now be described in detail with reference to the accompanying drawings, which form a part hereof, and which together with the embodiments of the invention serve to explain the principles of the invention.

An embodiment of the present invention discloses a method for cooperatively sharing a block chain and cloud data, as shown in fig. 1, including the following steps:

step S101, encryption storage step: the method comprises the steps that a block chain and cloud storage framework is adopted, a ciphertext obtained by encrypting a data original file is stored in a cloud end, and metadata of the data original file is stored in the block chain in an encrypted mode; the metadata includes storage location information of a key used for encryption and ciphertext on the cloud server.

Step S102, data sharing step: after acquiring the storage positions of the key and the ciphertext for encryption on the cloud server, the data owner DO carries out proxy re-encryption, and shares the storage positions of a new key and the re-encrypted ciphertext on the cloud server to the data user DU; and the data user DU decrypts the re-encrypted ciphertext by using the new secret key to obtain the plaintext information of the cloud data.

Specifically, after acquiring a key and a ciphertext storage position for encryption from a chain, a data owner DO performs proxy re-encryption on a ciphertext, hides the key and the ciphertext storage position, and generates a new key and a re-encrypted ciphertext storage position; sharing the new key and the storage position of the re-encrypted ciphertext to a data user DU; and the data user DU carries the encrypted ciphertext from the new storage position, and decrypts the encrypted ciphertext by using the new key to obtain the plaintext information of the cloud data.

Specifically, as shown in fig. 2, the cloud chain converged file encryption storage method includes:

step S201, dividing a data file into data file blocks with the same size;

the data file is first divided into equal sized blocks (e.g., 32MB, 64MB …). If the size of the last block is smaller than the specified value, it is deposited in the actual size.

Step S202, encrypting a data file block by using a symmetric encryption algorithm, wherein a symmetric secret key adopted in the symmetric encryption is a first secret key S;

the symmetric encryption algorithm is open, the calculated amount is small, the encryption speed is high, and the encryption efficiency is high. In the symmetric encryption algorithm, a data sender processes a plaintext (original data) and an encryption key together through a special encryption algorithm, and then the plaintext and the encryption key are changed into an encrypted ciphertext to be sent out. After the receiver receives the ciphertext, if the receiver wants to decode the original text, the receiver needs to decrypt the ciphertext by using the key used for encryption and the inverse algorithm of the same algorithm so as to recover the ciphertext into readable plaintext. In the symmetric encryption algorithm, only one key is used, and both the sender and the receiver use the key to encrypt and decrypt data, so that the secret party needs to know the encryption key in advance.

Optionally, the present embodiment adopts a des (data Encryption standard) symmetric Encryption algorithm, and the entry parameters include three: key, Data, Mode. Wherein Key is 64 bits in 8 bytes, and is a working Key of DES algorithm; data is also 8 bytes of 64 bits (may also be 128 bits or longer), which is Data to be encrypted or decrypted; mode is the working Mode of DES, and there are two kinds: encryption or decryption.

The DES algorithm changes a 64-bit plaintext input block into a 64-bit ciphertext output block, the used key is also 64 bits, and the algorithm is mainly divided into three steps:

(1) and (5) plaintext transformation. Firstly, carrying out initial permutation on an input 64-bit plaintext to obtain a permuted plaintext X0, wherein X0 is still 64 bits, only the permutation order of plaintext information is changed, and then the 64-bit permuted plaintext is equally divided into a left part L0 and a right part R0 to represent the left 32 bits and the right 32 bits of X0;

(2) and (6) iteration. Dividing the input 64-bit plaintext into two groups, then carrying out round encryption, wherein the encryption algorithm of each round is the same, taking Li-1 and Ri-1 of the previous round as the input of the next round, outputting Li and Ri of 32 bits, and the iteration rule is as follows:

Li-R i-1, Ri ═ Li ≧ f (R i-1, Ki) (i ═ 1,2,3, …,16), where f is a permutation function as shown in fig. 3, including E change rule, S-box and IP transform, with ×, denoting exclusive or;

wherein E change rule is as shown in Table 1

32	1	2	3	4	5	4	5	6	7	8	9	8	9	10	11
																12	13	12	13	14	15	16	17	16	17	18	19	20	21	20	21
22	23	24	25	26	25	26	27	28	29	28	29	30	31	32	1

S Box is shown in Table 2

IP substitution tables are shown in Table 3

58	50	42	34	26	18	10	2	60	52	44	36	28	20	12	4
																62	54	46	38	30	22	14	6	64	56	48	40	32	24	16	8
57	49	41	33	25	17	9	1	59	51	43	35	27	19	11	3
																61	53	45	37	29	21	13	5	63	55	47	39	31	23	15	7

(3): and finally, obtaining a ciphertext Y through an inverse substitution table IP-1.

Inverse substitution Table IP-1 is as shown in Table 4

40	8	48	16	56	24	64	32	39	7	47	15	55	23	63	31
																38	6	46	14	54	22	62	30	37	5	45	13	53	21	64	29
36	4	44	12	52	20	60	28	35	3	43	11	51	19	59	27
																34	2	42	10	50	18	58	26	33	1	41	9	49	17	57	25

Step S203, storing the block data file ciphertext to a data storage node of a cloud; a data storage node may store one or more tile data files.

Step S204, encrypting the first secret key S by using a public key P1 of a data owner DO to generate a secret key ciphertext;

each blockchain user, upon successful registration, assigns a public/private key pair, e.g., the user's public/private key pair (pk, sk) is generated based on an elliptic curve cryptography ECC algorithm. The public key is public and the private key is kept by the user himself.

ECC allows users to decrypt their files without the involvement of any key generation center or third party. At the same time, a signature key pair (spk, ssk) is generated using the digital signature algorithm ECDSA. At data streaming time, the sender signs ssk on the data file block and is verified by the receiver using spk.

Step S205, establishing metadata of each data file block, and encrypting the metadata by using a public key P1 of a data owner DO to generate a metadata ciphertext;

the metadata comprises lightweight data including the name of the data file block, the position of the cloud storage node, a key ciphertext, a Hash value and the URL address of the copy; and the metadata stored in the block chain corresponds to the data file blocks stored in the cloud one by one according to the positions of the cloud storage nodes. This relationship may be obtained by decrypting the metadata ciphertext.

Step S206, the metadata ciphertext is linked to the block chain for storage.

Specifically, the metadata ciphertext is circulated by a transaction mechanism of the blockchain and randomly stored on a node of the P2P network of the blockchain.

In the block chain structure shown in fig. 4, taking the contract file as an example, we only store the metadata of the data file, rather than storing the data file itself in the block chain. Because the block chain is highly redundant, the method can save a large amount of memory space for users, improve the operation speed and is safer. Even if an attacker intercepts the transaction data, the original contract data cannot be acquired. In our architecture, what is recorded on the blockchain is not a transaction in the traditional sense, but rather a process where metadata is streamed from one party to the other, again with a timestamp. Therefore, when a user wants to update a data file, only a new transaction needs to be initiated; likewise, when a user reviews a data file, only the latest transaction associated therewith needs to be reviewed, as it is the final state of the data file. When a user needs to verify their data, the transaction records can be traced back from the blockchain according to the identity information, and then their data can be verified through the file locations recorded on the blockchain.

Further, integrity verification is performed on the metadata ciphertext by using the Melkle tree.

As shown in fig. 5, the Melkle tree is computed from SHA256 one-way hashes, while SHA2562 is two SHA256 operations. The Melkle tree is first constructed by pairing data, i.e. the bottommost leaf node Ti. In bitcoin systems Ti generally refers to transactions, while in our system we refer to the process of streaming metadata from DO to DU. And h (Ti) is obtained after the hash operation, then pairwise matching and hash are carried out again, and the hash is carried out upwards one layer by one layer until the final calculation result, namely the Melkle tree root, is obtained. In the tree, each leaf node containing contract information may be verified through its corresponding path. By comparing their Melkle tree roots, we can know whether the contract metadata in the leaf nodes has been tampered with.

SHA256 outputs any input as a 256-bit string that is irreversible and with slight changes in input, the output will change significantly. As known from the calculation process, the Melkle root stores the information related to all the contract file blocks, so the integrity verification of the contract files only needs to verify the Melkle root, and the calculation cost is very low.

Further, the fault-tolerant processing of the metadata ciphertext is carried out by using a redundant file copy mode.

In order to ensure the reliability and performance of the architecture, a random storage strategy is adopted to store contract file blocks on nodes of the P2P network, and redundant file copies are used to realize a fault tolerance mechanism. Similarly, the contract document copies are encrypted before being uploaded, and the number of the contract document copies is determined by the number of the contract document blocks and the document copy placement policy (which is generally fixed). The file and the copies thereof are stored in a data center or a server in a triplicate manner, wherein the first copy is placed on a data node for uploading the file, and if the file is submitted outside a cluster, a node with a less busy disk, a less busy memory and a less busy CPU is randomly selected for storage; the second copy is placed on a node on a different chassis than the first copy; the third copy is placed on an adjacent node of the same chassis as the second copy. For security, contract file blocks and their copies are randomly placed around the user node so that a malicious attacker has little access to all of the chunks of the contract file.

Fig. 6 is a schematic diagram of the overall architecture of blockchain + cloud storage, i.e., a blockchain-based distributed cloud storage architecture, according to the embodiment.

Furthermore, cloud and block chain interaction is carried out by using the intelligent contract, so that cloud data and data on the block chain are ensured to be consistent.

The intelligent contract is used to store the encrypted key index and some related data and complete the retrieval operation to ensure the privacy of the user data. In the contract-making stage, the contract-initiating party is the Data Owner (Data Owner, DO) and the contract-receiving party is the Data User (DU), and this identity may change at any time during the contract-signing process (because new Data is continuously generated). The intelligent contracts of contract data interaction are divided into two types which are respectively used for sharing contract data and using the contract data. The former is deployed by a contract drafter and is sent to a contract receiver, so that contract data transfer is completed; the latter is issued by contract receiver for contract signing, searching and checking, and all process data are stored in intelligent contract.

1. Add user AddUser

Because we adopt the architecture of the federation chain and implement membership system for user management, only the administrator of the federation chain has the authority to execute the AddUser function (whether the AddUser function is executed or not can be decided by voting of the members of the federation chain). Firstly, a user initiates a request for adding a new user to an administrator, the administrator receives and verifies the identity certificate information of the user to be added through an encryption channel, and after verification is successful, a alliance chain account is authorized to the user through the function and public and private keys are distributed.

2. Deleting a user Removeuser

Only the federation chain administrator has authority to perform this function. When a user needs to be deleted, the administrator deletes the user's alliance chain account from the authorized account list through the function.

3. Adding index AddIndex to contract document

Only the contractual originator has the right to perform the function. When the drafter uploads a new contract document, he needs to select a keyword list from each document and build an encryption keyword index, and store it into the intelligent contract.

4. Deleting a contract document DeleteFile

Only the contractual originator has the right to perform the function. When the DO deletes a certain contract file, it is necessary to provide the encryption key index and the transaction ID of the file.

5. Delete keyword DeleteKeyword

Only the contractual originator has the right to perform the function. When a certain key word of the contract document needs to be deleted, an index of the key word needs to be provided.

6. Search

This function can only be performed by the contractual drafts or centrally authorized users. The user retrieves through the encrypted keyword Index keyworkindex and the function returns the transaction list TxID and the associated keyword list Index. When the retrieval initiator is an authorized user, before retrieval, whether the user balance is $ msg.value is enough to pay for the retrieval, and after the retrieval is successful, the retrieval cost $ cost is deducted from the user wallet.

Only the contractual originator has the right to perform the function. After performing this function, the DO returns the contract-related search fee to the user.

8. Sending contract metadata to designated users

Only the contractual originator has the right to perform the function. And encrypting the contract metadata and sending the encrypted contract metadata to a specified user.

9. Receiving contract metadata ReceiveContract

This function can only be performed by the contract recipient for reading the contract metadata. After successful reception, the DU can also retrieve contract data locally, and others cannot view the process.

10. Data search for data inspection

Only the contract recipient has the right to perform the function. And calling a Search function through the encrypted keyword index KeywordIndex to acquire and store a retrieval result in an intelligent contract of a contract receiving party.

11. Value Deposit into Deposit

This function is used to credit value consumed for data sharing and retrieval into the account wallet.

Specifically, the data sharing of this embodiment adopts a proxy re-encryption technique, and the data owner only needs to provide the data location and the newly set decryption key when sharing data; and the data receiver downloads the updated ciphertext from the corresponding position and then decrypts the ciphertext. As shown in fig. 7, the steps are as follows:

step S701, the data owner DO sends a metadata access request to the block chain, and after the request passes, the data owner DO downloads a metadata ciphertext, wherein the metadata ciphertext is the metadata ciphertext encrypted by the data owner DO through a public key of the data owner DO; the data owner DO decrypts the metadata ciphertext by using a private key P2 of the data owner DO to obtain a first key and the storage position number of the block data file;

the block chain in this embodiment is a federation chain, the data owner DO sends a metadata access request to the federation chain, and the federation nodes pass the metadata access request by voting.

Step S702, the data owner DO encrypts the first key to generate a second key, and then encrypts the second key and the first key to generate a third key for re-encryption;

the data owner DO encrypts the first key S to randomly generate another 64-bit random symmetric key, the second key S', and the random algorithm core can be specified by the user, so as to improve the security. The data owner DO uses the conversion key generation function to generate a third key from the first key S and the second key S' as a conversion encryption key K for proxy re-encryption;

step S703, the data owner DO transmits the third key K to the file storage position node through the secure channel, and encrypts the block data file ciphertext in the storage node again, wherein the obtained ciphertext is called as a re-encrypted ciphertext;

step S704, the data owner DO sends the re-encrypted ciphertext to the data sharing node;

the data sharing node is randomly selected for the data owner DO.

Step S705, the data owner DO shares the second key S and the location of the data sharing node to the data user DU through the secure channel;

step S706, the DU downloads the re-encrypted ciphertext from the data sharing node, and decrypts the re-encrypted ciphertext by using the second key to obtain the plaintext information of the data file block.

In summary, in the method for cooperatively sharing the blockchain and the cloud data disclosed in this embodiment, the access manner of the data is to use a storage architecture of the blockchain and the cloud, store the lightweight metadata on the blockchain, store the original file on the cloud, expand the storage capacity of the blockchain, and improve the consensus efficiency; data interaction under the chain link is realized, and the consistency of data is ensured; and the safe sharing of cloud data protects the data privacy during data sharing and transmission.

The above description is only for the preferred embodiment of the present invention, but the scope of the present invention is not limited thereto, and any changes or substitutions that can be easily conceived by those skilled in the art within the technical scope of the present invention are included in the scope of the present invention.

Claims (10)

1. A method for cooperatively sharing a block chain and cloud data is characterized by comprising the following steps:

and (3) encryption storage: the method comprises the steps that a block chain and cloud storage framework is adopted, a ciphertext obtained by encrypting a data original file is stored in a cloud end, and metadata of the data original file is stored in the block chain in an encrypted mode; the metadata includes a key for encryption and ciphertext storage location information;

a data sharing step: the data owner DO acquires the encrypted metadata from the block chain, and decrypts the metadata to obtain a key used for encryption and a ciphertext storage position; carrying out proxy re-encryption on the ciphertext to generate a new key and a re-encrypted ciphertext storage position; sharing the new key and the storage position of the re-encrypted ciphertext to a data user DU; and the data user DU carries the encrypted ciphertext from the new storage position, and decrypts the encrypted ciphertext by using the new key to obtain the plaintext information of the cloud data.

2. The method of claim 1, wherein the storing the encrypted ciphertext of the original data file in the cloud comprises:

dividing a data original file into data file blocks with the same size;

encrypting each data file block by using a symmetric encryption algorithm to obtain a block data file ciphertext; the symmetric encryption adopts a symmetric key as a first key;

storing the block data file ciphertext into a data storage node of a cloud;

the encrypting and storing the metadata of the data original file on the block chain comprises:

encrypting the first secret key by using a public key P1 of the data owner DO to generate a key ciphertext;

establishing metadata of each data file block based on the storage nodes of the key ciphertext and the block data file ciphertext; encrypting the metadata by using a public key P1 of a data owner DO to generate a metadata ciphertext;

and linking the metadata ciphertext to a block chain for storage.

3. The method of claim 2, wherein the metadata comprises lightweight data including a name of a data file block, a cloud storage node location, a key cryptogram, a Hash value, and a URL address of a copy; and the metadata stored in the block chain corresponds to the data file blocks stored in the cloud one by one according to the positions of the cloud storage nodes.

4. The method of claim 2, wherein the proxy re-encrypting the ciphertext comprises:

step 1, the data owner DO sends a metadata access request to the block chain, and after the request passes, the data owner DO downloads a metadata ciphertext; the data owner DO decrypts the metadata ciphertext by using a private key P2 of the data owner DO to obtain a first key and a storage location of the block data file;

step 2, the data owner DO encrypts the first key to generate a second key, and then encrypts the first key and the second secret key to generate a third key for re-encryption;

step 3, the data owner DO transmits the third key to the file storage node through a safety channel, the block data file ciphertext in the file storage node is encrypted again, and the obtained ciphertext is called as a re-encrypted ciphertext;

step 4, the data owner DO sends the re-encrypted ciphertext to the data sharing node;

step 5, the data owner DO shares the second key and the position of the data sharing node to the data user DU through the secure channel;

and 6, downloading the re-encrypted ciphertext from the data sharing node by the DU, and decrypting the re-encrypted ciphertext by using the second key to obtain the plaintext information of the data file block.

5. The method of claim 2, wherein the second key is a symmetric key generated by the data owner DO by encrypting according to the first key by using a random algorithm, and a core of the random algorithm is specified by the data owner DO.

6. The method of claim 2, wherein the data sharing node is randomly selected by a data owner DO.

7. The method for cooperatively sharing blockchain and cloud data according to any one of claims 1 to 6, wherein the metadata ciphertext is circulated in a transaction mechanism of the blockchain and is randomly stored on a node of a P2P network of the blockchain.

8. The method for cooperatively sharing a blockchain and cloud data according to any one of claims 1 to 6, further comprising performing integrity verification on a metadata ciphertext by using a Melkle tree.

9. The method for cooperatively sharing the blockchain and the cloud data according to any one of claims 1 to 6, further comprising performing fault-tolerant processing on a metadata ciphertext by using a redundant file copy manner.

10. The method for cooperatively sharing blockchain and cloud data according to any one of claims 1 to 6, further comprising performing cloud and blockchain interaction by using a smart contract, so that the cloud data and the data on the blockchain are consistent.

Images