A Multi-User Revocable Searchable Encryption Method Based on Blockchain

Abstract

The present invention discloses a multi-user revocable searchable encryption method based on blockchain, which relates to the fields of blockchain and searchable encryption technologies. The method includes: a system establishment stage, a user management stage, an update stage, and a search stage. By adopting blockchain technology and IPFS decentralized storage, the immutability of system information is guaranteed, and the risk of privacy leakage is reduced. By introducing a homomorphic exclusive-or function and verifying after wrapping the user identifier, a multi-user application scenario is realized, the interaction efficiency of the system is improved, and the security and reliability under multiple users are also ensured; by introducing a Bloom filter and a pseudorandom puncturing function, the operability of file identifiers is improved, and a secure and efficient key generation and transmission mechanism is designed in cooperation; for file deletion, a revocation mechanism is added, and a secondary search mechanism is emphatically designed, reducing the update and search overhead, thereby improving the overall performance of the system.

Description

Technical Field

[0001] The present invention relates to blockchain technology and searchable encryption technology, and particularly relates to a multi-user revocable 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 utilized, resulting in an explosive growth in the data scale. Along with this, there is a substantial increase in the demand for data storage. To effectively address this demand, more organizations and individuals choose to outsource data to a third-party cloud storage platform for storage to reduce storage costs. However, the outsourcing of data storage increases the risk of data leakage. To reduce the risk of data leakage, researchers have introduced data encryption to ensure the confidentiality of data, thereby achieving secure outsourcing storage of data. Further, for data to generate value, it also needs to be effectively utilized, which requires providing accurate data for specific data analysis. How to accurately locate the required data in encrypted data has become an urgent problem to be solved. To solve this problem, researchers have introduced searchable encryption technology.

[0003] In Dynamic Symmetric Searchable Encryption (DSSE), it is allowed that a client encrypts a set of data and outsources it to an untrusted smart contract. Generally speaking, the way of data encryption is to efficiently search data without sacrificing data and query privacy. And SSE obtains better efficiency at the cost of allowing partial information leakage captured by a specific leakage function.

[0004] However, even in the case of a small amount of leakage, the adversary will also be able to infer sensitive information hidden in the data. In other words, if the adversary obtains part of the file content or keywords in the file of some data owners, the adversary can infer the queries made by the client from the leakage function. Subsequently, a file injection attack emerged. This attack can obtain the complete client query with only a small number of injected files, threatening the security of the dynamic searchable encryption scheme. Therefore, the concepts of forward privacy and backward privacy were proposed. Forward privacy ensures that previous search queries cannot be associated with future updates, and 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 and their implementation efficiency for single-user and multi-user scenarios.

[0005] To reduce the time overhead of verifying the search result return, as well as issues such as the security of the search trapdoor and search efficiency, blockchain has also been introduced in the field of searchable encryption. The blockchain and the smart contracts deployed on it achieve decentralization and possess excellent properties such as immutability. Coupled with the gradually mature decentralized storage InterPlanetary File System (IPFS), it solves problems such as high risks of traditional storage privacy leakage. Summary of the Invention

[0006] The purpose of the present invention is to overcome the deficiencies of the prior art and provide a multi-user revocable searchable encryption method based on blockchain, which ensures the immutability of system information and reduces the risk of privacy leakage.

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

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

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

[0010] User management UserControl phase: including adding users and deleting users. When a user needs to be added, the user submits a registration application to the data owner. The data owner generates a unique identifier u id and a random number r i for the user, and secretly stores them in the User set. Using the system key K u calculate the user key k i and return it to the user; When a user needs to be deleted, the data owner deletes the user from the User set;

[0011] Update phase: The data owner charges the user an update fee. For the document corresponding to the keyword w, use the homomorphic exclusive-or function f to calculate the keyword search status tw; According to the keyword search status tw, retrieve the master key sk of the pseudo-random puncturing function GGM tree corresponding to the keyword w from the set E; Use the file identifier ind and the user identifier u idAfter hashing, the tag is obtained; the Bloom filter algorithm is used to map the tag, and combined with the pseudo-random puncturing function GGM tree to generate an encryption key. After all data documents are encrypted, the data owner pads all encrypted documents neatly and sends them to the IPFS distributed database for storage; after the data owner receives the FileHash value calculated by IPFS, an update-upload trapdoor is generated and sent to the blockchain, and an update fee is transferred to the update contract account to execute the update contract for upload processing; or the file identifier to be deleted is revoked, an update-delete trapdoor is generated and sent to the blockchain, and an update fee is transferred to the update contract account to execute 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 exclusive-or function f for verification to obtain the keyword search status tw, and extracts the master key sk of the GGM tree and the keyword w from E[tw]; uses the Bloom filter combined with the pseudo-random puncturing function GGM tree to generate a decryption key and packages it 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 process or a normal search process.

