Multi-user revocable and searchable encryption method based on block chain

Abstract

The invention discloses a multi-user revocable and searchable encryption method based on a block chain, and relates to the technical field of block chains and searchable encryption, and the method comprises a system establishment stage, a user management stage, an updating stage and a searching stage. And by adopting the block chain technology and IPFS decentralized storage, the tampering resistance of the system information is ensured, and the privacy leakage risk is reduced. By introducing the homomorphic XOR function, the user identifier is packaged and then verified, so that a multi-user application scene is realized, the interaction efficiency of the system is improved, and the safety and reliability under multiple users are also ensured; by introducing a Bloom filter and a pseudo-random puncture function, the operability of a file identifier is improved, and a safe and efficient key generation and transmission mechanism is cooperatively designed; and aiming at file deletion and addition of a revocation mechanism, a secondary search mechanism is designed emphatically at the same time, so that the updating and search overhead is reduced, and the overall performance of the system is improved.

Description

Technical Field

[0001] The present invention relates to blockchain technology and searchable encryption technology, and in particular to a multi-user revocable and searchable encryption method based on blockchain. Background Art

[0002] With the rapid development of the Internet and cloud computing, a large amount of data related to life and production has been collected and used, resulting in an explosive growth in the scale of data, accompanied by a substantial increase in the demand for data storage. In order to effectively respond to this demand, more organizations and individuals choose to outsource data to third-party cloud storage platforms for storage to reduce storage costs. However, outsourcing data storage increases the risk of data leakage. In order to reduce the risk of data leakage, researchers introduced data encryption to ensure the confidentiality of data, thereby achieving secure outsourcing storage of data. Furthermore, in order for data to generate value and be effectively used, it is necessary to provide accurate data for specific data analysis. How to accurately locate the required data in encrypted data has become an urgent problem to be solved. In order to solve this problem, researchers introduced searchable encryption technology.

[0003] Dynamic Symmetric Searchable Encryption (DSSE) allows clients to encrypt a set of data and outsource it to an untrusted smart contract. Generally speaking, data encryption is done in a way that allows efficient search of data without sacrificing data and query privacy. SSE achieves better efficiency at the cost of allowing partial information captured by a specific leakage function to leak.

[0004] However, in the event of a small amount of leakage, the adversary will be able to infer sensitive information hidden in the data. In other words, if the adversary obtains the file content or keywords in the file of some data owners, the adversary can infer the query performed by the client from the leakage function. Later, file injection attacks appeared. This attack can obtain complete client queries with only a small amount of injection files, threatening the security of dynamic searchable encryption schemes. Therefore, the concepts of forward privacy and backward privacy are proposed. Forward privacy ensures that previous search queries cannot be associated with future updates, while backward privacy ensures that subsequent search queries cannot be associated with documents deleted in the past. Since then, extensive research has been conducted on different degrees of forward and backward privacy for single users and multiple users and the efficiency of achieving them.

[0005] In order to reduce the time cost of search result return verification, search trap security and search efficiency, blockchain is also introduced in the searchable encryption field. Blockchain and smart contracts published on it are decentralized and have excellent properties such as immutability. Combined with the gradually mature decentralized storage Interplanetary File System (IPFS), it solves the problem of high risk of privacy leakage in traditional storage. Summary of the invention

[0006] The purpose of the present invention is to overcome the shortcomings of the prior art and provide a multi-user revocable and searchable encryption method based on blockchain to ensure the non-tamperability of system information and reduce the risk of privacy leakage.

[0007] The objective of the present invention is achieved through the following technical solutions:

[0008] A multi-user revocable and searchable encryption method based on blockchain, comprising:

[0009] System Setup Phase: The data owner performs initialization. The data owner uses the system parameter λ to initialize multiple sets C, D, User, E, EDB, Cd, OTags, Odel for storing user data, as well as the pseudo-random puncture function GGM tree T and the system key K u ; The data owner publishes the update contract and search contract to the blockchain, initializes the set Map, Tags, Dict, Del, Cs, Cache and a Bloom filter list D; The data owner sets the required fee for executing the contract on the blockchain;

[0010] User Management UserControl stage: including adding and deleting users. When adding a user, the user submits a registration application to the data owner, and the data owner generates a unique identifier u for the user. id With random number r i , and secretly stored in the User collection, using the system key K u Calculate the user key k i And return it to the user; when the user needs to be deleted, the data owner deletes the user from the User collection;

[0011] Update phase: The data owner collects the update fee from the user, and uses the homomorphic XOR function f to calculate the keyword search state tw for the document corresponding to the keyword w; according to the keyword search state tw, the master key sk of the pseudo-random puncture function GGM tree corresponding to the keyword w is taken from the set E; the file identifier ind and the user identifier u are used to calculate the keyword search state tw; idAfter hashing, the tag is obtained; the tag is mapped using the Bloom filter algorithm, and the encryption key is generated by combining the pseudo-random puncture function GGM tree. After all data documents are encrypted, the data owner fills all encrypted documents neatly in blocks and sends them to the IPFS distributed database for storage; after receiving the FileHash value calculated by IPFS, the data owner generates an update-upload trapdoor and sends it to the blockchain, and transfers the update fee to the update contract account, and executes the update contract for upload processing; or revokes the file identifier that needs to be deleted, generates an update-delete trapdoor and sends it to the blockchain, and transfers the update fee to the update contract account, and executes the update contract for deletion processing;

[0012] Search phase: the user calculates the search token ST and the search fee and sends them to the data owner; the data owner uses the homomorphic XOR function f for verification, obtains the keyword search state tw, and takes out the master key sk and keyword w of the GGM tree from E[tw]; the decryption key is generated by combining the Bloom filter with the pseudo-random puncture function GGM tree and packaged as a GGM tree node; the data owner generates a search trapdoor and sends it to the blockchain, and transfers the search fee to the search contract account to execute the search contract; the search contract determines whether to perform a secondary search or a normal search.

[0013] Furthermore, the system establishment Setup phase specifically includes the following steps:

[0014] The data owner initializes multiple sets for storing user data, including set C for storing the number of uploads corresponding to each user's keyword, set D for storing the Bloom filter list corresponding to each keyword, and the random number r corresponding to each user. i With logo u id The set of pairs User, the set E of the master key sk and keyword w pairs (sk, w) of the pseudo-random puncture function GGM tree corresponding to each keyword, the set EDB of all encrypted documents ciphertext_list, the set Cd of the upload times of the keyword w data document set DB(w), the set OTags of the tag tag for the update processing of the smart contract, and the set Odel of the tag tag for the deletion processing of the smart contract; set all the sets to empty;

[0015] The data owner initializes the pseudo-random puncture function GGM tree T;

[0016] The data owner uses the system parameter λ to initialize the system key K u ←{0,1} λ ;

