Blockchain-based multi-keyword searchable encryption method and system

Abstract

This invention proposes a multi-keyword searchable encryption method and system based on blockchain, belonging to the field of information security technology. The method includes: S1: The trust center takes the security parameter λ as input and outputs the system parameter σ; S2: Update the blockchain-side dictionary set Dic1 and the cloud server-side dictionary set Dic2, send the updated encrypted file to the cloud server, and update the set U. p The process involves several steps: S1: Sending the search token to the blockchain; S2: The client generates a corresponding set of search tokens; S3: The cloud server performs the search and sends the results to the client, which then obtains the RCBF (Retrievable Content Token); S4: The blockchain obtains the BCBF (Best Content Token) based on the search token, and the two are verified. The verification result is then sent to the client; S5: If the verification is valid, the client filters the results and requests the actual file. This invention improves the efficiency of encrypted retrieval, enables reliable and fair verification of search results, and reduces communication and computation costs.

Description

Technical Field

[0001] This invention belongs to the field of information security technology, and specifically relates to a multi-keyword searchable encryption method and system based on blockchain. Background Technology

[0002] With the increasing demands for information security and privacy protection, especially in environments such as cloud computing and big data processing, traditional encryption methods face significant challenges. These methods typically require data to be decrypted after encryption before searches can be performed, leading to a conflict between efficiency and privacy protection.

[0003] Searchable symmetric encryption (SSE) improves query efficiency by directly searching for keywords in encrypted data, ensuring data confidentiality. Static SSE does not support many document operations required in practical applications, such as creation, updating, and deletion. Therefore, researchers have focused on dynamic searchable symmetric encryption (DSSE). However, in typical DSSE schemes, adversaries can use file injection attacks to recover retrieved keywords when data is dynamically updated, exposing critical information. Therefore, to defend against file injection attacks, forward security has been proposed to ensure that it is impossible to determine whether newly added files contain previously retrieved keywords.

[0004] If forward safety guarantees safety during addition, then safety during deletion is achieved by backward safety. Backward safety aims to prevent leaks related to deleted entities. Bost et al. proposed a formal definition of backward safety, while Ghareh Chamani et al. improved upon previous work in terms of computational cost and security level, proposing three new schemes. However, considering both forward and backward safety constructions often leads to significant communication overhead for updates, especially when considering both forms of safety simultaneously.

[0005] Verifiability of search results is another important research topic in SSE. Since cloud servers are untrusted and may return incorrect or incomplete results due to system failures or cost-saving measures, it is necessary to verify search results. In 2012, Chai proposed the concept of Verifiable Searchable Symmetric Encryption (VSSE) and constructed a word tree-based verifiable SSE scheme. Shi et al. proposed a multi-user SE scheme supporting dynamic updates and verification using B+ trees and counted Bloom filters. Wang et al. designed a VSE scheme using AVL trees, where stored path information verifies the correctness and completeness of search results. Wu et al. constructed a verifiable multi-user forward-secure SE scheme, implementing verification features using multi-set hash functions. While existing schemes creatively utilize novel data structures to aid verification, they all assume a trusted / specific entity to verify search results. However, this assumption may not always hold true in practical applications due to external / internal attacks or configuration errors. Furthermore, some verification mechanisms remain impractical in terms of performance. In recent research, some researchers have introduced blockchain-based methods into SE to verify search results, ensuring the fairness and reliability of the verification process.

[0006] However, the above-mentioned solutions can support basic single-keyword searches, while complex search expressions are a necessary requirement for efficient searches in reality. Although some DSSE solutions meet forward or backward security and guarantee join queries, they lack non-join query methods and the former two lack verification mechanisms. Summary of the Invention

[0007] To address the aforementioned technical problems, this invention provides a blockchain-based multi-keyword searchable encryption method, comprising the following steps:

[0008] Step S1: The Trust Center (TC) takes the security parameter λ as input and outputs the system parameter σ.