[0013] Furthermore, the specific steps of the Setup phase established by the system include:

[0014] The data owner initializes multiple sets for storing user data, including a set C for storing the upload times of each keyword corresponding to each user, a set D of Bloom filter lists corresponding to each keyword, a random number r corresponding to each user i and the set User of identifiers u id a set E of pairs (sk, w) of the master key sk of the pseudo-random puncturing function GGM tree and the keyword w corresponding to each keyword, a set EDB of all encrypted document ciphertext_list, a set Cd of the upload times of the keyword w data document set DB(w), a set OTags of tags tag for updating processing in cooperation with the smart contract, and a set Odel of tags tag for deleting processing in cooperation with the smart contract; all sets are set to be empty;

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

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

[0017] The data owner publishes the smart contract to the blockchain, initializes the sets Map, Tags, Dict, Del, Cs, which are used to store the FileHash values of the IPFS storage file blocks corresponding to the keyword w, the tags tag uploaded by the data owner, the list of encrypted document identifiers downloaded by the smart contract from IPFS, the tags tag that each user needs to delete for the corresponding keyword, the number of uploads of each user corresponding to the keyword recorded on the blockchain, and sets the fees required to execute the contract on the blockchain;

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

[0019] The smart contract initializes a list of Bloom filters D, which is used to cooperate with the update and search operations of the data owner.

[0020] Furthermore, the UserControl phase specifically includes:

[0021] Adding a user: The data owner generates a user identifier u λ from {0,1} id and a random number r i , and secretly stores them in the User set; the data owner calculates the user key k for each registered user using the system key i ←K u ⊕r i , and sends it to the user through a secure channel;

[0022] Deleting a user: The data owner deletes the corresponding identifier u of the user id and the random number r i from the User set.

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

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

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

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

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

[0028] Upload files: The data owner combines the pseudo-random puncturing function GGM tree to generate an encryption key. After all data documents are encrypted, all encrypted documents are filled in blocks neatly and sent to the IPFS distributed database for storage; after the data owner receives the FileHash value calculated by IPFS, generate an update-upload trapdoor and send it to the blockchain, and transfer the update fee to the update contract account to execute the update contract for upload processing; or revoke the file identifier that needs to be deleted;

[0029] Delete files: The data owner generates an update-delete trapdoor and sends it to the blockchain, and transfers the update fee to the update contract account to execute the update contract for deletion processing.

[0030] Furthermore, the uploading of files includes the steps of:

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

[0032] The data owner uses the pseudo-random puncturing 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 uses the symmetric encryption algorithm Enc(ind, sk index ) to encrypt the file identifier ind to obtain the ciphertext ct index , put it into the corresponding position ciphertext_list[index] of the ciphertext list, and all ciphertexts form the ciphertext list ciphertext_list;

[0033] The data owner calculates the identifier label←H2(counter, token) using the hash function H2, the upload count counter, and the token;

[0034] The data owner returns the Bloom filter list D to the set D[w], and returns the incremented upload count counter + 1 to the set C[token];

[0035] The data owner places the tag into the sets OTags[label] and ODel[token];

[0036] The data owner places the ciphertext_list in the encrypted document set EDB[label], sets the block size B, and if it is less than B, pads it with {0, 1} to the size of B, otherwise divides it into blocks, and pads the last block with {0, 1} to the size of B, and sends it to IPFS;

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

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

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

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

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

[0042] Furthermore, the specific steps for deleting a file include:

[0043] For each file identifier tag to be deleted, the data owner uses the Bloom filter algorithm add_tag(D,tag) to set all positions corresponding to the 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 as an update-deletion trapdoor to the blockchain and transfers the update fee to the update contract account;

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

[0047] Furthermore, the specific steps of the Search phase include:

[0048] The user generates a random number S from {0,1} λ and uses the homomorphic XOR function f, the random number S and the user key k i to calculate ST i1 = f ki (w⊕S), ST i2 = S, and sends the search token ST i = (ST i1 , ST i2 ) and the search fee to the data owner;

[0049] The data owner retrieves the user identifier u corresponding to the user from the user set User id and the random number r i , and uses 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, and obtains the keyword search status tw corresponding to the keyword w;

[0050] The data owner retrieves the pair (sk, w) from E[tw], that is, the master key sk of the pseudo-random puncturing 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 to calculate the flag token←H2(w,u id );

[0051] The data owner retrieves the Bloom filter list D from the set D[w], retrieves the upload count counter corresponding to the flag token from the set C[token], and retrieves d_counter from the set Cd[w]. If any of these parameters do not exist, it indicates 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, increments it by 1 each time, and performs a loop calculation addr←H2(w,d_cnt) until d_cnt is greater than d_counter, obtaining Addrs = {addr1,addr2,…,addr d_counter};

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

[0054] For each position pos in remain_pos, the data owner initializes a node of the pseudorandom puncturing function GGM tree, sets the position attribute index of the node to pos, sets the height attribute level of the node 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 pseudorandom puncturing function GGM tree algorithm min_coverage(node_list) to reduce the nodes in node_list to the node set remain_node with optimal coverage;

[0056] For each node node in the optimal coverage node set remain_node, the data owner calculates the symmetric key sk corresponding to the node using the pseudorandom puncturing function GGM tree algorithm derive_key(T,sk,node.index,node.level) j and sets the symmetric key attribute key of the node to sk j ;

[0057] The data owner sends the flag token, the upload count counter corresponding to the flag token, the keyword w to the IPFS storage index set Addrs, the optimal coverage node set remain_node, and the height T.level of the pseudorandom puncturing function GGM tree T as a search trapdoor to the blockchain and transfers the search fee to the search contract account;

[0058] Execute the search contract, receive the flag token, retrieve the upload count s_counter of the flag token recorded on the blockchain from the set Cs[token] stored on the blockchain, and compare it with the upload count counter corresponding to the flag token recorded by the received data owner. If counter is less than or equal to s_counter, it indicates that no new files corresponding to the flag token have been uploaded between the two recent searches, and the secondary search process is directly triggered. If counter is greater than s_counter, it indicates that new files corresponding to the flag token have been uploaded between the two recent searches. The search contract uses the received Addrs = {addr1, addr2, …, addr d_counter}, and each time extracts one addr from addr1, addr2, …, addr d_counte , and extracts the FileHashes i retrieved from Map[addr i , and then downloads the encrypted data document from IPFS to the set Dict and directly performs the normal search process; i

[0059] The secondary search process is as follows: Use the data in the cache set Cache on the blockchain, remove the file identifiers to be deleted recorded, and send the search results to the user;

[0060] The normal search 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, removes the padding bits, and stores it in the set Dict. Then, it restores the wrapped GGM tree nodes to decryption keys, decrypts the ciphertext, and implements the deletion process of the revoked documents during the decryption process. The document set after the deletion process is sent to IPFS for storage, IPFS returns the FileHash value to update the dictionary Map stored on the blockchain, and finally, the search results are stored in the cache set Cache and then sent to the user.

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

[0062] The search contract retrieves the previous search result set Res from the cache set Cache[token]. Res stores file identifier / tag pairs, i.e., (ind, tag), and retrieves the list of tags tag marked as deleted from the deletion 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 searching the loop for the end of the contract dec_pos, check the flag. If the flag is 0, it means that the file identifier ind has been deleted. The smart contract empties Tags[label] and Dict[label] to complete the deletion operation;

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

[0075] After the search contract ends all loops corresponding to Addrs, it merges the d_counter search result sets res into the total search result set Res, puts it into the cache set Cache[token], and uses the number of times counter that the data owner records the flag token upload as the number of times s_counter that the updated search contract records the flag token upload, and executes Cs[token] ← counter. Then it uploads all the updated sets back 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) By introducing blockchain technology and the decentralized IPFS distributed database, it ensures the immutability of system information and reduces the risk of privacy leakage.

[0079] 2) By using the homomorphic exclusive - or encryption function f, it realizes the permission control management of multiple users, thus completing the support for multi - user scenarios and making it more practical.