[0017] The data owner publishes the smart contract to the blockchain and initializes the sets Map, Tags, Dict, Del, and Cs, which are used to store the FileHash value of the IPFS storage file block corresponding to the keyword w, the tag uploaded by the data owner, the encrypted document identifier list downloaded from IPFS by the smart contract, the tag that needs to be deleted for each user's corresponding keyword, the number of uploads of each user's corresponding keyword recorded on the blockchain, and set the cost of executing the contract on the blockchain;

[0018] The smart contract initializes the cache collection Cache, which is used to cache the last search result index collection of each user's corresponding keyword;

[0019] The smart contract initializes a Bloom filter list D to cooperate with the data owner's update and search operations.

[0020] Furthermore, the user management UserControl stage specifically includes:

[0021] Add user: data owner from {0,1} λ Generate user ID u id With random number r i , and is secretly stored in the User collection; the data owner uses the system key to calculate the user key k for each registered user i ←K u ⊕r i and sent to the user via a secure channel;

[0022] Delete user: The data owner deletes the user's corresponding identifier u id With random number r i Remove from the User collection.

[0023] In a specific embodiment, the update phase specifically includes the following steps:

[0024] The data owner receives the user's update fee and uses the homomorphic XOR function f and the system key K u Calculate keyword search status tw←f Ku (w), take out the master key sk of the pseudo-random puncture function GGM tree corresponding to keyword w from the set E[tw]. If sk does not exist, it means that the file related to keyword w has never been uploaded, then select {0,1} λ Initialize sk and form a (sk, w) pair with the keyword w and put it into E[tw];

[0025] For each (w, ind) of different users, the data owner takes the user's corresponding identifier u from the User set id, using the hash function H1, keyword w, and file identifier ind to calculate the tag tag←H1(w||ind||u id );

[0026] The data owner uses the hash function H2, keyword w and user identifier u id Calculate the token←H2(w,u id ), used to identify the same keyword w corresponding to different users;

[0027] The data owner takes out the Bloom filter list D corresponding to the keyword w from the set D, and takes out the upload count counter corresponding to the token from the set C; if the Bloom filter list D does not exist, initialize the Bloom filter list D, set it to all 0s, put it into D[w], set the counter to 0, and put it into C[token];

[0028] Upload files: The data owner generates an encryption key based on the pseudo-random puncture function GGM tree. After all data documents are encrypted, all encrypted documents are divided into blocks and filled neatly before being sent to the IPFS distributed database for storage. After receiving the FileHash value calculated by IPFS, the data owner generates an update-upload trapdoor and sends it to the blockchain. The update fee is transferred to the update contract account, and the update contract is executed for upload processing; or the file identifier that needs to be deleted is revoked;

[0029] Deleting files: The data owner generates an update-delete trapdoor and sends it to the blockchain, transfers the update fee to the update contract account, and executes the update contract to perform the deletion process.

[0030] Furthermore, the file uploading process includes the following steps:

[0031] The data owner uses the Bloom filter algorithm get_index(D,tag) to obtain all the position indexes corresponding to the tag tag on the Bloom filter list D;

[0032] The data owner uses the pseudo-random puncture function GGM tree algorithm derive_key(T,sk,index,T.level) to generate an encryption key sk for each position index in indexes index , and then use the symmetric encryption algorithm Enc(ind,sk index ) Encrypt the file identifier ind to obtain the ciphertext ct index , put into the corresponding position of the ciphertext list ciphertext_list[index], all ciphertexts form the ciphertext list ciphertext_list;

[0033] The data owner uses the hash function H2, the number of uploads counter, and token to calculate the label ← H2 (counter, token);

[0034] The data owner puts the Bloom filter list D back into the set D[w], adds the upload count counter+1, and puts it back into the set C[token];

[0035] The data owner puts the tag into the set OTags[label] and the set ODel[token];

[0036] The data owner puts ciphertext_list into the encrypted document set EDB[label] position, sets the block size B, and fills {0,1} to the size of B if it is smaller than B, otherwise divides it into Block, the last block is filled with {0,1} to B size and sent to IPFS;

[0037] IPFS stores EDB in blocks and returns FileHashes={FileHash1, FileHash2,…, FileHash j};

[0038] The data owner takes d_counter from Cd[w] and calculates addr←H2(w,d_counter), and then adds Cd[w]←d_counter+1;

[0039] Send (addr, FileHashes, OTags, ODel) as the update-upload trapdoor to the blockchain, and transfer the update fee to the update contract account;

[0040] Execute the update contract, execute FileHashes={FileHash1,FileHash2,…,FileHash j}←Map[addr], implement the index of keyword w to IPFS storage file block FileHash;

[0041] The update contract merges the tag storage set Tags with OTags, and removes the tag tag in the set ODel[token] from the deletion set Del[token].

[0042] Furthermore, the deleting file specifically includes the steps of:

[0043] For each tag corresponding to the file identifier to be deleted, the data owner uses the Bloom filter algorithm add_tag(D,tag) to set all positions corresponding to the tag tag on the Bloom filter list D to 1, and then puts the Bloom filter list D back into the set D[w];

[0044] The data owner puts the tag to be deleted into ODel[token];

[0045] The data owner sends the set ODel to the blockchain as an update-delete trapdoor and transfers the update fee to the update contract account;

[0046] Execute the update contract to merge the deletion set Del with the set ODel.

[0047] Furthermore, the search phase specifically includes the following steps:

[0048] User from {0,1} λ Generate a random number S, use the homomorphic XOR function f, the random number S and the user key k i Calculate ST i1 =f ki (w⊕S),ST i2 = S, and the search token ST i =(ST i1 ,ST i2 ) and search fees are sent to the data owner;

[0049] The data owner takes the user ID u corresponding to the user from the user set User id With random number r i , using the homomorphic XOR function f to calculate f ri (S)⊕ST i1 =f ri (S)⊕f ki (w⊕S)=f ri⊕ki (w) = f Ku (w)=tw, get the keyword search state tw corresponding to keyword w;

[0050] The data owner takes out the (sk, w) pair from E[tw], that is, the master key sk of the pseudo-random puncture function GGM tree corresponding to the keyword w and the keyword w, and then uses the hash function H2, the keyword w and the user identifier u id Calculate the token←H2(w,u id );

[0051] The data owner takes out the Bloom filter list D from the set D[w], takes out the upload count counter corresponding to the token from the set C[token], and takes out d_counter from the set Cd[w]. If any of the parameters does not exist, it means that the file related to the keyword w has never been uploaded, and the search algorithm ends;

[0052] The data owner starts with the count d_cnt = 0, and adds 1 each time until d_cnt is greater than d_counter. Then, the data owner performs a loop to calculate addr←H2(w, d_cnt) and obtains Addrs = {addr1, addr2, ..., addr d_counter};

[0053] The data owner uses the Bloom filter algorithm search(D) to obtain all the positions remaining_pos set to 0 on the Bloom filter list D corresponding to the keyword w;

[0054] The data owner initializes a pseudo-random puncture function GGM tree node node for each position pos in remain_pos, sets the node's position attribute index to pos, sets the node's height attribute level to the height T.level of the GGM tree T, and then puts these nodes into the node set node_list;

