A robust forward-backward privacy joint symmetric searchable encryption method

Abstract

The application belongs to the field of computer science and technology, and proposes a robust forward-backward privacy joint symmetric searchable encryption method. Its main purpose is to solve the problems that some of the existing technologies have generated a great communication overhead, some cannot guarantee forward-backward privacy at the same time, some cannot guarantee robustness, and some cannot support joint query. After initialization on the client side and the server side, the client generates update operation association information according to the user input key, keyword and file, and sends a message to the server side. The server side executes the update operation according to the received message, and sends the operation return value to the client side. The client side completes the remaining steps of the update operation according to the return value. When the query operation is performed, the client side generates the information of the query operation and sends it to the server side, the server side performs the query operation and returns the result to the client side. Finally, the client side decrypts and clears the returned file set.

Description

Technical Field

[0001] This invention belongs to the field of computer science and technology, and specifically relates to a robust forward and backward privacy joint symmetric searchable encryption method. Background Technology

[0002] In recent years, with the development of mobile internet technology and the continuous upgrading of storage devices, the number of encrypted files stored on cloud servers has been increasing, giving rise to searchable encryption. Searchable encryption is a technology that enables efficient searching on encrypted data, ensuring user privacy information, namely the query keywords and the files returned by the server. However, early searchable encryption could only search on static encrypted datasets and did not support file addition or deletion, nor prevent the leakage of privacy information when updating files. When a user performs an update or query operation, attackers can obtain the user's past query privacy based on certain information returned by the server, such as whether the keyword has been searched. When a user performs a query operation, attackers can obtain the user's past update privacy based on the corresponding information, such as the user's deletion history. Furthermore, most solutions cannot simultaneously meet the above security requirements while supporting federated queries and robust operations, i.e., federated queries with multiple keywords and unreasonable update operations. Therefore, a forward-backward privacy-focused, dynamically symmetric searchable encryption technology that supports federated searches and guarantees robustness has become an urgent problem to solve.

[0003] Currently, in the field of symmetric searchable encryption, scholars both domestically and internationally have proposed several symmetric searchable encryption methods, mainly including: static searchable encryption schemes. Static searchable encryption schemes neither support updates to the encrypted dataset nor prevent privacy leaks caused by the update process; therefore, these schemes are not practical in real-world applications. Dynamic symmetric searchable encryption schemes. Dynamic symmetric searchable encryption schemes allow clients to arbitrarily add or delete files corresponding to keywords on the server. However, even when some privacy protection techniques are employed in symmetric searchable encryption, some of these methods incur significant computational overhead, some incur significant communication overhead, some cannot simultaneously guarantee forward and backward privacy, some cannot guarantee robustness, and some cannot support federated queries. Therefore, how to provide robust forward and backward symmetric searchable encryption schemes that support federated queries while ensuring efficiency and security is a problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0004] To address the limitations of symmetric searchable encryption methods, this invention proposes a robust forward-backward privacy-integrated symmetric searchable encryption method. This method primarily uses a Bloom filter to store information about added or deleted files, and employs pseudo-random functions, hash functions, and random states to generate information related to updating files. The robustness of the method is achieved through the use of a Bloom filter.

[0005] To achieve the above objectives, the present invention employs the following technical means:

[0006] This invention provides a robust forward-backward privacy joint symmetric searchable encryption method, comprising the following steps:

[0007] Step 1: Initialize the client. The client generates a key k based on the security parameters. t , sk and d, and initialize empty sets XSet and UpdCnt. XSet is used to store the latest file index ciphertext and status information of the keyword, and UpdCnt is used to store the number of files corresponding to the keyword;

[0008] Step 2: Perform client initialization. The server also performs initialization operations after the client initialization, including creating empty sets TSet and Dic. TSet stores the join hash of the keyword state hash, which connects the current and previous states. Dic stores the two Bloom filters corresponding to the keywords.

[0009] Step 3: The client generates update operation association information.

[0010] Step B1: When the system receives the user's key, keyword w, and corresponding file ind, it will generate a keyword token, file index ciphertext, token-index ciphertext concatenation hash h, and keyword token hash. If the client's operation is to add, the system will determine whether it is the first time adding, and then generate intermediate values ​​related to the keyword token, status, and file. and state connection hash Finally, the client will send a message to the server. ;

[0011] Step B2: When the server-side operation is deletion, the client does not generate any additional intermediate messages, but only sends a message containing the hash value and the keyword token hash to the server. This indicates that the client has not performed an add operation, and the preparation work for the update phase has been completed.

[0012] Step 4: Server-side update operation

[0013] Based on the message sent by the client, if both 'e' and 'u' in the message are not empty, it means that the client is performing an add operation. The server will check whether the file corresponding to the keyword has been added. If it has been added, no operation will be performed. Otherwise, the add operation will be performed and the key-value pair will be stored in TSet. If both 'e' and 'u' in the message are empty, it means that the client is performing a delete operation. The server will check whether the file corresponding to the keyword has been inserted and not deleted. If so, it will be mapped to the delete Bloom filter, and the server will send the operation return value 'b' to the client.

[0014] Step 5: The client completes the remaining steps of the update operation based on the operation return value b returned by the server. If the operation is add and the return value is 1, it means that the addition was successful. The client will increment the update counter by 1 and update the latest status and file index ciphertext corresponding to the keyword. If the operation is delete and the return value is 1, it means that the deletion was successful. The client will decrement the update counter by 1 and complete the update operation.