[0080] 3) By using the probabilistic data structure BloomFilter, it realizes the efficient mapping of file identifiers and key mapping. Through operations on the BloomFilter mapping list, the revocation operation of the file to be deleted can be achieved with minimal cost, greatly improving the efficiency of system update query and key generation.

[0081] 4) By using the pseudorandom puncturing function GGM tree, it realizes the efficient key generation and management.

[0082] 5) A detailed design is carried out for the secondary search, greatly improving the search efficiency. Brief Description of the Drawings

[0083] Figure 1 This is the system framework diagram of the present invention. Detailed Embodiments

[0084] Next, the technical solutions of the present invention will be clearly and completely described in conjunction with the embodiments. Obviously, the described embodiments are only a 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 efforts fall within the protection scope of the present invention.

[0085] Refer to Figure 1 , the present invention provides a technical solution:

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

[0087] System establishment Setup phase: The data owner performs initialization. The data owner initializes multiple sets C, D, User, E, EDB, Cd, OTags, Odel for storing user data, as well as the pseudo - random puncturing function GGM tree T and the system key K u ; The data owner publishes the update contract and the search contract to the blockchain, initializes the sets 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;

[0088] User management UserControl phase: including adding users and deleting users. When a user needs to be added, the user submits a registration application to the data owner. The data owner generates a unique identifier u id and a random number r i , and secretly stores them in the User set, and calculates the user key k u using the system key K i and returns it to the user; When a user needs to be deleted, the data owner deletes the user from the User set;

[0089] Update phase: The data owner charges the user an update fee. For the document corresponding to the keyword w, the data owner calculates the keyword search status tw using the homomorphic exclusive - or function f; Retrieves the master key sk of the pseudo - random puncturing function GGM tree corresponding to the keyword w from the set E according to the keyword search status tw; Using the file identifier ind and the user identifier u idAfter hashing, the tag is obtained; the Bloom filter algorithm is used to map the tag, and the encryption key is generated by combining the pseudorandom puncturing 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 the data owner receives the FileHash value calculated by IPFS, an update-upload trapdoor is generated and sent to the blockchain, and an update fee is transferred to the update contract account to execute the update contract for upload processing; or the file identifier to be deleted is revoked, an update-delete trapdoor is generated and sent to the blockchain, and an update fee is transferred to the update contract account to execute 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 exclusive-or function f for verification to obtain the keyword search status tw, and extracts the master key sk of the GGM tree and the keyword w from E[tw]; the decryption key is generated by combining the Bloom filter with the pseudorandom puncturing 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 secondary search processing or normal search processing.

[0091] The system framework diagram of the present invention is as Figure 1 shown, which includes four entities in this solution, and their names and functions are as follows:

[0092] Data Owner: It is a completely honest entity, and its behavior will not pose a threat to 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 submitting search requests to the data owner. After registering with the data owner, a unique identifier is obtained. The data owner uses the identifier to upload or delete files that can only be searched by this user;

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

[0095] IPFS Distributed Database: Responsible for storing and downloading encrypted data document blocks.

[0096] In a specific embodiment, the specific steps of the Setup phase of the system include:

[0097] The data owner initializes multiple sets for storing user data, including set C for storing the upload times of keywords corresponding to each user, set D for the list of Bloom filters corresponding to each keyword, random number r corresponding to each user i associated with identifier u id in set User, the master key sk of the pseudorandom puncturing function GGM tree corresponding to each keyword and the set E of keyword w pairs (sk, w), the set EDB of all encrypted document ciphertext_list, the set Cd of the upload times of the keyword w data document set DB(w), the set OTags of tags tag for cooperating with the smart contract update process, and the set Odel of tags tag for cooperating with the smart contract deletion process; all sets are set to empty;

[0098] The data owner initializes the pseudorandom puncturing function GGM tree T;

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

[0100] The data owner publishes the smart contract to the blockchain, initializes sets Map, Tags, Dict, Del, Cs, which are used to store the FileHash value of the IPFS storage file block corresponding to keyword w, the tag tag uploaded by the data owner, the list of encrypted document identifiers downloaded by the smart contract from IPFS, the tag tag that each user needs to delete for the corresponding keyword, and the upload times of each user's corresponding keyword recorded on the blockchain, and sets the fees required to execute the contract on the blockchain;