[0055] The data owner uses the pseudo-random puncture function GGM tree algorithm min_coverage(node_list) to reduce the nodes in node_list to the optimal coverage node set remain_node;

[0056] The data owner uses the pseudo-random puncture function GGM tree algorithm derive_key(T,sk,node.index,node.level) to calculate the symmetric key sk corresponding to each node node in the optimal coverage node set remain_node j , set the symmetric key attribute key of node to sk j ;

[0057] The data owner sends the token, the upload count counter corresponding to the token, the keyword w to the IPFS storage index set Addrs, the optimal coverage node set remain_node and the pseudo-random puncture function GGM tree T tree height T.level to form a search trapdoor and sends it to the blockchain, and transfers the search fee to the search contract account;

[0058] Execute the search contract, receive the token, take out the token upload count s_counter recorded on the blockchain from the set Cs[token] stored on the blockchain, and compare it with the token upload count counter recorded by the owner of the received data. If counter is less than or equal to s_counter, it means that there is no new file upload corresponding to the token between the last two searches, and the secondary search process is directly triggered; if counter is greater than s_counter, it means that there is a new file upload corresponding to the token between the last two searches, and the search contract uses the received Addrs = {addr1, addr2, ..., addr d_counter}, from addr1, addr2, ..., addr d_counte Each time an addr is taken out i , from Map[addr i ]Remove the FileHashes i , then download the encrypted data document from IPFS to the collection Dict, and directly perform normal search processing;

[0059] The secondary search process is as follows: using the data in the cache set Cache on the blockchain, removing the file identifiers that should be deleted from the records, obtaining the search results and sending them to the user;

[0060] The normal search processing process is as follows: the search contract uses the dictionary Map stored on the blockchain to retrieve the IPFS file block FileHash corresponding to the keyword w, downloads the encrypted document corresponding to the keyword w from IPFS and removes the padding bits to the set Dict, then restores the packaged GGM tree node to the decryption key, decrypts the ciphertext, and deletes the revoked document during the decryption process, sends the deleted document set to the IPFS storage, and IPFS returns the FileHash value to update the dictionary Map stored on the blockchain. Finally, the search results are stored in the cache set Cache and then sent to the user.

[0061] Furthermore, the secondary search process specifically includes the steps of:

[0062] The search contract takes out the result set Res of the last search from the cache set Cache[token], which stores the file identifier / tag pair (ind, tag), and takes out the tag list marked as deleted from the delete set Del[token];

[0063] The search contract removes all (ind, tag) containing the tag tag in Del[token] from the search result set Res;

[0064] The search contract puts the processed search result set Res back into the cache set Cache[token], republishes the updated set to the blockchain, and then sends Res to the user.

[0065] Furthermore, the normal search process specifically includes the steps of:

[0066] The search contract receives the optimal coverage node set remain_node and the pseudo-random puncture function GGM tree T tree height T.level, and uses the pseudo-random puncture function GGM tree algorithm compute_key(remain_node,T.level) to calculate the symmetric key node.key corresponding to all nodes in the node set remain_list, and puts it into the key storage set Keys. The symmetric key of each node is strictly stored in Keys[node.index];

[0067] The search contract starts from the count cnt=0, and increases by 1 each time until cnt is greater than counter, and then executes steps i to vi in ​​a loop:

[0068] i. The search contract uses the hash function H2, the count cnt, and the token to calculate the label label←H2(cnt,token);

[0069] ii. The search contract sets a flag flag = 0 to mark whether the file identifier ind is successfully decrypted during the decryption process of each tag tag;

[0070] iii. The search contract takes out the ciphertext list ciphertext_list from the ciphertext storage set Dict[label], and takes out the tag tag from the tag storage set Tags[label];

[0071] iv. The search contract uses the Bloom filter list D with all positions set to 0 in the system setup, and uses the Bloom filter algorithm get_index(D,tag) to simulate all the positions corresponding to the tag tag obtained by running the algorithm get_index(D,tag) when the data owner encrypts, which is recorded as dec_pos here;

[0072] v. The search contract decrypts each position pos in each dec_pos using the symmetric decryption algorithm Dec(ciphertext_list[pos],Keys[pos]). If the decryption is successful and the file identifier ind is obtained, the flag is set to 1, the (ind, tag) pair is stored in the search result set res, and the loop on dec_pos is terminated in advance;

[0073] vi. After the search contract finishes the dec_pos loop, it checks the flag. If the flag is 0, it means that the file identifier ind has been deleted. The smart contract sets Tags[label] and Dict[label] to empty, completing the deletion operation.

[0074] After the search contract ends the loop, the Dict after the deletion process is used as the updated encrypted data document and filled in blocks of size B and sent to IPFS. IPFS stores and returns the new FileHashes = {FileHash1, FileHash2, ..., FileHash j}, search for contract update Map[addr i ]←FileHashes={FileHash1,FileHash2,…,FileHash j};

[0075] After the search contract completes all loops corresponding to Addrs, it merges d_counter search result sets res into the total search result set Res, puts it into the cache set Cache[token], takes the token upload count counter recorded by the data owner as the token upload count s_counter recorded by the updated search contract, executes Cs[token]←counter, and re-uploads all updated sets to the blockchain;

[0076] The search contract sends the total search result set Res to the user.

[0077] The beneficial effects of the present invention are:

[0078] 1) The introduction of blockchain technology and decentralized IPFS distributed database ensures the immutability of system information and reduces the risk of privacy leakage.

[0079] 2) The homomorphic XOR encryption function f is used to implement multi-user permission control management, thereby completing the support for multi-user scenarios and making it more oriented to practical applications.

[0080] 3) The probabilistic data structure BloomFilter is used to achieve efficient file identifier mapping and key mapping. By operating the Bloom filter mapping list, the undo operation of the deleted files can be achieved with minimal cost, greatly improving the efficiency of system update query and key generation.

[0081] 4) The pseudo-random puncture function GGM tree is used to achieve efficient key generation and management.

[0082] 5) A detailed design was carried out for the secondary search, which greatly improved the search efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0083] Figure 1 It is a system framework diagram of the present invention. DETAILED DESCRIPTION

[0084] The technical solution of the present invention will be clearly and completely described below in conjunction with the embodiments. Obviously, the described embodiments are only part of the embodiments of the present invention, rather than all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present invention.

[0085] See also Figure 1 , the present invention provides a technical solution:

[0086] A multi-user revocable and searchable encryption method based on blockchain, comprising:

[0087] System Setup Phase: The data owner performs initialization. The data owner uses the system parameter λ to initialize multiple sets C, D, User, E, EDB, Cd, OTags, Odel for storing user data, as well as the pseudo-random puncture function GGM tree T and the system key K u ; The data owner publishes the update contract and search contract to the blockchain, initializes the set Map, Tags, Dict, Del, Cs, Cache and a Bloom filter list D; The data owner sets the required fee for executing the contract on the blockchain;