[0015] Step 6: Generation of Client Query Operation Information: After receiving the union query request, the client generates query operation information. It determines the keyword with the fewest occurrences in the current file, retrieves the corresponding latest state and file index ciphertext, then calculates the keyword token and keyword token hash for each keyword, and stores them in lists TokenList and TdLis. Finally, the client combines the lists TokenList, TdLis, and the latest state... Send to the server;

[0016] Step 7: After receiving the client's query request, the server performs the query operation. It initializes two empty sets to store the retrieved files and the files returned to the client. The server extracts the Bloom filter corresponding to each keyword and calculates the intermediate value, the previous state, and the file based on the keyword with the minimum update counter value. Then, the server determines whether the file meets all the query conditions. If it does, it adds the file to the returned file set. Finally, the server sends the retrieved files and the returned file set to the client.

[0017] Step 8: The client decrypts the file set returned by the server and adds the decrypted file indexes to the file index set. Then, the client uses another file set to perform a cleanup operation and re-adds the files to it.

[0018] In the above technical solution, the detailed implementation steps of client initialization in step 1 are as follows:

[0019] When the system first starts running, the client needs to perform an initialization operation, generating a client key k based on the security parameter λ. t sk and d, initialize sets XSet and UpdCnt, and set both sets to empty. XSet maps and stores the latest file index ciphertext and status information corresponding to the keyword w. UpdCnt stores the current number of files corresponding to the keyword w. t sk and d are both keys owned by the client, and k t The keyword token is used to encrypt keywords and generate a keyword token; sk is used to encrypt file indexes and generate file index ciphertext; d is used to hash the keyword token and generate a keyword token hash td.

[0020] In the above technical solution, the detailed implementation steps of server-side initialization in step 2 are as follows:

[0021] After the client initializes, the server performs corresponding initialization operations. The server initializes the sets TSet and Dic, setting them both to empty sets. The set TSet is used to store the state connection hashes corresponding to the key-value pair state hashes. ， The state connection hash connects the keyword state hash in the current state and the keyword state hash in the previous state. The set Dic is used to store the two Bloom filters corresponding to the keyword w.

[0022] In the above technical solution, the message generation algorithm executed according to the client's operation type in step 3, which involves generating update operation association information on the client, is as follows:

[0023] Step B1: When the system receives the user's key, keyword w, and corresponding file ind, it calculates the corresponding keyword token using a pseudo-random function on keyword w and file ind. and file index ciphertext Then, a hash function is used to... Calculate with the indexed ciphertext c to obtain and keyword token hash Next, retrieve the latest state corresponding to the keyword w from the set XSet. The ciphertext of the file index corresponding to this state Next, the system will identify the actions the client will take regarding the keywords. , H1() and H2() are random functions, and H1() and H2() are hash functions.

[0024] If the client's corresponding operation is "add", that is, the client wants to perform an "add" operation, the system first determines whether this "add" operation is the first "add" operation for this keyword (the system determines this by checking the latest state retrieved from XSet and whether the encrypted file is empty, as well as performing the above checks in reverse).

[0025] If this is the first time adding, a state will be randomly generated for the current keyword-file pair. Then, a hash function is used to hash the keyword token tw and the state. And the latest file index ciphertext Calculations are performed to obtain intermediate values ​​related to the keyword token, status, and file. and state connection hash ;

[0026] If this is not the first time it has been added, a state will be randomly generated for the current keyword-file pair. As the latest state, then use a hash function to hash the keyword token tw and the state. And the latest file index ciphertext Calculations are performed to obtain intermediate values ​​related to the keyword token, state, and file: keyword state hash. and state connection hash ;

[0027] At this point, the information generation for the client's operation of adding is complete. Since the intermediate value u and the state connection hash e are only generated when the client's operation is adding, the client sends a message to the server when the client's operation is adding. ;

[0028] Step B2: When the client's corresponding operation is deletion, the client does not generate any additional intermediate messages; instead, the client sends a message to the server. At this point, the preparation work for the client update phase has been completed. ⊥ represents the abort symbol, indicating that the client has not generated the keyword state hash u and the state connection hash e, which means that the client has not performed the add operation.

[0029] In the above technical solution, the detailed implementation steps of the server-side update operation in step 4 include:

[0030] Based on the message generated by the client in step 3 and sent to the server. The server retrieves the 'td' from the message, and then extracts two Bloom filters from the set Dic that contain the keyword corresponding to the 'td'. If set Dic does not have a corresponding Bloom filter for td, then create and delete Bloom filters for td, so that... ;

[0031] Based on the received message, the specific process executed by the server-side update algorithm is as follows:

[0032] Step C1: If both 'e' and 'u' in the message received by the server are not empty, it indicates that the client performed an add operation. At this point, check if message 'h' is empty. Whether a match was found, h represents the associated message between the keyword token and the file index ciphertext.

[0033] If a match is found, it means that the file corresponding to the keyword has been added. The system does not perform any operation and sets the operation return value b to 0.

[0034] Otherwise, it means the file corresponding to the keyword has not been added, so the add operation is performed, and the key-value pair is added. Stored in TSet, i.e. Then map h to the added Bloom filter Finally, the return value b is set to 1;

[0035] Step C2: If both 'e' and 'u' in the message received by the server are empty, it indicates that the client is performing a deletion operation. First, check if 'h' is a match. Missed ,Right now and If the file corresponding to the keyword has been inserted but not deleted, then 'h' will be mapped to the delete Bloom filter. Then, the system sets the operation return value b to 1. For the cases where the Bloom filter is BF1[h]=1 and BF2[h]=1, BF1[h]≠1 and BF2[h]=1, or BF1[h]≠1 and BF2[h]≠1, the system will only set the operation return value b to 0 and will not perform any other operations. At this point, the server-side update operation is complete, and the server will send the operation return value b back to the client.