[0101] The smart contract initializes the cache set Cache for caching the set of search result indexes for the corresponding keyword of each user last time;

[0102] The smart contract initializes a list of Bloom filters D for cooperating with the update and search operations of the data owner.

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

[0104] Adding a user: The data owner generates user identifier u λ and random number r id from {0,1} i and secretly stores them in set User; the data owner calculates the user key k for each registered user using the system key i ← K u ⊕ r i and sends it to the user through a secure channel;

[0105] Delete user: The data owner deletes the identifier u corresponding to the user id and the random number r i from the User set.

[0106] In the Update phase, several common 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. This function has f ki (x1) ⊕ f kj (x2) = f ki⊕kj (x1 ⊕ x2), where k i and k j represent random keys with the same bit length. In this function, f ki (x1) and f kj (x2) perform an XOR operation on the random results output. The result is XOR-bound to the input value and then uses two random keys k i and k j The random output result generated after the XOR operation is equal.

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

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

[0110] (2) BF.add_tag(D, tag): Input the Bloom filter list D and the tag tag. The tag tag is mapped to h positions of the list D through h hash functions, and these positions are set to 1, and output the updated Bloom filter list D;

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

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

[0113] The specific algorithm of the pseudo-random puncturing 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 a position index, a height level, and a key key. The position and height are initialized accordingly. The key key is iteratively derived from the root node key sk. Calculate the tree height T.level and output an initialized GGM tree T;

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

[0116] (3) GGMTree.min_coverage(node_list): Input the node set node_list. According to the position and height information of its nodes, reduce the duplicate coverage between nodes by merging nodes with the same parent node and the same level, so as to find the node set with the smallest coverage rate, and output node_list updated to the optimal coverage node set.

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

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

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

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

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

[0122] Upload file: The data owner combines the pseudorandom puncturing function GGM tree to generate an encryption key. After all data documents are encrypted, all encrypted documents are filled in blocks neatly and sent to the IPFS distributed database for storage; after the data owner receives the FileHash value calculated by IPFS, generate an update-upload trapdoor and send it to the blockchain, and transfer the update fee to the update contract account to execute the update contract for upload processing; or revoke the file identifier to be deleted;

[0123] Delete file: The data owner generates an update-delete trapdoor and sends it to the blockchain, and transfers the update fee to the update contract account to execute the update contract for deletion processing.

[0124] Furthermore, the uploading of files includes the steps of:

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

[0126] The data owner uses the pseudorandom puncturing 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 uses the symmetric encryption algorithm Enc(ind,sk index ) to encrypt the file identifier ind to obtain the ciphertext ct index , put it into the corresponding position ciphertext_list[index] of the ciphertext list, and all ciphertexts form the ciphertext list ciphertext_list;

[0127] The data owner calculates the identifier label←H2(counter,token) using the hash function H2, the upload count counter, and the token;

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

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

[0130] The data owner places the ciphertext_list at the position of the encrypted document set EDB[label], sets the block size B, fills it with {0, 1} to the size of B if it is less than B, otherwise divides it into blocks, fills the last block with {0, 1} to the size of B, and sends it to IPFS;

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

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

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

[0134] Execute the update contract, execute FileHashes = {FileHash1, FileHash2, …, FileHash j} ← Map[addr], to implement the index of the keyword w to the IPFS stored 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 specific steps for deleting a file include:

[0137] For each tag 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 places the tag tag to be deleted into ODel[token];

[0139] The data owner sends the set ODel as an update-delete trapdoor to the blockchain 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 steps:

[0142] The user generates a random number S from {0, 1} λ and calculates ST using the homomorphic exclusive - or function f, the random number S, and the user's key k i ST i1 = f ki (w ⊕ S), where ST i2 = S, and the search token ST i =(ST i1 , ST i2 ) and the search cost are sent to the data owner;

[0143] The data owner retrieves the user identifier u corresponding to the user from the user set User id and the random number r i and calculates f ri (S) ⊕ ST i1 = f ri (S) ⊕ f ki (w ⊕ S)= f ri⊕ki (w)= f Ku (w)= tw, obtaining the keyword search status tw corresponding to the keyword w;

[0144] The data owner retrieves the pair (sk, w) from E[tw], that is, the master key sk of the pseudo - random puncturing 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 to calculate the flag token ← H2(w, u id );

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