[0088] User Management UserControl stage: including adding and deleting users. When adding a user, the user submits a registration application to the data owner, and the data owner generates a unique identifier u for the user. id With random number r i , and secretly stored in the User collection, using the system key K u Calculate the user key k i And return it to the user; when the user needs to be deleted, the data owner deletes the user from the User collection;

[0089] Update phase: The data owner collects the update fee from the user, and uses the homomorphic XOR function f to calculate the keyword search state tw for the document corresponding to the keyword w; according to the keyword search state tw, the master key sk of the pseudo-random puncture function GGM tree corresponding to the keyword w is taken from the set E; the file identifier ind and the user identifier u are used to calculate the keyword search state tw; idAfter hashing, the tag is obtained; the tag is mapped using the Bloom filter algorithm, and the encryption key is generated by combining the pseudo-random puncture function GGM tree. After all data documents are encrypted, the data owner fills all encrypted documents neatly in blocks and sends them to the IPFS distributed database for storage; after receiving the FileHash value calculated by IPFS, the data owner generates an update-upload trapdoor and sends it to the blockchain, and transfers the update fee to the update contract account, and executes the update contract for upload processing; or revokes the file identifier that needs to be deleted, generates an update-delete trapdoor and sends it to the blockchain, and transfers the update fee to the update contract account, and executes the update contract for deletion processing;

[0090] Search phase: the user calculates the search token ST and the search fee and sends them to the data owner; the data owner uses the homomorphic XOR function f for verification, obtains the keyword search state tw, and takes out the master key sk and keyword w of the GGM tree from E[tw]; the decryption key is generated by combining the Bloom filter with the pseudo-random puncture function GGM tree and packaged as a GGM tree node; the data owner generates a search trapdoor and sends it to the blockchain, and transfers the search fee to the search contract account to execute the search contract; the search contract determines whether to perform a secondary search or a normal search.

[0091] The system framework diagram of the present invention is as follows: Figure 1 As shown, there are four entities in this scheme, whose names and functions are as follows:

[0092] Data Owner: A completely honest entity whose behavior will not threaten the system. It is responsible for user registration and deletion, key generation and distribution, and file update and search in the solution process;

[0093] User: Responsible for making search requests to the data owner. After registering with the data owner, a unique ID is obtained. The data owner uses the ID to upload or delete files that can only be searched by the user.

[0094] Blockchain and Smart contract: realize decentralization, execute preset codes, complete update and search operations with data owners, and ensure the immutability of system information.

[0095] IPFS Distributed Database: responsible for the storage and downloading of encrypted data document blocks.

[0096] In a specific embodiment, the system establishment Setup phase specifically includes the following steps:

[0097] The data owner initializes multiple sets for storing user data, including set C for storing the number of uploads corresponding to each user's keyword, set D for storing the Bloom filter list corresponding to each keyword, and the random number r corresponding to each user. i With logo u id The set of pairs User, the set E of the master key sk and keyword w pairs (sk, w) of the pseudo-random puncture function GGM tree corresponding to each keyword, the set EDB of all encrypted documents ciphertext_list, the set Cd of the upload times of the keyword w data document set DB(w), the set OTags of the tag tag for the update processing of the smart contract, and the set Odel of the tag tag for the deletion processing of the smart contract; set all the sets to empty;

[0098] The data owner initializes the pseudo-random puncture function GGM tree T;

[0099] The data owner uses the system parameter λ to initialize the system key K u ←{0,1} λ ;

[0100] The data owner publishes the smart contract to the blockchain and initializes the sets Map, Tags, Dict, Del, and Cs, which are used to store the FileHash value of the IPFS storage file block corresponding to the keyword w, the tag uploaded by the data owner, the encrypted document identifier list downloaded from IPFS by the smart contract, the tag that needs to be deleted for each user's corresponding keyword, the number of uploads of each user's corresponding keyword recorded on the blockchain, and set the cost of executing the contract on the blockchain;

[0101] The smart contract initializes the cache collection Cache, which is used to cache the last search result index collection of each user's corresponding keyword;

[0102] The smart contract initializes a Bloom filter list D to cooperate with the data owner's update and search operations.

[0103] In a specific embodiment, the user management UserControl stage specifically includes:

[0104] Add user: data owner from {0,1} λ Generate user ID u id With random number r i , and is secretly stored in the User collection; the data owner uses the system key to calculate the user key k for each registered user i ←K u ⊕r i and sent to the user via a secure channel;

[0105] Delete user: The data owner deletes the user's corresponding identifier u id With random number r i Remove from the User collection.

[0106] In the Update phase, several commonly used functions and algorithms are involved. The specific principles or algorithm steps are as follows:

[0107] The homomorphic XOR function f is a pseudo-random function with encryption properties. ki (x1)⊕f kj (x2) = f ki⊕kj (x1⊕x2) property, where k i and k j represents a random key with the same bit length. In this function, f ki (x1) and f kj (x2) The random result of the output is XORed, and the result is XORed with the input value and bound using two random keys k i and k j The random output results produced by the XOR operation are equal.

[0108] The specific algorithm of BloomFilter is as follows:

[0109] (1) BF.gen(b,h): Input the length b of the Bloom filter list D and the number of hash functions in the hash function cluster h, and output a Bloom filter list D with all positions of length b set to 0;

[0110] (2) BF.add_tag(D,tag): Input Bloom filter list D and tag tag. Tag tag is mapped to h positions in list D through h hash functions. These positions are set to 1. Output the updated Bloom filter list D.

[0111] (3) BF.get_index(D,tag): Input Bloom filter list D and tag tag, tag tag is mapped to h positions in list D through h hash functions, and outputs the set indexes composed of these positions;

[0112] (4) BF.search(D): Input Bloom filter list D, and output all positions on Bloom filter list D that are set to 0.

[0113] The specific algorithm of the pseudo-random puncture function GGM tree is as follows:

[0114] (1) GGMTree.init(n): Input the number of nodes n of the GGM tree. The GGM tree is a complete binary tree. Each node GGMNode includes position index, height level and key key. The position and height are initialized accordingly. The key key is iteratively derived from the root node key sk. The tree height T.level is calculated and an initialized GGM tree T is output.

[0115] (2) GGMTree.derive_key(T,sk,index,level): Input GGM tree T, root key sk, position index, height level, derive the key key corresponding to the node GGMNode at position index and height level from the root node key sk, and output the key key corresponding to the node;

[0116] (3) GGMTree.min_coverage(node_list): Input node set node_list, and according to the position and height information of the nodes, merge the nodes with the same parent node and the same level to reduce the repeated coverage between nodes, so as to find the node set with the minimum coverage, and output node_list updated to the optimal coverage node set.

[0117] In a specific embodiment, the update phase specifically includes the following steps:

[0118] The data owner receives the user's update fee and uses the homomorphic XOR function f and the system key K u Calculate keyword search status tw←f Ku (w), take out the master key sk of the pseudo-random puncture function GGM tree corresponding to keyword w from the set E[tw]. If sk does not exist, it means that the file related to keyword w has never been uploaded, then select {0,1} λ Initialize sk and form a (sk, w) pair with the keyword w and put it into E[tw];