[0009] Step S2: Based on the given document, keywords, and key in σ, update the blockchain-side dictionary set Dic1 and the cloud server-side dictionary set Dic2 respectively, generate the counting Bloom filter lookup table CBFList, send the updated encrypted file to the cloud server, and send the update set U containing all updates to the cloud server. p Send to the blockchain;

[0010] Step S3: The client uses the keyword set (w1, w2, ..., w) from this query. q Generate the corresponding search token set searchtoken;

[0011] Step S4: The cloud server uses the search token and Dic2 to perform a search and obtain the search result R. search Concurrently sent to the client, the client responds to R search Decryption mapping yields the RCBF for this search;

[0012] Step S5: The blockchain obtains the BCBF for this search based on the search token, verifies it using RCBF and BCBF, and sends the verification result to the client;

[0013] Step S6: If the verification result is valid, the client filters the target subset and finally requests the real file from the cloud server.

[0014] Beneficial effects:

[0015] 1. This invention discloses a multi-keyword searchable encryption method based on blockchain, and designs a novel index structure stored on a server. This multi-chain radial structure allows the server to perform dual parallelism. The first layer enables the server to search each chain corresponding to the token in parallel. The second layer enables the cloud server to simultaneously find all corresponding password texts when restoring the previous state, while maintaining forward security and supporting backward security by encrypting the search results.

[0016] 2. This invention allows clients to save only the latest tokens for the keywords they need to query, greatly saving the client's storage costs and enabling efficient multi-keyword search. By using blockchain and count Bloom filters to verify search results, it enables join and non-joint queries within a precise range. Based on the search results from a large-scale database, the results are further cross-referenced with the client's target subset to ultimately obtain the required precise file. Attached Figure Description

[0017] Figure 1 This is a schematic diagram of a blockchain-based multi-keyword searchable encryption method according to the present invention;

[0018] Figure 2 This is a timing diagram of a blockchain-based multi-keyword searchable encryption method in an embodiment of the present invention;

[0019] Figure 3 This is a structural block diagram of a blockchain-based multi-keyword searchable encryption system according to the present invention. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention. Furthermore, the technical features involved in the various embodiments of this invention described below can be combined with each other as long as they do not conflict with each other.

[0021] This invention involves three entities: a client, a cloud server, and a blockchain. The client updates a file according to an update trapdoor and sends the updated encrypted file to the cloud server. Simultaneously, the client generates a set of search tokens based on the keyword set to be queried and sends them to the cloud server and the blockchain. The cloud server uses the search tokens to search for all matching data in parallel across a multi-chain radial structure and returns the results to the client. The client decrypts the server's results into the form of ind||op, maps each entry in the decrypted results to the form of RCBF, and then sends it to the blockchain. The blockchain compares and verifies the RCBF with its stored CBF evidence to achieve public verification. If the verification result is accepted, the client can further match the files in the target subset with the results in the RCBF to achieve both join and join-based queries. Based on the information provided above, the client is responsible for updating files and evidence, the cloud server is responsible for searching relevant files, and the blockchain is responsible for storing evidence and verifying search results.

[0022] Example 1

[0023] like Figure 1 As shown in the figure, an embodiment of the present invention provides a multi-keyword searchable encryption method based on blockchain, which includes the following steps:

[0024] Step S1: The Trust Center (TC) takes the security parameter λ as input and outputs the system parameter σ.

[0025] Step S2: Based on the given document, keywords, and key in σ, update the blockchain-side dictionary set Dic1 and the cloud server-side dictionary set Dic2 respectively, generate the counting Bloom filter lookup table CBFList, send the updated encrypted file to the cloud server, and send the update set U containing all updates to the cloud server. p Send to the blockchain;

[0026] Step S3: The client uses the keyword set (w1, w2, ..., w) from this query. q Generate the corresponding search token set searchtoken;

[0027] Step S4: The cloud server uses the search token and Dic2 to perform a search and obtain the search result R. searchConcurrently sent to the client, the client responds to R search Decryption mapping yields the RCBF for this search;

[0028] Step S5: The blockchain obtains the BCBF for this search based on the search token, verifies it using RCBF and BCBF, and sends the verification result to the client;