[0036] In the above technical solution, step 5, the client update operation, specifically includes the following steps:

[0037] Based on the return value 'b' returned by the server to the client in step 4, the client continues to complete the remaining steps of the update operation. The specific two processes are as follows:

[0038] Step D1: If the client's operation is "add", and the server returns a value b of 1, indicating successful addition, the client increments the update counter UpdCnt corresponding to the keyword w by 1. This indicates that an add operation was performed on the keyword w, and then the XSet corresponding to the keyword w was updated, that is, the latest state of the keyword w and the latest file index ciphertext were updated. ;

[0039] Step D2: If the client's operation is deletion, and the server returns a value b of 1, indicating successful deletion, the client decrements the update counter UpdCnt corresponding to the keyword w by 1. This indicates that a deletion operation has been performed on the keyword, and the client update operation is now complete.

[0040] In the above technical solution, the generation of information for the client query operation in step 6 specifically includes:

[0041] First, the client receives a combined query containing n keywords. The system then sets the keyword token list TokenList and the td storage list TdList to empty lists, and then determines the keyword with the fewest occurrences in the current file. Then, take out The latest corresponding status And the latest file index ciphertext, then for each keyword Calculate the corresponding keyword tokens respectively. and the corresponding And store them in TokenList and TdList respectively, that is and Then, the client will store TokenList, TdList, and the latest state. Send to the server.

[0042] In the above technical solution, the detailed implementation steps of the server-side query operation in step 7 are as follows:

[0043] Upon receiving a message from the client, the server initializes an empty set. empty set The set R stores the files returned to the client, and the set I stores all retrieved files. The server retrieves two Bloom filters corresponding to each keyword w, first updating the keyword with the smallest update counter value. Corresponding keyword tokens and the latest status calculate and Based on the calculated intermediate value u, extract its corresponding e in TSet, and then use e and The previous state and the previous file corresponding to the keyword are calculated, that is... Then the server calculates Then, the system determines Did it hit the keyword? The corresponding delete Bloom filter If the Bloom filter is not hit, it means the file corresponding to the keyword has not been deleted, and the current file will be... Add it to collection I, then check the remaining keyword tokens in TokenList. If the remaining keyword tokens correspond to... If the file matches the corresponding add Bloom filter but not the corresponding delete Bloom filter, it means the file satisfies all the query conditions, and the system will then process the file. The file is added to set R, and the system continues to iterate until the previous state of the obtained keyword is ⊥. The system then returns the two file sets to the client.

[0044] In the above technical solution, the detailed implementation steps for generating the client query results in step 8 are as follows:

[0045] Client-initiated file index set Then the client decrypts the files in set R and adds the decrypted file indexes to the file index set ID. Finally, the client uses set I to perform a cleanup operation, that is, to remove the keywords in set I. The corresponding files were added again.

[0046] Because the present invention adopts the above-described technical solution, it has the following beneficial effects:

[0047] This invention addresses the issues of robustness, forward and backward privacy, and joint query in searchable encryption schemes by proposing a robust forward and backward privacy DSSE scheme called RFBC. RFBC can effectively handle unreasonable update requests from clients, ensuring robustness, and simultaneously achieving forward and backward security. Its advantages include the following:

[0048] 1) A robust forward and backward privacy-secure dynamic joint symmetric searchable cryptographic scheme, RFBC, is proposed. This scheme satisfies forward privacy and, while balancing efficiency and security, also satisfies Type-III backward privacy.

[0049] 2) The proposed solution supports multi-keyword joint queries. Furthermore, the solution is robust, meaning that while ensuring forward and backward privacy, it can handle some unreasonable client requests, such as adding or deleting files that have already been added.

[0050] 3) Compared with other robust forward and backward safety DSSE schemes, the scheme proposed in this paper has significantly reduced computational overhead and also has certain advantages in communication overhead. Attached Figure Description

[0051] Figure 1 This is an overall structural diagram corresponding to the method described in this invention;

[0052] Figure 2 A schematic diagram illustrating client-server update operations;

[0053] Figure 3 Update time for different schemes under different amounts of updated data;

[0054] Figure 4 Search time for different schemes under different updated data volumes;

[0055] Figure 5 The system's communication overhead under different schemes and different amounts of updated data;

[0056] Figure 6 This is a diagram illustrating the functions supported by the present invention. Detailed Implementation

[0057] The embodiments of the present invention will be described in detail below. Although the present invention will be described and illustrated in conjunction with some specific embodiments, it should be noted that the present invention is not limited to these embodiments. On the contrary, any modifications or equivalent substitutions made to the present invention should be covered within the scope of the claims of the present invention.

[0058] Furthermore, to better illustrate the present invention, numerous specific details are set forth in the following detailed embodiments. Those skilled in the art will understand that the present invention can be practiced without these specific details.

[0059] A robust forward-and-backward privacy joint symmetric searchable encryption method includes the following definitions:

[0060] Definition 1: TSet is a user-defined encrypted collection primarily used to store key-value pairs. The key of each pair represents the keyword token hash *u*, and the value represents the state join hash *e*. The numerical value represents the XOR of the hash value with the file index and the state. Its purpose is to retrieve the file corresponding to the keyword with the lowest update frequency in a join query.

[0061] Definition 2: An XSet is a user-defined encrypted collection primarily used to store key-value pairs corresponding to query keywords. Here, the key represents the keyword corresponding to the update operation, and the value of the key-value pair represents the latest state and the latest file index encrypted for that keyword. Its purpose is to detect whether the matched files contain the other keywords in the join query.

[0062] This invention provides a robust forward and backward privacy-joint symmetric searchable encryption method, which is jointly executed by a client and a server, and includes the following steps:

[0063] Step 1: Client Initialization. The client first needs to determine the keys kt, sk, d, set XSet, and set UpdCnt required for client operation, namely the key required to generate the keyword token, the key required to generate the encrypted file identifier, the key to generate the keyword token hash, the set storing the latest state corresponding to the keyword, the set storing the encrypted file identifier, and the set representing the keyword update counter.

[0064] The system continues execution and proceeds to step 2.

[0065] Step 2: Server-side initialization. The server determines the required sets TSet and Dic, namely the set used to store the state connection hash e and the set used to store the Bloom filter.

[0066] Step 3: The client generates update operation association information.

[0067] During system usage, the client requests an operation from the server: adding or deleting a file corresponding to a keyword. The client first preprocesses the keyword and its corresponding file, sending the processed information containing the keyword / file pair to the server. Upon receiving the request, the server processes the information and adds the relevant information to the corresponding Bloom filter. If the addition is successful, the server returns a value of 1. If the addition fails, the server returns a value of 0. The server then sends the return value back to the client. After receiving the return value, the client updates its counter accordingly.

[0068] Furthermore, if the operation the client wants to perform is to add, then proceed to step B1:

[0069] Step B1: If this is the first time adding a file, initial addition operation information is generated first. The system randomly selects a status value to represent the latest status of the keyword after adding the file corresponding to that keyword. Then, the system uses two different hash functions H2 and H3. First, H2 is used to calculate the keyword token hash. Then, the intermediate hash value calculated by hash function H3 is XORed with the combined hash of the encrypted file identifier and the initial status information (terminator) to obtain the status concatenation hash, which is used to obfuscate the file index ciphertext, that is, the keyword token, status information, and encrypted file identifier are contained in a single hash value.

[0070] If this is not the first time the item is added, non-initial addition operation information is generated first. Similar to the steps above, the system randomly selects a state value and calculates the keyword token hash. The intermediate hash value calculated using the hash function H3 is then XORed with the combined hash of the encrypted file identifier and the previous state information corresponding to that keyword to obtain the latest state connection hash.

[0071] If the client performs a delete operation, then proceed to step B2:

[0072] Step B2: The client does not generate any additional intermediate messages; the client sends a message to the server. Here, "⊥" indicates that the keyword state hash u and state link hash e have not been generated, meaning that the client has not performed an add operation. At this point, the preparation work for the client update phase is complete.

[0073] Step 4: Server-side update operation. First, the server receives the update request from the client. Based on the storage address of the Bloom filter calculated by the client in Step 2, the server retrieves the Bloom filter corresponding to the keyword to be operated on. Then, the server performs different operations for different client operation requests. Finally, the server sets the response return value according to the operation result and returns the return value to the client.

[0074] Furthermore, the specific steps for the server to handle add and delete requests from the client are as follows:

[0075] Step C1: The corresponding update operation is to add a file. The system determines whether the joint hash of the keyword token and the file index ciphertext is in the corresponding add Bloom filter. If it has been added, the return value is set to 0, indicating that no operation has been performed; otherwise, the corresponding information of the add Bloom filter is set to 1, and then the keyword token hash and state connection hash calculated in step 3 are stored in TSet as key-value pairs. Finally, the return value is set to 1, indicating that the update operation has been performed.

[0076] Step C2: The corresponding update operation is file deletion. The system determines whether the joint hash of the keyword token and the file index ciphertext is in the corresponding add Bloom filter and not in the corresponding delete Bloom filter. If deleted, the return value is set to 0; otherwise, the server sets the corresponding information of the delete Bloom filter to 1, and then sets the return value to 1, indicating that the deletion operation has been performed.

[0077] Step 5: Client Update Operation. If the client sends an add request and the server returns 1 in Step 4, the client increments the update counter corresponding to the keyword and stores the latest status information and the latest updated encrypted file identifier for that keyword in the set XSet. If the client sends a delete request and the server returns 1 in Step 4, the client decrements the update counter corresponding to the keyword.

[0078] Step 6: Generation of client query information. When performing a combined keyword query, the client first determines the keyword with the smallest value in the file update counter UpdCnt (assuming it is...). Then, based on keywords Get keywords from the XSet collection. The latest status information is then used to calculate the tokens for all query keywords, and... The latest status information, token list TokenList, and Bloom filter address information TdList are sent to the server.

[0079] Step 7: Server-side query operation. After receiving the information sent by the client in Step 6, the server initializes two empty sets R and I. Based on the received messages, the server can retrieve... For all previously added encrypted file identifiers, each time an encrypted file identifier is retrieved, the following check is performed: if the file identifier is not in the keyword... In the deletion Bloom filter, the encrypted file identifier will be... Add to set I, then determine the encrypted file identifier. The relationship with other keywords, if If it contains other keywords and has not been deleted by the deletion operation of other keywords, then... Add it to set R. The server then sends set R and set I to the client.

[0080] Step 8: Client Query Result Generation. The client initializes an empty set ID as the file index set to store the queried file index results. After receiving sets R and I returned by the server in Step 7, the client uses its private key to decrypt the ciphertext of the file index in set R and adds the decrypted ciphertext to the file index set ID. After performing a search, the client needs to use set I to... The relevant files will be cleared, that is, the keywords in I will be removed. The corresponding files need to be added again.

[0081] In this example, such as Figure 1 and Figure 2 As shown, the main participants are the client and the server. A robust forward-and-backward privacy joint symmetric searchable encryption method mainly includes eight processes: client initialization, server initialization, client generation of update operation association information, server update operation, client update operation, generation of client query operation information, server query operation, and client query result generation, as detailed below:

[0082] A robust forward-and-backward privacy-preserving joint symmetric searchable encryption method mainly includes eight processes: client initialization, server initialization, client generation of update operation association information, server update operation, client update operation, generation of client query operation information, server query operation, and client query result generation, as detailed below:

[0083] Step 1: Client Initialization

[0084] When the system first starts running, the client needs to perform an initialization operation, generating a client key k based on the security parameter λ. tsk and d, initialize sets XSet and UpdCnt, and set both sets to empty. XSet maps and stores the latest file index ciphertext and status information corresponding to the keyword w. UpdCnt stores the current number of files corresponding to the keyword w. t sk and d are both keys owned by the client, and k t Used to encrypt keywords and generate keyword tokens; sk is used to encrypt file indexes and generate file index ciphertext; d is used to hash keyword tokens and generate keyword token hash td.

[0085] Step 2: Server-side initialization

[0086] After the client is initialized, the server performs the corresponding initialization operations. The server initializes the sets TSet and Dic, setting them to empty sets. The set TSet is used to store the state connection hash corresponding to the keyword state hash in the form of key-value pairs. This state connection hash connects the keyword state hash in the current state and the keyword state hash in the previous state. The set Dic is used to store the two Bloom filters corresponding to the keyword w.

[0087] Step 3: The client generates update operation association information.

[0088] The client generates update operation association information based on the operation to be performed, and sends different information to the server. The specific process of generating update operation association information when adding is as follows:

[0089] When the system receives the user's key, keyword w, and corresponding file ind, it calculates the corresponding keyword token using a pseudo-random function. and file index ciphertext Then, a hash function is used to... The token-index ciphertext concatenation hash is obtained by calculating the hash with the index ciphertext c. and keyword token hash H1() and H2() are hash functions, and then the latest state corresponding to the keyword w is retrieved from the set XSet. The ciphertext of the file index corresponding to this state Next, the system will identify the actions the client will take regarding the keywords. , It is a random function.

[0090] Furthermore, the system executes a message generation algorithm based on the client's operation type:

[0091] Step B1: If the client's corresponding operation is "add", that is, the client wants to perform an "add" operation, the system first determines whether this "add" operation is the first "add" operation for this keyword (the system determines this by checking the latest state retrieved from XSet and whether the encrypted file is empty, and by performing the above checks in reverse).

[0092] If this is the first time adding, a state will be randomly generated for the current keyword-file pair. Then, a hash function is used to hash the keyword token tw and the state. And the latest file index ciphertext Calculations are performed to obtain intermediate values ​​related to the keyword token, status, and file. and state connection hash ;

[0093] If this is not the first time it has been added, a state will be randomly generated for the current keyword-file pair. As the latest state, then use a hash function to hash the keyword token tw and the state. And the latest file index ciphertext Calculations are performed to obtain intermediate values ​​related to the keyword token, state, and file: keyword state hash. and state connection hash ;

[0094] At this point, the information generation for the client's operation of adding is complete. Since the intermediate value u and the state connection hash e are only generated when the client's operation is adding, the client sends a message to the server when the client's operation is adding. ;

[0095] Step B2: When the client's corresponding operation is deletion, the client does not generate any additional intermediate messages; instead, the client sends a message to the server. At this point, the preparation work for the client update phase is complete. ⊥ represents the abort symbol, indicating that the client has not generated the keyword state hash u and the state connection hash e, meaning the client has not performed an add operation.

[0096] Step 4: Server-side update operation

[0097] Based on the message generated by the client in step 3 and sent to the server. The server retrieves the message 'td' (which contains information about the keyword token, and thus information about the keyword 'w'), and then extracts two Bloom filters from the dictionary 'Dic' for the keyword corresponding to 'td'. If set Dic does not have a corresponding Bloom filter for td, then create two Bloom filters for td: an add Bloom filter and a delete Bloom filter, so that... .

[0098] Furthermore, based on the received message, the specific process executed by the server-side update algorithm is as follows:

[0099] Step C1: If both messages e and u received by the server are not empty, it indicates that the client performed an add operation. At this time, the system determines that message h is in... Whether a match is found depends on whether 'h' represents the associated message between the keyword token and the file index ciphertext.

[0100] If a match is found, it means that the file corresponding to the keyword has been added. The system does not perform any operation and sets the operation return value b to 0.

[0101] Otherwise, it means the file corresponding to the keyword has not been added, and the system will perform the add operation, adding the key-value pair. Stored in TSet, i.e. Then map h to the added Bloom filter Finally, the return value b is set to 1.

[0102] Step C2: If both messages e and u received by the server are empty, it indicates that the client has performed a deletion operation. The system first checks whether h is a match. Missed ,Right now and If the file corresponding to the keyword has been inserted but not deleted, the system will map 'h' to the delete Bloom filter. Then, the system sets the operation return value b to 1. For cases other than those described above, the system sets the operation return value b to 0 and performs no other operations. At this point, the server-side update operation is complete, and the server sends the operation return value b back to the client.

[0103] Step 5: Client update operation

[0104] Based on the return value 'b' returned by the server to the client in step 4, the client continues to complete the remaining steps of the update operation. The specific two processes are as follows:

[0105] Step D1: If the client's operation is "add", and the server returns a value b of 1, indicating successful addition, the client increments the update counter UpdCnt corresponding to the keyword w by 1. This indicates that an add operation was performed on the keyword w, and then the XSet corresponding to the keyword w was updated, that is, the latest state of the keyword w and the latest file index ciphertext were updated. ;