[0119] For each (w, ind) of different users, the data owner takes the user's corresponding identifier u from the User set id , using the hash function H1, keyword w, and file identifier ind to calculate the tag tag←H1(w||ind||u id );

[0120] The data owner uses the hash function H2, keyword w and user identifier u id Calculate the token←H2(w,u id ), used to identify the same keyword w corresponding to different users;

[0121] The data owner takes out the Bloom filter list D corresponding to the keyword w from the set D, and takes out the upload count counter corresponding to the token from the set C; if the Bloom filter list D does not exist, initialize the Bloom filter list D, set it to all 0s, put it into D[w], set the counter to 0, and put it into C[token];

[0122] Upload files: The data owner generates an encryption key based on the pseudo-random puncture function GGM tree. After all data documents are encrypted, all encrypted documents are divided into blocks and filled neatly before being sent to the IPFS distributed database for storage. After receiving the FileHash value calculated by IPFS, the data owner generates an update-upload trapdoor and sends it to the blockchain. The update fee is transferred to the update contract account, and the update contract is executed for upload processing; or the file identifier that needs to be deleted is revoked;

[0123] Deleting files: The data owner generates an update-delete trapdoor and sends it to the blockchain, transfers the update fee to the update contract account, and executes the update contract to perform the deletion process.

[0124] Furthermore, the file uploading process includes the following steps:

[0125] The data owner uses the Bloom filter algorithm get_index(D,tag) to obtain all the position indexes corresponding to the tag tag on the Bloom filter list D;

[0126] The data owner uses the pseudo-random puncture function GGM tree algorithm derive_key(T,sk,index,T.level) to generate an encryption key sk for each position index in indexes index , and then use the symmetric encryption algorithm Enc(ind,sk index ) Encrypt the file identifier ind to obtain the ciphertext ct index , put into the corresponding position of the ciphertext list ciphertext_list[index], all ciphertexts form the ciphertext list ciphertext_list;

[0127] The data owner uses the hash function H2, the number of uploads counter, and token to calculate the label ← H2 (counter, token);

[0128] The data owner puts the Bloom filter list D back into the set D[w], adds the upload count counter+1, and puts it back into the set C[token];

[0129] The data owner puts the tag into the set OTags[label] and the set ODel[token];

[0130] The data owner puts ciphertext_list into the encrypted document set EDB[label] position, sets the block size B, and fills {0,1} to the size of B if it is smaller than B, otherwise divides it into Block, the last block is filled with {0,1} to B size and sent to IPFS;

[0131] IPFS stores EDB in blocks and returns FileHashes={FileHash1, FileHash2,…, FileHash j};

[0132] The data owner takes d_counter from Cd[w] and calculates addr←H2(w,d_counter), and then adds Cd[w]←d_counter+1;

[0133] Send (addr, FileHashes, OTags, ODel) as the update-upload trapdoor to the blockchain, and transfer the update fee to the update contract account;

[0134] Execute the update contract, execute FileHashes={FileHash1,FileHash2,…,FileHash j}←Map[addr], implement the index of keyword w to IPFS storage file block FileHash;

[0135] The update contract merges the tag storage set Tags with OTags, and removes the tag tag in the set ODel[token] from the deletion set Del[token].

[0136] Furthermore, the deleting file specifically includes the steps of:

[0137] For each tag corresponding to the file identifier to be deleted, the data owner uses the Bloom filter algorithm add_tag(D,tag) to set all positions corresponding to the tag tag on the Bloom filter list D to 1, and then puts the Bloom filter list D back into the set D[w];

[0138] The data owner puts the tag to be deleted into ODel[token];

[0139] The data owner sends the set ODel to the blockchain as an update-delete trapdoor and transfers the update fee to the update contract account;

[0140] Execute the update contract to merge the deletion set Del with the set ODel.

[0141] In a specific embodiment, the search phase specifically includes the following steps:

[0142] User from {0,1} λ Generate a random number S, use the homomorphic XOR function f, the random number S and the user key k i Calculate ST i1 =f ki (w⊕S),ST i2 = S, and the search token ST i =(ST i1 ,ST i2 ) and search fees are sent to the data owner;

[0143] The data owner takes the user ID u corresponding to the user from the user set User id With random number r i , using the homomorphic XOR function f to calculate f ri (S)⊕ST i1 =f ri (S)⊕f ki (w⊕S)=f ri⊕ki (w) = f Ku (w)=tw, get the keyword search state tw corresponding to keyword w;

[0144] The data owner takes out the (sk, w) pair from E[tw], that is, the master key sk of the pseudo-random puncture function GGM tree corresponding to the keyword w and the keyword w, and then uses the hash function H2, the keyword w and the user identifier u id Calculate the token←H2(w,u id );

[0145] The data owner takes out the Bloom filter list D from the set D[w], takes out the upload count counter corresponding to the token from the set C[token], and takes out d_counter from the set Cd[w]. If any of the parameters does not exist, it means that the file related to the keyword w has never been uploaded, and the search algorithm ends;

[0146] The data owner starts with the count d_cnt = 0, and adds 1 each time until d_cnt is greater than d_counter. Then, the data owner performs a loop to calculate addr←H2(w, d_cnt) and obtains Addrs = {addr1, addr2, ..., addr d_counter};

[0147] The data owner uses the Bloom filter algorithm search(D) to obtain all the positions remaining_pos set to 0 on the Bloom filter list D corresponding to the keyword w;

[0148] The data owner initializes a pseudo-random puncture function GGM tree node node for each position pos in remain_pos, sets the node's position attribute index to pos, sets the node's height attribute level to the height T.level of the GGM tree T, and then puts these nodes into the node set node_list;

[0149] The data owner uses the pseudo-random puncture function GGM tree algorithm min_coverage(node_list) to reduce the nodes in node_list to the optimal coverage node set remain_node;

[0150] The data owner uses the pseudo-random puncture function GGM tree algorithm derive_key(T,sk,node.index,node.level) to calculate the symmetric key sk corresponding to each node node in the optimal coverage node set remain_node j , set the symmetric key attribute key of node to sk j ;

[0151] The data owner sends the token, the upload count counter corresponding to the token, the keyword w to the IPFS storage index set Addrs, the optimal coverage node set remain_node and the pseudo-random puncture function GGM tree T tree height T.level to form a search trapdoor and sends it to the blockchain, and transfers the search fee to the search contract account;

[0152] Execute the search contract, receive the token, take out the token upload count s_counter recorded on the blockchain from the set Cs[token] stored on the blockchain, and compare it with the token upload count counter recorded by the owner of the received data. If counter is less than or equal to s_counter, it means that there is no new file upload corresponding to the token between the last two searches, and the secondary search process is directly triggered; if counter is greater than s_counter, it means that there is a new file upload corresponding to the token between the last two searches, and the search contract uses the received Addrs = {addr1, addr2, ..., addr d_counter}, from addr1, addr2, ..., addr d_counte Each time an addr is taken out i , from Map[addr i ]Remove the FileHashes i , then download the encrypted data document from IPFS to the collection Dict, and directly perform normal search processing;