[0146] The data owner starts from d_cnt = 0, increments it by 1 each time until d_cnt is greater than d_counter, and calculates addr ← H2(w, d_cnt) in a loop to obtain Addrs = {addr1, addr2, …, addr d_counter};

[0147] The data owner uses the Bloom filter algorithm search(D) to obtain all the positions remain_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 processing process is as follows: Use the data in the cache set Cache on the blockchain, remove the file identifiers to be deleted recorded, and send the search results 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, removes the padding bits, and then goes to the set Dict. Then, restore the wrapped GGM tree node to the decryption key, decrypt the ciphertext, and implement the deletion process of the revoked document during the decryption process. Send the processed document set to IPFS for storage. IPFS returns the FileHash value to update the dictionary Map stored on the blockchain. Finally, store the search results in the cache set Cache and then send them to the user.

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

[0156] The search contract retrieves the previous search result set Res from the cache set Cache[token]. Res stores file identifier / tag pairs, i.e., (ind, tag), and retrieves the list of tags tag marked as deleted from the deletion 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 processing specifically includes the steps;

[0160] The search contract receives the optimal coverage node set remain_node and the height T.level of the pseudo-random puncturing function GGM tree T, and uses the pseudo-random puncturing function GGM tree algorithm compute_key(remain_node, T.level) to calculate the symmetric keys node.key corresponding to all nodes in the node set remain_list, and put them 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, adds 1 each time until cnt is greater than counter, and loops to execute steps i - step vi:

[0162] i. The search contract calculates the identifier label ← H2(cnt, token) using the hash function H2, the count cnt, and the flag 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 retrieves the ciphertext list ciphertext_list from the ciphertext storage set Dict[label] and the tag tag from the tag storage set Tags[label];

[0165] iv. The search contract uses the Bloom filter list D initialized to 0 at all positions during the system setup Setup, and uses the Bloom filter algorithm get_index(D, tag) to simulate all positions corresponding to the tag tag obtained when the data owner encrypts by running the algorithm get_index(D, tag). Here, it is denoted as dec_pos;

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

[0167] vi. After the search contract ends the loop of dec_pos, it checks the flag flag. If flag is 0, it means that the file identifier ind has been deleted. The smart contract empties Tags[label] and Dict[label] to complete the deletion operation;

[0168] After the search contract ends the loop, it takes the updated encrypted data document Dict after the deletion process, fills it in blocks of size B, and sends it to IPFS. IPFS stores it and returns the new FileHashes = {FileHash1, FileHash2, …, FileHash j}, and the search contract updates Map[addr i ← FileHashes = {FileHash1, FileHash2, …, FileHash j};

[0169] After searching for all loops corresponding to the contract end Addrs, merge the d_counter search result sets res into the total search result set Res, put it into the cache set Cache[token], and upload the flag token upload count counter recorded by the data owner as the flag token upload count s_counter of the updated search contract record. Execute Cs[token]←counter, and re-upload all the 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 search encryption method based on blockchain. Under the premise of a multi-user scenario, it realizes the interaction among 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 for searchable encryption.

[0172] The innovations of the present invention include: 1. Introducing blockchain technology and decentralized IPFS distributed database to ensure the immutability of system information and reduce the risk of privacy leakage; 2. Utilizing the homomorphic exclusive-or encryption function f to realize the permission control management of multiple users, thus completing the support for multi-user scenarios and making it more practical; 3. Utilizing the probabilistic data structure BloomFilter to realize the efficient mapping of file identifiers and key mapping. Through the operation of the BloomFilter mapping list, the revocation operation of the file to be deleted can be realized with minimal cost, greatly improving the efficiency of system update query and key generation; 4. Utilizing the pseudorandom puncturing function GGM tree to realize efficient key generation and management; 5. Conducting a detailed design for secondary search, greatly improving the search efficiency.

[0173] The above are only the preferred embodiments of the present invention. It should be understood that the present invention is not limited to the form disclosed herein, should not be regarded as excluding other embodiments, but can be used in various other combinations, modifications, and environments, and can be changed within the scope of the concept described herein through the above teachings or the technology or knowledge in related fields. And the changes and modifications made by those skilled in the art that do not depart from the spirit and scope of the present invention should all be within the protection scope of the appended claims of 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