[0106] Step D2: If the client's operation is deletion, and the server returns a value b of 1, indicating successful deletion, the client decrements the update counter UpdCnt corresponding to the keyword w by 1. This indicates that a deletion operation has been performed on the keyword, and the client update operation is now complete.

[0107] Step 6: Generating information for client query operations

[0108] First, the client receives a combined query containing n keywords. The system then sets the keyword token list TokenList and the td storage list TdList to empty lists, and then determines the keyword with the fewest occurrences in the current file (let's assume it's td). Immediately afterwards, take out The corresponding latest status and latest file index ciphertext. Then for each keyword... Calculate the corresponding keyword tokens respectively. and the corresponding And store them in TokenList and TdList respectively, that is and Then, the client will store TokenList, TdList, and the latest state. Send to the server.

[0109] Step 7: Server-side query operation

[0110] Upon receiving a message from the client, the server initializes two collections. The set R stores the files returned to the client, and the set I stores all retrieved files. The server retrieves two Bloom filters corresponding to each keyword w, first based on the keyword... Corresponding keyword tokens and the latest status calculate and Based on the calculated u, retrieve its corresponding e in TSet, and then use e and... The previous state and the previous file corresponding to the keyword are calculated, that is... Then the server calculates. Then, the system makes a judgment. Did it hit the keyword? The corresponding delete Bloom filter If the Bloom filter is not hit, it means the file corresponding to the keyword has not been deleted, and the current file will be... Add it to collection I, then check the remaining keyword tokens in TokenList. If the remaining keyword tokens correspond to... If the file matches the corresponding add Bloom filter but not the corresponding delete Bloom filter, it means the file satisfies all the query conditions, and the system will then process the file. The file is added to set R, and the system continues to iterate until the previous state of the obtained keyword is ⊥. The system then returns both file sets to the client.

[0111] Step 8: Generating client query results

[0112] Client-initiated file index set Then the client decrypts the files in set R and adds the decrypted file indexes to the file index set ID. Finally, the client uses set I to perform a cleanup operation, that is, to remove the keywords in set I. The corresponding files were added again.

[0113] This invention considers an attacker who is primarily honest and curious on the server side, aiming to obtain the user's keyword privacy. This solution assumes the client is honest and requires the solution to satisfy both forward and backward privacy. Simultaneously, for the client, we require it to be able to effectively handle unreasonable update requests. Therefore, we analyze the privacy protection capabilities of our system from the perspective of forward and backward privacy, and also analyze its robustness. The specific security analysis of the RFBC method is as follows:

[0114] 1) In the RFBC method, each reasonable addition of keyword file pairs generates a random state, making it impossible for the server to predict the next state. Similarly, each reasonable deletion of keyword file pairs is performed using hash values, preventing the server from obtaining any plaintext information about the keyword file pairs. Furthermore, when updates are unreasonable, the RFBC method filters out these unreasonable requests. Thus, the RFBC method guarantees forward privacy and robustness.

[0115] 2) In our system, after a joint search, RFBC deletes the file containing the keyword with the smallest update counter value. Even if the server saves past search tokens and other relevant information, it cannot find the previously deleted file. Therefore, the RFBC method guarantees backward privacy.

[0116] As can be seen from the above analysis, during the user query process, the server cannot infer any information about the keywords updated by the user, nor can it associate the keywords with the file. Therefore, the RFBC method described in this invention can defend against server-side probing of messages.

[0117] Since a user's trajectory includes their location, ensuring the privacy of their trajectory further guarantees the privacy of their location. Through experiments verifying continuous user queries, we assume that the LSP can obtain the user's location information in real time, i.e., obtain the user's trajectory. Our experiment uses randomly generated keyword-file data pairs; the keywords in the data pairs are 26 letters, and the files are randomly generated 16-byte strings. Figure 6 The functional comparison of the RFBC scheme designed in this invention with the ROSE scheme [1], BDXT scheme [2], and ODXT scheme [2] is shown. At the same time, we compare it with the BDXT scheme [2] and ODXT scheme [2] during the experiment.

[0118] 1) Update time

[0119] To demonstrate that the system does not negatively impact user experience when used for update operations, we evaluated the response time of the proposed RFBC scheme. We tested the system response time as the update data volume linearly varied from 200,000 to 1,000,000. The response time results are as follows: Figure 3 As shown in the figure, we can observe that the service response time increases with the amount of updated data. This is because an increase in the amount of updated data requires the server or client to perform more message calculations. Since our solution uses relatively few AES and hash operations, our system provides a better user experience compared to existing solutions for update operations.

[0120] 2) Search time

[0121] To demonstrate that our system does not negatively impact user experience when used for multi-keyword combined searches, we evaluated the response time of the proposed RFBC scheme. We tested the system response time as the updated data volume linearly varied from 200,000 to 1,000,000. The response time results are as follows: Figure 4 As shown in the figure, the service response time increases slightly with the increase in the amount of updated data. This is because the increase in the amount of updated data causes the server or client to traverse more files when retrieving messages. However, our system can filter out unreasonable update operations from the client, so this solution will not impose an additional burden on the user or degrade the user experience.

[0122] 3) Communication overhead of query operations

[0123] To demonstrate that the scheme has no impact on system overhead when users use our system for multi-keyword combined search operations, we evaluated the communication overhead of the RFBC scheme proposed in this invention for search operations. We tested the system communication overhead when the update data volume varied linearly from 200,000 to 1,000,000. The test results for communication overhead are as follows: Figure 5 As shown in the figure, we can observe that as the data volume increases, the system's communication overhead also gradually increases. Since both the messages sent by the client to the server and the messages sent by the server to the client are related to the data volume, the more data is updated, the more messages are sent. Therefore, the communication overhead gradually increases with the data volume. However, the solution of this invention significantly reduces the communication overhead compared to existing solutions, and the incremental overhead is also relatively small. Therefore, the solution of this invention will not burden the system during user operation.