[0153] The secondary search process is as follows: using the data in the cache set Cache on the blockchain, removing the file identifiers that should be deleted from the records, obtaining the search results and sending them to the user;

[0154] The normal search processing process is as follows: the search contract uses the dictionary Map stored on the blockchain to retrieve the IPFS file block FileHash corresponding to the keyword w, downloads the encrypted document corresponding to the keyword w from IPFS and removes the padding bits to the set Dict, then restores the packaged GGM tree node to the decryption key, decrypts the ciphertext, and deletes the revoked document during the decryption process, sends the deleted document set to the IPFS storage, and IPFS returns the FileHash value to update the dictionary Map stored on the blockchain. Finally, the search results are stored in the cache set Cache and then sent to the user.

[0155] Furthermore, the secondary search process specifically includes the steps of:

[0156] The search contract takes out the result set Res of the last search from the cache set Cache[token], which stores the file identifier / tag pair (ind, tag), and takes out the tag list marked as deleted from the delete set Del[token];

[0157] The search contract removes all (ind, tag) containing the tag tag in Del[token] from the search result set Res;

[0158] The search contract puts the processed search result set Res back into the cache set Cache[token], republishes the updated set to the blockchain, and then sends Res to the user.

[0159] Furthermore, the normal search process specifically includes the steps of:

[0160] The search contract receives the optimal coverage node set remain_node and the pseudo-random puncture function GGM tree T tree height T.level, and uses the pseudo-random puncture function GGM tree algorithm compute_key(remain_node,T.level) to calculate the symmetric key node.key corresponding to all nodes in the node set remain_list, and puts it into the key storage set Keys. The symmetric key of each node is strictly stored in Keys[node.index];

[0161] The search contract starts from the count cnt=0, and increases by 1 each time until cnt is greater than counter, and then executes steps i to vi in ​​a loop:

[0162] i. The search contract uses the hash function H2, the count cnt, and the token to calculate the label label←H2(cnt,token);

[0163] ii. The search contract sets a flag flag = 0 to mark whether the file identifier ind is successfully decrypted during the decryption process of each tag tag;

[0164] iii. The search contract takes out the ciphertext list ciphertext_list from the ciphertext storage set Dict[label], and takes out the tag tag from the tag storage set Tags[label];

[0165] iv. The search contract uses the Bloom filter list D with all positions set to 0 in the system setup, and uses the Bloom filter algorithm get_index(D,tag) to simulate all the positions corresponding to the tag tag obtained by running the algorithm get_index(D,tag) when the data owner encrypts, which is recorded as dec_pos here;

[0166] v. The search contract decrypts each position pos in each dec_pos using the symmetric decryption algorithm Dec(ciphertext_list[pos],Keys[pos]). If the decryption is successful and the file identifier ind is obtained, the flag is set to 1, the (ind, tag) pair is stored in the search result set res, and the loop on dec_pos is terminated in advance;

[0167] vi. After the search contract finishes the dec_pos loop, it checks the flag. If the flag is 0, it means that the file identifier ind has been deleted. The smart contract sets Tags[label] and Dict[label] to empty, completing the deletion operation.

[0168] After the search contract ends the loop, the Dict after the deletion process is used as the updated encrypted data document and filled in blocks of size B and sent to IPFS. IPFS stores and returns the new FileHashes = {FileHash1, FileHash2, ..., FileHash j}, search for contract update Map[addr i ]←FileHashes={FileHash1,FileHash2,…,FileHash j};

[0169] After the search contract completes all loops corresponding to Addrs, it merges d_counter search result sets res into the total search result set Res, puts it into the cache set Cache[token], takes the token upload count counter recorded by the data owner as the token upload count s_counter recorded by the updated search contract, executes Cs[token]←counter, and re-uploads all updated sets to the blockchain;

[0170] The search contract sends the total search result set Res to the user.

[0171] The present invention provides a multi-user revocable and searchable encryption method based on blockchain. Under the premise of multi-user scenarios, it realizes the interaction between users, data owners, blockchain and IPFS distributed database, adds a revocation mechanism, reduces the update search overhead, and realizes efficient update, search and secondary search searchable encryption.

[0172] The innovations of the present invention include: 1. The blockchain technology and the decentralized IPFS distributed database are introduced to ensure the non-tamperability of system information and reduce the risk of privacy leakage; 2. The homomorphic XOR encryption function f is used to realize the permission control management of multiple users, thereby completing the support for multi-user scenarios and making it more oriented to practical applications; 3. The probabilistic data structure BloomFilter is used to realize efficient file identifier mapping and key mapping. By operating the Bloom filter mapping list, the undo operation of the deleted file can be realized with minimal cost, which greatly improves the efficiency of system update query and key generation; 4. The pseudo-random puncture function GGM tree is used to realize efficient key generation and management; 5. A detailed design is carried out for secondary search, which greatly improves the search efficiency.

[0173] The above is only a preferred embodiment of the present invention. It should be understood that the present invention is not limited to the form disclosed herein, and should not be regarded as excluding other embodiments, but can be used in various other combinations, modifications and environments, and can be modified within the scope of the concept described herein through the above teachings or the technology or knowledge of the relevant field. The changes and modifications made by those skilled in the art shall not deviate from the spirit and scope of the present invention, and shall be within the scope of protection of the claims attached to the present invention.

Claims

1. A multi-user revocable and searchable encryption method based on blockchain, characterized in that: include: System Setup Phase: The data owner performs initialization. The data owner uses the system parameter λ to initialize multiple sets C, D, User, E, EDB, Cd, OTags, Odel for storing user data, as well as the pseudo-random puncture function GGM tree T and the system key K u ; The data owner publishes the update contract and search contract to the blockchain, and initializes the set Map, Tags, Dict, Del, Cs, Cache and a Bloom filter list D; The data owner sets the fees required to execute the contract on the blockchain; User Management UserControl stage: including adding and deleting users. When adding a user, the user submits a registration application to the data owner, and the data owner generates a unique identifier u for the user. id With random number r i , and secretly stored in the User collection, using the system key K u Calculate the user key k i And return it to the user; when the user needs to be deleted, the data owner deletes the user from the User collection; Update phase: The data owner collects the update fee from the user and uses the homomorphic XOR function f to calculate the keyword search state tw for the document corresponding to the keyword w; According to the keyword search state tw, the master key sk of the pseudo-random puncture function GGM tree corresponding to the keyword w is taken from the set E; the file identifier ind and the user identifier u are used id After hashing, the tag is obtained; the tag is mapped using the Bloom filter algorithm, and the encryption key is generated by combining the pseudo-random puncture function GGM tree. After all data documents are encrypted, the data owner fills all encrypted documents in blocks and sends them to the IPFS distributed database for storage; After receiving the FileHash value calculated by IPFS, the data owner generates an update-upload trapdoor and sends it to the blockchain. The update fee is transferred to the update contract account, and the update contract is executed to perform the upload process. Or revoke the file identifier that needs to be deleted, generate an update-delete trapdoor and send it to the blockchain, transfer the update fee to the update contract account, and execute the update contract to delete it; Search phase: users calculate the search token ST and search fee and send them to the data owner; The data owner uses the homomorphic XOR function f for verification, obtains the keyword search state tw, and extracts the master key sk and keyword w of the GGM tree from E[tw]; uses the Bloom filter combined with the pseudo-random puncture function GGM tree to generate the decryption key and packages it into a GGM tree node; the data owner generates a search trapdoor and sends it to the blockchain, and transfers the search fee to the search contract account to execute the search contract; the search contract determines whether to perform a secondary search process or a normal search process.