[0029] Step S6: If the verification result is valid, the client filters the target subset and finally requests the real file from the cloud server.

[0030] In one embodiment, step S1 above: The trust center TC takes the security parameter λ as input and outputs the system parameter σ, specifically including:

[0031] Step S11: The Trust Center (TC) generates a master key MK and a client's private key sk based on λ; the private key sk and the master key MK are XORed to generate sk′;

[0032] Step S12: h i There are four different hash functions, i∈[1,4]. The input length of the hash functions is the same, but the output results are different, but the result length is the same. F(·) is a pseudo-random function, and Enc(·) / Dec(·) is a symmetric encryption and decryption algorithm. The function F(·) is used to generate the encryption and decryption key of Enc(·) / Dec(·).

[0033] Step S13: Encapsulate F(·), Enc(·) / Dec(·) and MK into system parameter σ=(h i ∈[1,4], F(·), Enc(·) / Dec(·), MK).

[0034] This invention encrypts data using hash functions, pseudo-random functions, and symmetric encryption / decryption algorithms. It leverages the one-wayness and collision resistance of hash functions to protect data security and privacy.

[0035] In one embodiment, step S2 above involves updating the blockchain-side dictionary set Dic1 and the cloud server-side dictionary set Dic2 based on the given document, keywords, and key in σ, generating a counted Bloom filter lookup table CBFList, sending the updated encrypted file to the cloud server, and sending the update set U containing all updates to the cloud server. p Sending to the blockchain, specifically including:

[0036] Step S21: The client obtains k and k' respectively using a function based on sk and sk', and combines this with the current version number. Get the latest token for the current version ,in The dictionary set Dic1 is stored in the blockchain, and the client and cloud server access the contents of Dic1 by interacting with the blockchain.

[0037] Step S21 is shown in lines 1-4 of Algorithm 1 below.

[0038] Step S22: The client, according to Each keyword index pair in the current version is encrypted using a hash function h, resulting in two encrypted tuples. and The keyword index pair is formed by the document identifier f to be updated. i and keyword w j The binary tuple (w) j ,f i );

[0039] In step S12, h1 and h2 of the four hash functions are constructed with As input, we obtain the first type of encrypted index tuple. h3 and h4 with (m, Using this as input, we obtain the second type of encrypted index tuple. m is the sequence number of the files to be updated in this batch;

[0040] Step 22 is shown in lines 5-24 of Algorithm 1 below.

[0041] Step S23: The client will and Send it to the cloud server to update the cloud server dictionary set Dic2;

[0042] Step S24: While encrypting, the client will also add the current keyword w. j In the current version All encrypted keyword indexes are encapsulated into a triple ( ), and store in the updated set U p In, among them, The keyword is w j In the current version The mapping of the updated records; the updated set U p Send to the blockchain;

[0043] Among them, version number It is a randomly generated string of length λ, for example: F|Ig)%uLbwrX17GK <!nCfyiJvCsaS|H;kHg6+5 y, subscript This indicates the version number. Step S24 specifically includes the following sub-steps:

[0044] Step S241: From (DB(w j Read each update record from the (),op) , where DB(w j ) represents the changes made to w in this update. j The set of related index numbers (ind); op represents the add / delete operation of the index in this update;

[0045] Step S242: According to Map the ind to its op type. middle;

[0046] Step S243: Concatenate ind and op directly into strings, then encrypt them using a symmetric encryption algorithm to obtain the encrypted update record indop;

[0047] Step S244: will cover w j Triples of all related update records ( Stored in set U p In, and send to the blockchain;

[0048] Step S25: Blockchain according to U p , with the keyword w j The latest update record is saved to the count Bloom filter lookup table CBFList to facilitate verification operations in subsequent stages.

[0049] Algorithm 1: Index Building Algorithm

[0050] Client:

[0051] 1:

[0052] 2:

[0053] 3:

[0054] 4: and

[0055] 5:

[0056] 6:

[0057] 7: then

[0058] 8: set

[0059] 9: else

[0060] 10:

[0061] 11: end if

[0062] 12:

[0063] 13:

[0064] 14:

[0065] 15:

[0066] 16:

[0067] 17:

[0068] 18:

[0069] 19:

[0070] 20:

[0071] twenty one:

[0072] 22: end for

[0073] twenty three:

[0074] 24: end for

[0075] 25: Send to CS

[0076] 26: Send to CS

[0077] 27: Send to BC

[0078] This invention aims to improve data query efficiency by constructing an encrypted index structure.

[0079] In one embodiment, step S3 above: The client, based on the keyword set (w1, w2, ..., w) of this query... q Generate the corresponding search token set searchtoken, which specifically includes:

[0080] Step S31: The client obtains the version number from Dic1. ;

[0081] Step S32: For each keyword w j The client combines σ and Generate their respective search trapdoors These search tokens constitute the search token set searchtoken;

[0082] Step S33: The client sets the keyword sequence number j and the corresponding search trap. Combined into a binary ( ) j∈[1,q] It is sent to the cloud server and the blockchain.

[0083] In one embodiment, step S4 above: The cloud server uses the searchtoken and Dic2 to perform a search and obtain the search result R. search Concurrently sent to the client, the client responds to R search The RCBF obtained from this search is obtained by decryption mapping, specifically including:

[0084] Step S41: After receiving the query request, the cloud server retrieves the data from the tuple (...). ) j∈[1,q] The search tokens corresponding to each keyword are parsed. ;

[0085] Step S42: The cloud server performs parallel searches using the search token within a multi-chain radial index structure, specifically including:

[0086] Step S421: Obtained through h1 ,Will As the key value of Dic2;

[0087] Step S422: Due to It is by XOR h2 What was obtained, and It is Dic2[ The value of ];

[0088] Step S423: Obtain the following formula (1) Database size under status And the previous state of the link. :

[0089] ⊕ (1)

[0090] Step S424: For Each search record in the status includes:

[0091] Step S4241: Each search record corresponds to a number m, where m ∈ [1, ..., ... ];

[0092] Step S4242: (m, (obtained through h3) ,Will As the key value of Dic2;

[0093] Step S4243: Because It is composed of (m, XORing h4 What was obtained, and As Dic2[ The value of ];

[0094] Step S4244: Obtained through the following formula (2) Each search record in the status :

[0095] ⊕ (2)

[0096] Step S425: According to the following formula (3), Merge into keyword w j In the result set:

[0097] ← (3)

[0098] Step S426: After searching each relevant chain, merge all search results into R according to the following formulas (4)~(5). search In the middle, and perform a search of the previous state:

[0099] R search ← R search ∪ (4)

[0100] ← (5)

[0101] Step S425: For the next state Continue executing steps S421-S426 until all states on the chain have been searched.

[0102] Step S43: The cloud server will process the final search results on each independent chain. Merged into search results set R search In, and R searchSend to the client;

[0103] Step S44: The client will send R search Each update record in the data is decrypted as follows: The form;

[0104] Step S45: The client, according to... The operation type in the code simplifies the result to an Ind collection, where the operation type is either add or del, specifically including:

[0105] Step S451: The client, based on the decrypted... Extract ;

[0106] Step S452: If , then Add to the Ind collection;

[0107] Step S453: If , then Add to the del set;

[0108] Step S454: After processing each update record, simplify the Ind result set according to formula (6):

[0109] ← (6)

[0110] The multi-chain parallel retrieval of this invention involves a cloud server using a search token set (searchtoken) and a dictionary (Dic2) to perform iterative searches on each chain, ultimately obtaining the search result R. search .

[0111] Step S46: The client maps Ind to the count Bloom filter to obtain the RCBF reflecting the current search result;

[0112] Step S47: The client sends the RCBF to the blockchain for verification.

[0113] Algorithm 2: Search Algorithm

[0114] 1:

[0115] 2:

[0116] 3: do

[0117] 4:

[0118] 5:

[0119] 6:

[0120] 7:

[0121] 8:

[0122] 9:

[0123] 10:

[0124] 11:

[0125] 12:

[0126] 13: end for

[0127] 14:

[0128] 15:

[0129] 16: end while

[0130] 17: end for

[0131] 18: Send to Client

[0132] In one embodiment, step S5 above: The blockchain obtains the BCBF for this search based on the search token, verifies it using RCBF and BCBF, and sends the verification result to the client, specifically including:

[0133] Step S51: The blockchain determines each search token in the searchtoken set. Read the CBF corresponding to this keyword from CBFList. j ;

[0134] Step S52: Put all CBF j Add them one by one to BCBF;

[0135] Step S53: The blockchain compares BCBF and RCBF. If they are equal, the verification is successful and an Accept message is sent to the client. If they are not equal, the verification fails and a Reject message is sent to the client.

[0136] Algorithm 3: Verification of the Algorithm

[0137] 1: BCBF

[0138] 2:for each st do

[0139] 3: BCBF BCBF + CBFList[st]

[0140] 4:end for

[0141] 5: if RCBF == BCBF then

[0142] 6: Accept

[0143] 7: else

[0144] 8: Reject

[0145] 9: end if

[0146] The data verification in this invention is the process of blockchain verifying the simplified search result Index returned by the cloud server. The blockchain finds the corresponding CBF from the list CBFList based on the search token set searchtoken. j The summation yields BCBF. Then, it is compared with RCBF, which is mapped from the Ind set. If they are equal, the verification is successful, and an Accept message is sent to the client; otherwise, the verification fails, and a Reject message is sent to the client.

[0147] In one embodiment, step S6: If the verification result is valid, the client filters the target subset and finally requests the real file from the cloud server, specifically including:

[0148] Step S61: Determine whether the user's query type is a join query or a non-join query;

[0149] Step S62: If it is a join query, the target index number is selected by the Repeat algorithm; if it is a non-join query, the target index number is selected by the Check algorithm.

[0150] Step S63: Send the final set of target index numbers (Finalset) to the cloud server and request the actual files.

[0151] The target subset filtering of this invention refers to the client further filtering the target set based on the RCBF that reflects the characteristics of this search.

[0152] Figure 2 This is a timing diagram of a blockchain-based multi-keyword searchable encryption method in an embodiment of the present invention.

[0153] Example 2

[0154] like Figure 3 As shown, this embodiment of the invention provides a blockchain-based multi-keyword searchable encryption system, including the following modules:

[0155] The system parameter acquisition module 71 is used by the Trust Center (TC) to take the security parameter λ as input and output the system parameter σ.

[0156] Update module 72 is used to update the blockchain-side dictionary set Dic1 and the cloud server-side dictionary set Dic2 respectively based on the given document, keywords, and keys in σ, generate a counted Bloom filter lookup table CBFList, send the updated encrypted file to the cloud server, and send the update set U containing all updates to the cloud server. p Send to the blockchain;

[0157] The search token generation module 73 is used by the client to generate search tokens based on the keyword set (w1, w2, ..., w) for this query. q Generate the corresponding search token set searchtoken;

[0158] Search module 74 is used by the cloud server to perform searches using the search token and Dic2 to obtain search results R. search Concurrently sent to the client, the client responds to R search Decryption mapping yields the RCBF for this search;

[0159] Verification module 75 is used to verify the blockchain using RCBF and searchtoken, and sends the verification result to the client;

[0160] The filtering module 76 is used to filter the target subset if the verification result is valid, and finally request the real file from the cloud server.

[0161] A blockchain-based multi-key searchable encryption device includes one or more electronic devices, wherein the one or more electronic devices are used to implement a blockchain-based multi-key searchable encryption method, system, and device.

[0162] An electronic device includes: one or more processors; and a memory for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors enable the one or more processors to implement a blockchain-based multi-key searchable encryption method, system, and apparatus.

[0163] The above description is merely a specific embodiment of the present invention, enabling those skilled in the art to understand or implement this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, the present invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A multi-key searchable encryption method based on blockchain, characterized in that, include: Step S1: The Trust Center (TC) takes the security parameter λ as input and outputs the system parameter σ, which specifically includes: Step S11: The Trust Center (TC) generates a master key MK and a client's private key sk based on λ; the private key sk and the master key MK are XORed to generate sk′; Step S12: h i There are four different hash functions, i∈[1,4]. The input lengths of the hash functions are the same, but the output results are different, but the result lengths are the same. F(·) is a pseudo-random function, and Enc(·) / Dec(·) is a symmetric encryption and decryption algorithm. The function F(·) is used to generate the encryption and decryption keys of Enc(·) / Dec(·). Step S13: Encapsulate F, Enc(·) / Dec(·) and MK into system parameter σ=(h i ∈[1,4], F (·), Enc(·) / Dec(·), MK); Step S2: Based on the given document, keywords, and key in σ, update the blockchain-side dictionary set Dic1 and the cloud server-side dictionary set Dic2 respectively, generate the counting Bloom filter lookup table CBFList, send the updated encrypted file to the cloud server, and send the update set U containing all updates to the cloud server. p Sending to the blockchain, specifically including: Step S21: The client obtains k and k' respectively using a function based on sk and sk', and combines this with the current version number. Get the latest token for the current version ,in The contents of Dic1 are stored in the blockchain dictionary set, and the client and cloud server access the contents of Dic1 by interacting with the blockchain. Step S22: The client, according to Each keyword index pair in the current version is encrypted using a hash function h, resulting in two encrypted tuples. and The keyword index pair is formed by the document identifier f to be updated. i and keyword w j The binary tuple (w) j f i ); Step S23: The client will and Send it to the cloud server to update the cloud server dictionary set Dic2; Step S24: While encrypting, the client will also add the current keyword w. j In the current version All encrypted keyword indexes are encapsulated into a triple ( ), and store in the updated set U p In, among them, The keyword is w j In the current version The mapping of the updated records; the updated set U p Send to the blockchain; Step S25: The blockchain, based on U p , with the keyword w j The latest update record is saved to the count Bloom filter lookup table CBFList; Step S3: The client uses the keyword set (w1, w2, ..., w) from this query. q Generate the corresponding search token set searchtoken; Step S4: The cloud server uses the search token and Dic2 to perform a search and obtain the search result R. search Concurrently sent to the client, the client responds to R search Decryption mapping yields the RCBF for this search; Step S5: The blockchain obtains the BCBF for this search based on the search token, verifies it using RCBF and BCBF, and sends the verification result to the client; Step S6: If the verification result is valid, the client filters the target subset and finally requests the real file from the cloud server.

2. The blockchain-based multi-key searchable encryption method according to claim 1, characterized in that, Step S3: The client, based on the keyword set (w1, w2, ..., w) of this query, q Generate the corresponding search token set searchtoken, which specifically includes: Step S31: The client obtains the version number from Dic1. ; Step S32: For each keyword w j The client combines σ and Generate their respective search tokens These search tokens are combined into a search token set called searchtoken; Step S33: The client sends the keyword sequence number j and the corresponding search token. Combined into a binary ( ) j∈[1,q] It is sent to the cloud server and the blockchain.

3. The blockchain-based multi-keyword searchable encryption method according to claim 2, characterized in that, Step S4: The cloud server uses the search token and Dic2 to perform a search and obtain the search result R. search Concurrently sent to the client, the client responds to R search The RCBF obtained from this search is obtained by decryption mapping, specifically including: Step S41: After receiving the query request, the cloud server retrieves the data from the tuple (...). ) j∈[1,q] The search tokens corresponding to each keyword are parsed. ; Step S42: The cloud server performs parallel searches using the search token within a multi-chain radial index structure; Step S43: The cloud server will process the final search results on each independent chain. Merged into search results set R search In, and R search Send to the client; Step S44: The client will send R search Each update record in the data is decrypted as The form; Step S45: The client, according to... The operation type in the code will simplify the result into an Ind set, where the operation type is either add or del; Step S46: The client maps Ind to the count Bloom filter to obtain the RCBF reflecting the current search result; Step S47: The client sends the RCBF to the blockchain for verification.

4. The blockchain-based multi-key searchable encryption method according to claim 3, characterized in that, Step S5: The blockchain obtains the BCBF for this search based on the search token, verifies it using RCBF and BCBF, and sends the verification result to the client, specifically including: Step S51: The blockchain determines each search token in the searchtoken set. Read the CBF corresponding to this keyword from CBFList. j ; Step S52: Put all CBF j Add them one by one to BCBF; Step S53: The blockchain compares BCBF and RCBF. If they are equal, the verification is successful and an Accept message is sent to the client. If they are not equal, the verification fails and a Reject message is sent to the client.

5. The blockchain-based multi-key searchable encryption method according to claim 4, characterized in that, Step S6: If the verification result is valid, the client filters the target subset and finally requests the real file from the cloud server, specifically including: Step S61: Determine whether the user's query type is a join query or a non-join query; Step S62: If it is a join query, the target index number is selected by the Repeat algorithm; if it is a non-join query, the target index number is selected by the Check algorithm. Step S63: Send the final set of target index numbers (Finalset) to the cloud server and request the actual files.

6. A blockchain-based multi-keyword searchable encryption system, characterized in that, Includes the following modules: The system parameter acquisition module is used by the Trust Center (TC) to take the security parameter λ as input and output the system parameter σ, which specifically includes: Step S11: The Trust Center (TC) generates a master key MK and a client's private key sk based on λ; the private key sk and the master key MK are XORed to generate sk′; Step S12: h i There are four different hash functions, i∈[1,4]. The input lengths of the hash functions are the same, but the output results are different, but the result lengths are the same. F(·) is a pseudo-random function, and Enc(·) / Dec(·) is a symmetric encryption and decryption algorithm. The function F(·) is used to generate the encryption and decryption keys of Enc(·) / Dec(·). Step S13: Encapsulate F, Enc(·) / Dec(·) and MK into system parameter σ=(h i ∈[1,4], F (·), Enc(·) / Dec(·), MK); The update module is used to update the blockchain-side dictionary set Dic1 and the cloud server-side dictionary set Dic2 based on the given document, keywords, and keys in σ, respectively, generate a counted Bloom filter lookup table CBFList, send the updated encrypted file to the cloud server, and send the update set U containing all updates to the cloud server. p Sending to the blockchain, specifically including: Step S21: The client obtains k and k' respectively using a function based on sk and sk', and combines this with the current version number. Get the latest token for the current version ,in The contents of Dic1 are stored in the blockchain dictionary set, and the client and cloud server access the contents of Dic1 by interacting with the blockchain. Step S22: The client, according to Each keyword index pair in the current version is encrypted using a hash function h, resulting in two encrypted tuples. and The keyword index pair is formed by the document identifier f to be updated. i and keyword w j The binary tuple (w) j f i ); Step S23: The client will and Send it to the cloud server to update the cloud server dictionary set Dic2; Step S24: While encrypting, the client will also add the current keyword w. j In the current version All encrypted keyword indexes are encapsulated into a triple ( ), and store in the updated set U p In, among them, The keyword is w j In the current version The mapping of the updated records; the updated set U p Send to the blockchain; Step S25: The blockchain, based on U p , with the keyword w j The latest update record is saved to the count Bloom filter lookup table CBFList; The search token generation module is used by the client to generate search tokens based on the keyword set (w1, w2, ..., w) for this query. q Generate the corresponding search token set searchtoken; The search module is used by the cloud server to perform searches using the search token and Dic2 to obtain search results R. search Concurrently sent to the client, the client responds to R search Decryption mapping yields the RCBF for this search; The verification module is used to verify the blockchain using RCBF and searchtoken, and sends the verification results to the client. The filtering module is used to filter the target subset if the verification result is valid, and finally request the real file from the cloud server.

7. A blockchain-based multi-keyword searchable encryption device, characterized in that, It includes one or more electronic devices, wherein the one or more electronic devices are used to implement the method of any one of claims 1 to 5.

8. An electronic device, characterized in that, include: One or more processors; A memory for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the method of any one of claims 1 to 5.

Images