Claims

1. A robust forward-and-backward privacy joint symmetric searchable encryption method, characterized in that, Includes the following steps: Step 1: Initialize the client. The client generates a key k based on the security parameters. t , sk and d, and initialize empty sets XSet and UpdCnt. XSet is used to store the latest file index ciphertext and status information of the keyword, and UpdCnt is used to store the number of files corresponding to the keyword; Step 2: Perform server-side initialization. The server-side also performs initialization operations after the client-side initialization, including creating an empty set TSet and an empty set Dic. TSet stores the join hash of the keyword state hash, which joins the current and previous states. Dic stores the two Bloom filters corresponding to the keywords. Step 3: The client generates update operation association information. Step B1: When the system receives the user's key, keyword w, and corresponding file ind, it will generate a keyword token, file index ciphertext, token-index ciphertext concatenation hash h, and keyword token hash. If the client's action is to add, the system will determine whether it is the first time adding, and then generate intermediate values ​​related to the keyword token, status, and file. and state connection hash Finally, the client will send a message to the server. ; Step B2: When the client's operation is deletion, the client does not generate any additional intermediate messages, but only sends a message containing the hash value and the keyword token hash to the server. This indicates that the client has not performed an add operation, and the preparation work for the update phase has been completed. Step 4: Server-side update operation Based on the message sent by the client, if both 'e' and 'u' in the message are not empty, it means that the client is performing an add operation. The server will check whether the file corresponding to the keyword has been added. If it has been added, no operation will be performed. Otherwise, the add operation will be performed and the key-value pair will be stored in TSet. If both 'e' and 'u' in the message are empty, it means that the client is performing a delete operation. The server will check whether the file corresponding to the keyword has been inserted and not deleted. If so, it will be mapped to the delete Bloom filter, and the server will send the operation return value 'b' to the client. Step 5: The client completes the remaining steps of the update operation based on the operation return value b returned by the server. If the operation is add and the return value is 1, it means that the addition was successful. The client will increment the update counter by 1 and update the latest status and file index ciphertext corresponding to the keyword. If the operation is delete and the return value is 1, it means that the deletion was successful. The client will decrement the update counter by 1 and complete the update operation. Step 6: Generation of Client Query Operation Information: After receiving the union query request, the client generates query operation information. It determines the keyword with the fewest occurrences in the current file, retrieves the corresponding latest state and file index ciphertext, then calculates the keyword token and keyword token hash for each keyword, and stores them in lists TokenList and TdLis. Finally, the client combines the lists TokenList, TdLis, and the latest state... Send to the server; Step 7: After receiving the client's query request, the server performs the query operation. It initializes two empty sets to store the retrieved files and the files returned to the client. The server extracts the Bloom filter corresponding to each keyword and calculates the intermediate value, the previous state, and the file based on the keyword with the minimum update counter value. Then, the server determines whether the file meets all the query conditions. If it does, it adds the file to the returned file set. Finally, the server sends the retrieved files and the returned file set to the client. Step 8: The client decrypts the file set returned by the server and adds the decrypted file indexes to the file index set. Then, the client uses another file set to perform a cleanup operation and re-adds the files to it.

2. The robust forward-backward privacy joint symmetric searchable encryption method according to claim 1, characterized in that, The detailed implementation steps for client initialization in step 1 are as follows: When the system first starts running, the client needs to perform an initialization operation, generating a client key k based on the security parameter λ. t sk and d, initialize sets XSet and UpdCnt, and set both sets to empty. XSet maps and stores the latest file index ciphertext and status information corresponding to the keyword w. UpdCnt stores the current number of files corresponding to the keyword w. t sk and d are both keys owned by the client, and k t The keyword token is used to encrypt keywords and generate a keyword token; sk is used to encrypt file indexes and generate file index ciphertext; d is used to hash the keyword token and generate a keyword token hash td.

3. A robust forward-and-backward privacy joint symmetric searchable encryption method according to claim 1, characterized in that, The detailed implementation steps of server-side initialization in step 2 are as follows: After the client is initialized, the server performs the corresponding initialization operations. The server initializes the sets TSet and Dic, setting them to empty sets. The set TSet is used to store the state connection hash corresponding to the keyword state hash in the form of key-value pairs. This state connection hash connects the keyword state hash in the current state and the keyword state hash in the previous state. The set Dic is used to store the two Bloom filters corresponding to the keyword w.

4. A robust forward-and-backward privacy joint symmetric searchable encryption method according to claim 1, characterized in that, In step 3, the message generation algorithm is executed based on the client's operation type when generating update operation association information, as follows: Step B1: When the system receives the user's key, keyword w, and corresponding file ind, it calculates the corresponding keyword token using a pseudo-random function on keyword w and file ind. and file index ciphertext Then, a hash function is used to... Calculate with the indexed ciphertext c to obtain and keyword token hash Next, retrieve the latest state corresponding to the keyword w from the set XSet. The ciphertext of the file index corresponding to this state Next, the system will identify the actions the client will take regarding the keywords. , H1() and H2() are random functions, and H1() and H2() are hash functions. If the client's corresponding operation is "add", that is, the client wants to perform an "add" operation, the system first determines whether this "add" operation is the first time the keyword has been added. If this is the first time adding, a state will be randomly generated for the current keyword-file pair. Then, a hash function is used to hash the keyword token tw and the state. And the latest file index ciphertext Calculations are performed to obtain intermediate values ​​related to the keyword token, status, and file. and state connection hash ; If this is not the first time it has been added, a state will be randomly generated for the current keyword-file pair. As the latest state, then use a hash function to hash the keyword token tw and the state. And the latest file index ciphertext Calculations are performed to obtain intermediate values ​​related to the keyword token, state, and file: keyword state hash. and state connection hash ; At this point, the information generation for the client's operation of adding is complete. Since the intermediate value u and the state connection hash e are only generated when the client's operation is adding, the client sends a message to the server when the client's operation is adding. ; Step B2: When the client's corresponding operation is deletion, the client does not generate any additional intermediate messages; instead, the client sends a message to the server. At this point, the preparation work for the client update phase has been completed. ⊥ represents the abort symbol, indicating that the client has not generated the keyword state hash u and the state connection hash e, which means that the client has not performed the add operation.