2. A multi-user revocable and searchable encryption method based on blockchain according to claim 1, characterized in that: The system establishment Setup phase specifically includes the following steps: The data owner initializes multiple sets for storing user data, including set C for storing the number of uploads corresponding to each user's keyword, set D for storing the Bloom filter list corresponding to each keyword, and the random number r corresponding to each user. i With logo u id The set of pairs User, the set E of the master key sk and keyword w pairs (sk, w) of the pseudo-random puncture function GGM tree corresponding to each keyword, the set EDB of all encrypted documents ciphertext_list, the set Cd of the upload times of the keyword w data document set DB(w), the set OTags of the tag tag for the update processing of the smart contract, and the set Odel of the tag tag for the deletion processing of the smart contract; set all the sets to empty; The data owner initializes the pseudo-random puncture function GGM tree T; The data owner uses the system parameter λ to initialize the system key K u ←{0,1} λ ; The data owner publishes the smart contract to the blockchain and initializes the sets Map, Tags, Dict, Del, and Cs, which are used to store the FileHash value of the IPFS storage file block corresponding to the keyword w, the tag uploaded by the data owner, the encrypted document identifier list downloaded from IPFS by the smart contract, the tag that needs to be deleted for each user's corresponding keyword, the number of uploads of each user's corresponding keyword recorded on the blockchain, and set the cost of executing the contract on the blockchain; The smart contract initializes the cache collection Cache, which is used to cache the last search result index collection of each user's corresponding keyword; The smart contract initializes a Bloom filter list D to cooperate with the data owner's update and search operations.

3. A multi-user revocable and searchable encryption method based on blockchain according to claim 1, characterized in that: The user management UserControl stage specifically includes: Add user: data owner from {0,1} λ Generate user ID u id With random number r i , and is secretly stored in the User collection; the data owner uses the system key to calculate the user key k for each registered user i ←K u ⊕r i and sent to the user via a secure channel; Delete user: The data owner deletes the user's corresponding identifier u id With random number r i Remove from the User collection.

4. A multi-user revocable and searchable encryption method based on blockchain according to claim 1, characterized in that: The update phase specifically includes the following steps: The data owner receives the user's update fee and uses the homomorphic XOR function f and the system key K u Calculate keyword search status tw←f Ku (w), take out the master key sk of the pseudo-random puncture function GGM tree corresponding to keyword w from the set E[tw]. If sk does not exist, it means that the file related to keyword w has never been uploaded, then select {0,1} λ Initialize sk and form a (sk, w) pair with the keyword w and put it into E[tw]; For each (w, ind) of different users, the data owner takes the user's corresponding identifier u from the User set id , using the hash function H1, keyword w, and file identifier ind to calculate the tag tag←H1(w||ind||u id ); The data owner uses the hash function H2, keyword w and user identifier u id Calculate the token←H2(w,u id ), used to identify the same keyword w corresponding to different users; The data owner takes out the Bloom filter list D corresponding to the keyword w from the set D, and takes out the upload count counter corresponding to the token from the set C; if the Bloom filter list D does not exist, initialize the Bloom filter list D, set it to all 0s, put it into D[w], set the counter to 0, and put it into C[token]; Upload files: The data owner generates an encryption key based on the pseudo-random puncture function GGM tree. After all data documents are encrypted, all encrypted documents are divided into blocks and filled neatly before being sent to the IPFS distributed database for storage; After receiving the FileHash value calculated by IPFS, the data owner generates an update-upload trapdoor and sends it to the blockchain. The update fee is transferred to the update contract account, and the update contract is executed to perform the upload process. Or revoke the file identification that needs to be deleted; Deleting files: The data owner generates an update-delete trapdoor and sends it to the blockchain, transfers the update fee to the update contract account, and executes the update contract to perform the deletion process.

5. A multi-user revocable and searchable encryption method based on blockchain according to claim 4, characterized in that: The uploading file comprises the steps of: The data owner uses the Bloom filter algorithm get_index(D,tag) to obtain all the position indexes corresponding to the tag tag on the Bloom filter list D; The data owner uses the pseudo-random puncture function GGM tree algorithm derive_key(T,sk,index,T.level) to generate an encryption key sk for each position index in indexes index , and then use the symmetric encryption algorithm Enc(ind,sk index ) Encrypt the file identifier ind to obtain the ciphertext ct index , put into the corresponding position of the ciphertext list ciphertext_list[index], all ciphertexts form the ciphertext list ciphertext_list; The data owner uses the hash function H2, the number of uploads counter, and token to calculate the label ← H2 (counter, token); The data owner puts the Bloom filter list D back into the set D[w], adds the upload count counter+1, and puts it back into the set C[token]; The data owner puts the tag into the set OTags[label] and the set ODel[token]; The data owner puts ciphertext_list into the encrypted document set EDB[label] position, sets the block size B, and fills {0,1} to the size of B if it is smaller than B, otherwise divides it into Block, the last block is filled with {0,1} to B size and sent to IPFS; IPFS stores EDB in blocks and returns FileHashes={FileHash1, FileHash2,…, FileHash j }; The data owner takes d_counter from Cd[w] and calculates addr←H2(w,d_counter), and then adds Cd[w]←d_counter+1; Send (addr, FileHashes, OTags, ODel) as the update-upload trapdoor to the blockchain, and transfer the update fee to the update contract account; Execute the update contract, execute FileHashes={FileHash1,FileHash2,…,FileHash j }←Map[addr], implement the index of keyword w to IPFS storage file block FileHash; The update contract merges the tag storage set Tags with OTags, and removes the tag tag in the set ODel[token] from the deletion set Del[token].

6. A multi-user revocable and searchable encryption method based on blockchain according to claim 5, characterized in that: Deleting the file specifically includes the following steps: For each tag corresponding to the file identifier to be deleted, the data owner uses the Bloom filter algorithm add_tag(D,tag) to set all positions corresponding to the tag tag on the Bloom filter list D to 1, and then puts the Bloom filter list D back into the set D[w]; The data owner puts the tag to be deleted into ODel[token]; The data owner sends the set ODel to the blockchain as an update-delete trapdoor and transfers the update fee to the update contract account; Execute the update contract to merge the deletion set Del with the set ODel.

7. A multi-user revocable and searchable encryption method based on blockchain according to claim 6, characterized in that: The search phase specifically includes the following steps: User from {0,1} λ Generate a random number S, use the homomorphic XOR function f, the random number S and the user key k i Calculate ST i1 =f ki (w⊕S),ST i2 = S, and the search token ST i =(ST i1 ,ST i2 ) and search fees are sent to the data owner; The data owner takes the user ID u corresponding to the user from the user set User id With random number r i , using the homomorphic XOR function f to calculate f ri (S)⊕ST i1 =f ri (S)⊕f ki (w⊕S)=f ri⊕ki (w) = f Ku (w)=tw, get the keyword search state tw corresponding to keyword w; The data owner takes out the (sk, w) pair from E[tw], that is, the master key sk of the pseudo-random puncture function GGM tree corresponding to the keyword w and the keyword w, and then uses the hash function H2, the keyword w and the user identifier u id Calculate the token←H2(w,u id ); The data owner takes out the Bloom filter list D from the set D[w], takes out the upload count counter corresponding to the token from the set C[token], and takes out d_counter from the set Cd[w]. If any of the parameters does not exist, it means that the file related to the keyword w has never been uploaded, and the search algorithm ends; The data owner starts with the count d_cnt = 0, and adds 1 each time until d_cnt is greater than d_counter. Then, the data owner performs a loop to calculate addr←H2(w, d_cnt) and obtains Addrs = {addr1, addr2, ..., addr d_counter }; The data owner uses the Bloom filter algorithm search(D) to obtain all the positions remaining_pos set to 0 on the Bloom filter list D corresponding to the keyword w; The data owner initializes a pseudo-random puncture function GGM tree node node for each position pos in remain_pos, sets the node's position attribute index to pos, sets the node's height attribute level to the height T.level of the GGM tree T, and then puts these nodes into the node set node_list; The data owner uses the pseudo-random puncture function GGM tree algorithm min_coverage(node_list) to reduce the nodes in node_list to the optimal coverage node set remain_node; The data owner uses the pseudo-random puncture function GGM tree algorithm derive_key(T,sk,node.index,node.level) to calculate the symmetric key sk corresponding to each node node in the optimal coverage node set remain_node j , set the symmetric key attribute key of node to sk j ; The data owner sends the token, the upload count counter corresponding to the token, the keyword w to the IPFS storage index set Addrs, the optimal coverage node set remain_node and the pseudo-random puncture function GGM tree T tree height T.level to form a search trapdoor and sends it to the blockchain, and transfers the search fee to the search contract account; Execute the search contract, receive the token, take out the token upload count s_counter recorded on the blockchain from the set Cs[token] stored on the blockchain, and compare it with the token upload count counter recorded by the owner of the received data. If counter is less than or equal to s_counter, it means that there is no new file upload corresponding to the token between the last two searches, and the secondary search process is directly triggered; if counter is greater than s_counter, it means that there is a new file upload corresponding to the token between the last two searches, and the search contract uses the received Addrs = {addr1, addr2, ..., addr d_counter }, from addr1, addr2, ..., addr d_counte Each time an addr is taken out i , from Map[addr i ]Remove the FileHashes i , then download the encrypted data document from IPFS to the collection Dict, and directly perform normal search processing; The secondary search process is as follows: using the data in the cache set Cache on the blockchain, removing the file identifiers that should be deleted from the records, obtaining the search results and sending them to the user; The normal search processing process is as follows: the search contract uses the dictionary Map stored on the blockchain to retrieve the IPFS file block FileHash corresponding to the keyword w, downloads the encrypted document corresponding to the keyword w from IPFS and removes the padding bits to the set Dict, then restores the packaged GGM tree node to the decryption key, decrypts the ciphertext, and deletes the revoked document during the decryption process, sends the deleted document set to the IPFS storage, and IPFS returns the FileHash value to update the dictionary Map stored on the blockchain. Finally, the search results are stored in the cache set Cache and then sent to the user.

8. A multi-user revocable and searchable encryption method based on blockchain according to claim 7, characterized in that: The secondary search process specifically includes the following steps: The search contract takes out the result set Res of the last search from the cache set Cache[token], which stores the file identifier / tag pair, i.e. (ind, tag), and takes out the tag list marked as deleted from the delete set Del[token]; The search contract removes all (ind, tag) containing the tag tag in Del[token] from the search result set Res; The search contract puts the processed search result set Res back into the cache set Cache[token], republishes the updated set to the blockchain, and then sends Res to the user.

9. A multi-user revocable and searchable encryption method based on blockchain according to claim 8, characterized in that: The normal search process specifically includes the steps: The search contract receives the optimal coverage node set remain_node and the pseudo-random puncture function GGM tree T tree height T.level, and uses the pseudo-random puncture function GGM tree algorithm compute_key(remain_node,T.level) to calculate the symmetric key node.key corresponding to all nodes in the node set remain_list, and puts it into the key storage set Keys. The symmetric key of each node is strictly stored in Keys[node.index]; The search contract starts from the count cnt=0, and increases by 1 each time until cnt is greater than counter, and then executes steps i to vi in ​​a loop: i. The search contract uses the hash function H2, the count cnt, and the token to calculate the label label←H2(cnt,token); ii. The search contract sets a flag flag = 0 to mark whether the file identifier ind is successfully decrypted during the decryption process of each tag tag; iii. The search contract takes out the ciphertext list ciphertext_list from the ciphertext storage set Dict[label], and takes out the tag tag from the tag storage set Tags[label]; iv. The search contract uses the Bloom filter list D with all positions set to 0 in the system setup, and uses the Bloom filter algorithm get_index(D,tag) to simulate all the positions corresponding to the tag tag obtained by running the algorithm get_index(D,tag) when the data owner encrypts, which is recorded as dec_pos here; v. The search contract decrypts each position pos in each dec_pos using the symmetric decryption algorithm Dec(ciphertext_list[pos],Keys[pos]). If the decryption is successful and the file identifier ind is obtained, the flag is set to 1, the (ind, tag) pair is stored in the search result set res, and the loop on dec_pos is terminated in advance; vi. After the search contract finishes the dec_pos loop, it checks the flag. If the flag is 0, it means that the file identifier ind has been deleted. The smart contract sets Tags[label] and Dict[label] to empty, completing the deletion operation. After the search contract ends the loop, the Dict after the deletion process is used as the updated encrypted data document and filled in blocks of size B and sent to IPFS. IPFS stores and returns the new FileHashes = {FileHash1, FileHash2, ..., FileHash j }, search for contract update Map[addr i ]←FileHashes={FileHash1,FileHash2,…,FileHash j }; After the search contract completes all loops corresponding to Addrs, it merges d_counter search result sets res into the total search result set Res, puts it into the cache set Cache[token], takes the token upload count counter recorded by the data owner as the token upload count s_counter recorded by the updated search contract, executes Cs[token]←counter, and re-uploads all updated sets to the blockchain; The search contract sends the total search result set Res to the user.

Images