5. A robust forward-and-backward privacy joint symmetric searchable encryption method according to claim 1, characterized in that, The detailed implementation steps of the server-side update operation in step 4 include: Based on the message generated by the client in step 3 and sent to the server. The server retrieves the 'td' from the message, and then extracts two Bloom filters from the set Dic that contain the keyword corresponding to the 'td'. If set Dic does not have a corresponding Bloom filter for td, then create and delete Bloom filters for td, so that... ; Based on the received message, the specific process executed by the server-side update algorithm is as follows: Step C1: If both 'e' and 'u' in the message received by the server are not empty, it indicates that the client performed an add operation. At this point, check if message 'h' is empty. Whether a match was found, 'h' indicates the associated message between the keyword token and the file index ciphertext. If a match is found, it means that the file corresponding to the keyword has been added. The system does not perform any operation and sets the operation return value b to 0. Otherwise, it means the file corresponding to the keyword has not been added, so the add operation is performed, and the key-value pair is added. Stored in TSet, i.e. Then map h to the added Bloom filter Finally, the return value b is set to 1; Step C2: If both 'e' and 'u' in the message received by the server are empty, it indicates that the client is performing a deletion operation. First, check if 'h' is a match. Missed ,Right now and If the file corresponding to the keyword has been inserted but not deleted, then 'h' will be mapped to the delete Bloom filter. Then, the system sets the operation return value b to 1. For the cases where the Bloom filter is BF1[h]=1 and BF2[h]=1, BF1[h]≠1 and BF2[h]=1, or BF1[h]≠1 and BF2[h]≠1, the system will only set the operation return value b to 0 and will not perform any other operations. At this point, the server-side update operation is complete, and the server will send the operation return value b back to the client.

6. A robust forward-and-backward privacy joint symmetric searchable encryption method according to claim 1, characterized in that, Step 5, the client update operation, specifically includes the following steps: Based on the return value 'b' returned by the server to the client in step 4, the client continues to complete the remaining steps of the update operation. The specific two processes are as follows: Step D1: If the client's operation is "add", and the server returns a value b of 1, indicating successful addition, the client increments the update counter UpdCnt corresponding to the keyword w by 1. This indicates that an add operation was performed on the keyword w, and then the XSet corresponding to the keyword w was updated, that is, the latest state of the keyword w and the latest file index ciphertext were updated. ; Step D2: If the client's operation is deletion, and the server returns a value b of 1, indicating successful deletion, the client decrements the update counter UpdCnt corresponding to the keyword w by 1. This indicates that a deletion operation has been performed on the keyword, and the client update operation is now complete.

7. A robust forward-and-backward privacy joint symmetric searchable encryption method according to claim 1, characterized in that, The generation of information for the client query operation in step 6 specifically includes: First, the client receives a combined query containing n keywords. The system then sets the keyword token list TokenList and the td storage list TdList to empty lists, and then determines the keyword with the fewest occurrences in the current file. Then, take out The latest corresponding status and the latest file index ciphertext c i Then for each keyword Calculate the corresponding keyword tokens respectively. and the corresponding And store them in TokenList and TdList respectively, that is and Then, the client will use TokenList, TdList, and The latest corresponding status Send to the server.

8. A robust forward-and-backward privacy joint symmetric searchable encryption method according to claim 1, characterized in that, The detailed implementation steps of the server-side query operation in step 7 are as follows: Upon receiving a message from the client, the server initializes an empty set. empty set The set R stores the files returned to the client, and the set I stores all retrieved files. The server retrieves two Bloom filters corresponding to each keyword w, first updating the keyword with the smallest update counter value. Corresponding keyword tokens and the latest status calculate and Based on the calculated intermediate value u, extract its corresponding e in TSet, and then use e and The previous state and the previous file corresponding to the keyword are calculated, that is... Then the server calculates , This represents the combined hash value of the keyword token corresponding to the keyword with the smallest update counter value and the token-index ciphertext concatenation hash of the file index ciphertext. Then, the system determines... Did it hit the keyword? If the corresponding Bloom filter is not matched, it means the file corresponding to the keyword has not been deleted, and the current file will be deleted. Add it to collection I, then check the remaining keyword tokens in TokenList. If the remaining keyword tokens correspond to... If the file matches the corresponding add Bloom filter but not the corresponding delete Bloom filter, it means the file satisfies all the query conditions, and the system will then process the file. The file is added to set R, and the system continues to iterate until the previous state of the obtained keyword is ⊥. At this point, the system returns the two file sets to the client.

9. A robust forward-and-backward privacy joint symmetric searchable encryption method according to claim 1, characterized in that, The detailed implementation steps for generating client query results in step 8 are as follows: Client-initiated file index set Then the client decrypts the files in set R and adds the decrypted file indexes to the file index set ID. Finally, the client uses set I to perform a cleanup operation, that is, to remove the keywords in set I. The corresponding files were added again.

Images