Boolean range query method supporting privacy protection of access mode and search mode

Abstract

The invention relates to the technical field of computer security, and discloses a Boolean range search method supporting access mode and search mode privacy protection, comprising the following steps: a cloud server receives a search request from a client; the cloud server receives an encryption index constructed by a data owner; the plurality of cloud servers search on the stored encrypted index according to the received search request to respectively obtain part of search results; and sending the obtained partial search results to the client for summation to obtain a final search result. On the basis of effectively protecting the privacy of the access mode and the search mode, efficient Boolean range search can be realized, and meanwhile, in the process of dynamically updating the data, forward security is realized, and the security of previous search is not influenced by data updating.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of computer security, and particularly relates to a Boolean range query method supporting access pattern and search pattern privacy protection. BACKGROUND

[0002] With the wide application of mobile devices and geographic positioning technology, location-based services are increasingly popular, and spatial keyword search has gradually become a research hotspot. For example, users input "nearby coffee shop" in the smart phone map application, and the system needs to return relevant results according to the current location of the user. At the same time, the rapid development of cloud computing promotes data outsourcing to cloud servers to become a trend of efficient data management. However, data privacy problems in the cloud environment are increasingly prominent, especially in the encrypted data search scenario, how to protect data confidentiality while achieving efficient ciphertext retrieval has become a core challenge in the field of searchable encryption.

[0003] In recent years, privacy protection solutions for spatial keyword search have received extensive attention. However, these solutions mainly focus on the implementation of privacy protection spatial keyword search, ignoring the problem of search pattern and access pattern leakage. Access pattern leakage may enable cloud servers to infer the frequency and order of user access to specific data, while search pattern leakage may expose user search intent and behavior patterns. By monitoring repeated search tokens or access logs of result documents, attackers can infer sensitive information and even reconstruct the original search content.

[0004] In order to solve the above problems, in recent years several innovative solutions have been proposed in the field of searchable encryption to protect search pattern and access pattern. However, many existing solutions still have certain limitations. At the same time, the importance of dynamic symmetric searchable encryption (DSSE) is increasingly prominent. DSSE enhances the manageability of encrypted data by supporting efficient dynamic updates, while strengthening privacy protection. It effectively prevents the association of data records with previous searches due to data updates, thereby achieving forward security. However, most existing searchable encryption schemes that support dynamic updates and forward security mainly focus on single keyword search or simple multi-keyword search, and the complex scenario of supporting Boolean range search remains an unsolved research challenge.

[0005] In summary, there are several key problems in the existing methods. Specifically, (1) most of the existing methods only improve search efficiency, but ignore the privacy protection of access pattern and search pattern. (2) Many existing schemes for protecting search pattern and access pattern are limited to keyword search and do not support range search, which cannot meet the complex search requirements. (3) Although dynamic searchable encryption enhances the manageability of encrypted data and strengthens privacy protection by supporting efficient dynamic updates, most existing searchable encryption schemes mainly focus on single-keyword search or simple multi-keyword search. For complex scenarios that support Boolean range search, it is still an unsolved research challenge. SUMMARY

[0006] The technical problem to be solved by the present application is to overcome the shortcomings of the prior art. The present application provides a Boolean range query method supporting access pattern and search pattern privacy protection, which can effectively protect the privacy of access pattern and search pattern, realize efficient Boolean range search, and realize forward security during dynamic data update, ensuring that data update does not affect the security of previous searches.

[0007] To achieve the above-mentioned purpose, the present application provides a Boolean range query method supporting access pattern and search pattern privacy protection, comprising the following steps: The cloud server receives a search request from the client; The cloud server receives an encrypted index built by the data owner; A plurality of said cloud servers search the stored encrypted index according to the received search request and obtain partial search results respectively; The obtained partial search results are sent to the client for summation to obtain the final search result; After each search, a plurality of said cloud servers jointly perform an index shuffling operation; After each search is completed, the data owner reassigns the corresponding index according to the search result, and the cloud server updates the index stored by itself according to the reassignment of the index, realizing the unlinkability of the search result; The index reassignment operation is: the data owner receives new ID field data sent by the client, and the new ID field data is generated by the client aggregating the search results of each said cloud server and randomly splitting; the data owner sends the new ID field to the cloud server, and the cloud server replaces the locally stored old ID field with the new ID field.

[0008] Preferably, the index shuffling operation is performed between the cloud servers and the cloud servers . Each of the cloud servers re-encrypts the keyword field and the prefix field using proxy re-encryption and secret shuffle parameters, the ID field is further randomized by general re-encryption, and each index entry is shuffled by random permutation to hide the position; A tag is added in each index entry to indicate the index shuffle state, and during each index shuffle, the cloud servers And the cloud servers Re-randomize the tag using a pseudo-random function F, and pass the tag to the client to help the client generate a new search token consistent with the current shuffled index entry.

[0009] Preferably, the cloud server receives a search request from the client, including: The client generates a search token by secret key , state And And shuffle parameters And ; The search token is randomized by TPF.Rnd algorithm, so that repeated searches for the same query keyword or query range prefix generate different search tokens; The cloud server re-encrypts the search token, so that the search token generated by the secret key Matches the keyword or prefix field encrypted by the cloud server using the master key ; The re-encryption step specifically includes: When the index item of the keyword field or prefix field queried by the client is shuffled to state Or , the key value of the index item is converted from To Or ; The cloud server converts the keyword field value or prefix key field value to Or Using the authorization key To match the field value of the shuffled index item.

[0010] Preferably, the cloud server searches the stored encrypted index according to the received search request, and obtains partial search results respectively, including: According to the search token received from the client, two cloud servers search the respective stored encrypted index; The cloud server re-encrypts the search token into a master token using the authorization key, and searches the index item using the master token; The cloud server then partially decrypts the searched ID field and sends it to another cloud server; Another cloud server completely decrypts the ID field, extracts the object's ID, and locates the corresponding encrypted data; Another cloud server returns encrypted data to the client, and the client's final search result is a combination of the search results from the two cloud servers.

[0011] Preferably, the cloud server receives an encrypted index constructed by the data owner, including: The encrypted index includes an encrypted prefix-ID index and an encrypted keyword-ID index; Each encrypted index is split into two encrypted sub-indexes to protect the search pattern. Specifically, the prefix field and keyword field remain unchanged, while only the ID field corresponding to the encrypted index is split, and then the two sub-indexes are sent to the cloud server. and the cloud server ; The cloud server and the cloud server Each stores an encrypted subprefix-ID index and an encrypted subkeyword-ID index.

[0012] Preferably, before the first search and after each subsequent search, multiple cloud servers jointly perform an index shuffling operation, including: The index shuffling operation is performed by the cloud server. and the cloud server Collaborative processing; For the cloud server : The cloud server Send the two stored inverted indexes to the cloud server. ; The cloud server The received inverted index is re-encrypted using its own parameters, and the two inverted indexes are rearranged before being sent to the cloud server. ; The cloud server The received inverted index is re-encrypted and rearranged using its own parameters; In each of the cloud servers, the keyword, prefix, and ID fields are encrypted using re-encryption. Each cloud server updates its ciphertext by re-encrypting the index entries and randomly rearranging each entry to change its position, so that the search token changes with each search, preventing the cloud server from inferring search patterns.

[0013] Preferably, the cloud server updates its stored index according to the reassigned index, including: The client generates an update token based on the status of the updated keyword or updated location, and the cloud server performs an index update operation on the locally stored encrypted index based on the update token.

[0014] Preferably, the client generates an update token based on the status of the updated keyword or updated location, including: For newly added objects Each keyword in or each prefix The client initializes two empty bitmaps and randomly selects one to mark the newly added object. ID information; The client encrypts it using TPF and TUR. To hide the location of the updated index entry, the client applies a permutation function to the original update token. Remove keyword, prefix, and ID fields; If the update token contains new keywords (i.e.) If the update token is not associated with any existing index entry, it ensures that no information is leaked. The update token is not replaced, and the keyword and ID fields are directly added to the index. The client ultimately generates four update tokens and sends them to the cloud server respectively. and the cloud server .

[0015] Preferably, the cloud server performing an index update operation on the locally stored encrypted index based on the update token includes: Update the prefix-ID index and the keyword-ID index. Specifically, the steps for updating the prefix-ID index are as follows: The cloud server Replace the stored index entries and send the replaced index to the cloud server. ; The cloud server Update the replaced index using the update token; The cloud server use Replace the index entries, remove the prefix field, re-encrypt the ID field, and send the sorted index to the cloud server. ; The cloud server Re-encrypt the ID field of the index entry that has not been updated, and return the entire index to the cloud server. ; The cloud server use Restore the order of the index entries and insert the newly added prefix index entry.

[0016] By adopting the above technical solution, this application has the following beneficial effects compared with the prior art: This application effectively hides access and search patterns by employing index shuffling and index reallocation strategies, preventing cloud servers from inferring users' search intent and behavioral patterns. Utilizing inverted indexes, Hilbert curves, and prefix encoding techniques, this application supports not only keyword search but also Boolean range search, achieving sublinear search efficiency and good scalability to meet more complex search needs. Furthermore, through homomorphic encryption and index reallocation techniques, this application supports dynamic data updates and ensures forward security, effectively preventing information leakage caused by data updates.

[0017] This application achieves high-efficiency search performance while ensuring high security, providing an innovative solution for privacy-preserving data search in cloud environments. It enables Boolean range search while protecting access and search modes.

[0018] The specific embodiments of this application will be described in further detail below with reference to the accompanying drawings. Attached Figure Description

[0019] The accompanying drawings, which form part of this application, are used to provide a further understanding of the application. The illustrative embodiments and descriptions of the application are used to explain the application, but do not constitute an undue limitation of the application. Obviously, the drawings described below are merely some embodiments, and those skilled in the art can obtain other drawings based on these drawings without creative effort.

[0020] In the attached diagram: Figure 1 This is a flowchart illustrating the Boolean range query method that supports privacy protection for access and search modes in this specific embodiment. Figure 2 This is another flowchart illustrating the Boolean range query method that supports privacy protection for access and search modes in this specific embodiment. Figure 3 This is a schematic diagram of the index shuffling process of the Boolean range query method that supports privacy protection for access mode and search mode in this specific embodiment. Figure 4 This is a diagram of the prefix-ID index structure for the Boolean range query method that supports privacy protection for access and search modes in this specific embodiment; Figure 5 This is a keyword-ID index structure diagram for the Boolean range query method that supports access mode and search mode privacy protection in this specific embodiment. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions in the embodiments will be clearly and completely described below with reference to the accompanying drawings. The following embodiments are used to illustrate this application, but are not intended to limit the scope of this application.

[0022] Please see Figure 1 and Figure 2 This application provides a Boolean range query method that supports privacy protection for access modes and search modes, including the following steps: The cloud server receives search requests from the client; The cloud server receives an encrypted index built by the data owner; Multiple cloud servers search the stored encrypted index based on the received search request and obtain partial search results respectively; The obtained partial search results are sent to the client for summation to obtain the final search results; After each search, multiple cloud servers jointly perform an index shuffling operation; After each search is completed, the data owner reallocates the corresponding index based on the search results, and the cloud server updates its stored index based on the reallocated index, thus achieving the unlinkability of the search results. The index reassignment operation is as follows: The data owner receives the new ID field data sent by the client. The new ID field data is generated by the client aggregating the search results of each cloud server and randomly splitting them. The data owner sends the new ID field to the cloud server, and the cloud server replaces the old ID field stored locally with the new ID field.

[0023] It should be noted that the Boolean range search method supporting access mode and search mode privacy protection in this embodiment is an access mode and search mode privacy protection Boolean range search device. This device can be an electronic device, a component in an electronic device, an integrated circuit, or a chip. The electronic device can be a mobile electronic device or a non-mobile electronic device. For example, mobile electronic devices can be mobile phones, tablets, laptops, PDAs, in-vehicle electronic devices, wearable devices, etc., and non-mobile electronic devices can be servers and personal computers, etc., which are not specifically limited in this application. The following description uses a server as the execution subject to illustrate the Boolean range search method supporting access mode and search mode privacy protection in this embodiment.

[0024] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of the embodiments of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0025] Please see Figure 1 The data owner owns a spatial object database, encrypts each index entry and generates two encrypted indexes, which are then sent to the cloud server. and cloud servers After each search, the data owner reassigns the encrypted index and uploads it to two cloud servers. The client, authorized by the data owner, has the right to access spatial objects. The client encrypts its search request into a trapdoor and sends it to two cloud servers for searching. After the search is complete, the client sends the search results back to the data owner for ID field reassignment. For updates, the client sends an update token to update the index. Finally, the client aggregates the search results from the two cloud servers to obtain the final search results. cloud server and cloud servers Each cloud server stores its own encrypted index and collaborates to perform searches, both before the first search and after each subsequent search. and cloud servers They jointly perform the index shuffling operation.

[0026] Specifically, the client inputs a search request and sends it to the cloud server. and cloud servers The two cloud servers search their respective indexes based on the search request and return the search results to the client. The client then takes the intersection of the search results to obtain the final search result.

[0027] Specifically, the data owner builds an encrypted index, which is then stored on two separate cloud servers. The cloud servers then shuffle their respective encrypted indexes. The client inputs a search request and sends it to the cloud servers. and cloud servers The two cloud servers search their respective encrypted indexes based on the search request and return the search results to the client. The client then takes the intersection of the search results to obtain the final search result. After that, the two cloud servers perform an index rewriting operation.

[0028] It should be noted that this embodiment does not use a secret sharing method. It does not require the secret sharing of search keywords / search scope. Instead, the search keywords or search scope are directly sent to the two cloud servers respectively.

[0029] As one specific implementation, the cloud server receives an encrypted index built by the data owner.

[0030] Specifically, to improve search efficiency, this embodiment constructs two inverted indexes: a prefix-ID inverted index and a keyword-ID inverted index. The prefix-ID inverted index reveals the relationship between prefix elements and object IDs; the prefix code of an object's location and its corresponding object ID form an index. The keyword-ID inverted index reveals the relationship between keywords and object IDs; the keyword and the object ID containing that keyword form an index. The ID field (i.e., the bitmap) is an n-bit string consisting of 0s and 1s, where '1' indicates the presence of a keyword or a prefix element corresponding to its location in the spatial object, while '0' indicates its absence.

[0031] Specifically, for the prefix-ID index, this embodiment uses a 3rd-order Hilbert curve to generate 384 possible prefix elements (excluding "******") for the Hilbert values ​​of all spatial objects in the database. To protect the search pattern, each inverted index is split into two sub-inverted indexes. Cloud server and cloud servers Each inverted index stores a sub-prefix-ID index and a sub-keyword-ID index. Because the ID field of both inverted indexes consists of split ID fields, clients can rewrite these fields after each search to update the search results view. After building the encrypted indexes, an index shuffling operation is performed. In each cloud server, the keyword, prefix, and ID fields are encrypted using a re-encryption system. Each cloud server updates its ciphertext by re-encrypting the index entries and randomly rearranging each entry to change its position. Therefore, the search token changes with each search, preventing cloud servers from inferring search patterns.

[0032] As a specific implementation method, after each search, multiple cloud servers jointly perform an index shuffling operation.

[0033] Specifically, a tag is added to each index entry to indicate the index shuffle status. During each index shuffle, the cloud server... and cloud servers The labels are rerandomized using a pseudo-random function F, and the labels are communicated to the client to help the client generate new search tokens consistent with the current shuffled index entries.

[0034] To protect access and search patterns, index entries are re-encrypted using proxy re-encryption and general re-encryption. This ensures that even if cloud servers process encrypted searches, they cannot infer meaningful information about client search behavior.

[0035] Specifically, the index shuffling operation takes place on two cloud servers. and cloud servers This is done between [the two indexes]. Because the original index was split into two sub-indexes, each stored on a cloud server... and cloud servers The index shuffling process involves two subroutines, executed jointly by two cloud servers. Each cloud server uses proxy re-encryption and secret shuffling parameters to re-encrypt the keyword and prefix fields, preventing the cloud server from associating the shuffled index with the original index. Furthermore, the ID field is further randomized through generic re-encryption to increase unpredictability. Index entries are also randomly arranged to hide their positions. Because search tokens are related to index entries and the number of index shuffles, and change after each shuffle, the cloud servers cannot infer search patterns from the search tokens. To help clients generate new search tokens consistent with the currently shuffled index entries, tags are added to the index entries to indicate the index shuffling status. During each index shuffle, the cloud server... and cloud servers The labels are rerandomized using a pseudo-random function F, and then the labels are communicated to the client for use.

[0036] It should be noted that the index shuffling used in this embodiment involves two cloud servers re-encrypting the prefix or keyword fields of their stored indexes using proxy re-encryption and re-encrypting the ID field using general re-encryption. Then, each cloud server rearranges the two indexes it stores. This is the entire index shuffling process.

[0037] Index shuffling steps: For cloud servers For example, it sends the two indexes it stores to the cloud server. cloud server The index is re-encrypted using its own parameters, the two indexes are rearranged, and then sent to the cloud server. Cloud server The index is re-encrypted and rearranged using its own parameters, thus enabling the cloud server to... The indexes on the page have completed the index shuffling.

[0038] As a specific implementation method, the cloud server receives search requests from clients.

[0039] Specifically, the client uses its secret key. ,state and and shuffling parameters and Search tokens are generated. These search tokens are then randomized using the TPF.Rnd algorithm to ensure that repeated searches for the same keyword or prefix generate different tokens. Since both search tokens and update tokens originate from the secret key... Search tokens and update tokens cannot be directly used with the master key. Matching encrypted keyword or prefix fields.

[0040] To enable search and update operations, the cloud server must re-encrypt these search tokens and update tokens. This occurs when the index entries for the client's keyword field (or prefix field) are shuffled to reflect the state of the search keywords. (or the state of the search range encoding) When ), its key value is from Convert to or Cloud servers use authorization keys. Convert this token key to or This allows the cloud server to search for index items that match the search token, in order to match the key of the shuffled index item.

[0041] It should be noted that existing searchable encryption methods mostly employ one-time randomization, or only randomize the token once on the client side. This embodiment introduces two independent shuffling parameters for searching or updating the token. It also combines their respective state variables and This embodiment is the first to embed TPF.Rnd into the search token generation process and use the master key. Client key and authorization key Key conversion chain.

[0042] As a specific implementation method, the cloud server searches the stored encrypted index based on the received search request and obtains partial search results.

[0043] Specifically, based on the encrypted index and the generated search token, the two cloud servers perform searches on their respective stored encrypted indexes. Because the cloud servers... and cloud servers Storing different index items, the search process includes two sub-processes. First, the cloud server... After receiving the search token, the cloud server The search token is re-encrypted into a master token using the authorization key, and this master token is used to search for index items. (Cloud server) Subsequently, the ID field was partially decrypted and sent to the cloud server. Next, the cloud server. Completely decrypt the ID field, extract the object's ID, and locate the corresponding encrypted data. Finally, the cloud server... Encrypted data is returned to the client, whose search results are a combination of search results from two cloud servers.

[0044] As a specific implementation method, after each search is completed, the data owner reassigns the corresponding index based on the search results, and the cloud server updates its stored index based on the reassigned index, thereby achieving the unlinkability of the search results.

[0045] Specifically, after each search, an index reshuffle is performed. The client aggregates the search results from the two cloud servers, randomly splits them into two parts, and adds these parts to a new ID field. These new ID fields are then sent to the cloud servers to replace the old ID fields, giving each cloud server a new view of the search results. To prevent the cloud servers from associating new results with old results, re-encryption is performed during the next index shuffle.

[0046] Index reallocation protects access patterns, while index shuffling protects search patterns. Index reallocation occurs after each search, while index shuffling occurs after each search.

[0047] As a specific implementation method, the cloud server updates its stored index according to the reassigned index, which includes: the client generating an update token based on the status of the update keyword or update location, and the cloud server performing an index update operation on the locally stored encrypted index based on the update token.

[0048] Specifically, for newly added objects Each keyword in or each prefix The client initializes two empty bitmaps and randomly selects one to mark the ID information of the newly added object. To ensure the security of the updated data, the client encrypts it using TPF and TUR. To hide the location of the updated index item, the client applies a permutation function to the original update token. And remove the keyword, prefix, and ID fields. If the update token contains new keywords (i.e., If the update token is not associated with any existing index entry, it ensures no information is leaked. In this case, the update token is not replaced, and the keyword and ID fields can be directly added to the index. The process ultimately generates four update tokens, which are sent to the cloud server respectively. and cloud servers .

[0049] It should be noted that the client needs to maintain two empty bitmaps for each newly added object and randomly select one to mark its ID information. This embodiment uses a hybrid encryption technique of proxy re-encryption, general re-encryption, and a permutation function to meet the dynamic update requirements. Previous search encryption methods mostly focused on updating keywords and did not support spatial location updates. This embodiment uses a dual bitmap + random selection + keyword or location update method, which is an extension of existing update token technology.

[0050] To achieve forward security during update operations, cloud servers and cloud servers The two indexes are updated collaboratively. Specifically, for the keyword-ID inverted index, the cloud server... The stored index entries are replaced to hide the actual location, and then the replaced index is sent to the cloud server. Cloud server Update the replaced index using the update token. (Due to the cloud server...) The update location and new index are unknown, and the cloud server... The original index is unknown, thus ensuring forward security. (Cloud server) use Replace the index entries, remove the keyword field, re-encrypt the ID field, and send the sorted index to the cloud server. To prevent cloud servers Inferring update location, cloud server Re-encrypt the ID field of the index entry that has not been updated, and return the entire index to the cloud server. Cloud server use Restore the order of the index entries and insert the newly added keyword index entries.

[0051] It's important to note that the two cloud servers alternately perform the permutation, re-encryption, and update operations primarily to prevent either server from knowing or understanding the other's actual index, and to prevent them from linking the old and new indexes. Even if one cloud server is attacked, the attacker will not obtain the true index. Both cloud servers possess the same re-encryption capability; they simply re-package existing ciphertext with new pseudo-random numbers, without altering the underlying key pair.

[0052] The update process for a prefix-ID inverted index is similar; if the prefix field covers all possible elements, no additional processing is needed for new elements. (Cloud server) The stored index entries are replaced to hide the actual location, and then the replaced index is sent to the cloud server. Cloud server Update the replaced index using the update token. (Due to the cloud server...) The update location and new index are unknown, and the cloud server... The original index is unknown, thus ensuring forward security. (Cloud server) use Replace the index entries, remove the prefix field, re-encrypt the ID field, and send the sorted index to the cloud server. To prevent cloud servers Inferring update location, cloud server Re-encrypt the ID field of the index entry that has not been updated, and return the entire index to the cloud server. Cloud server use Restore the order of the index entries and insert the newly added prefix index entry.

[0053] The above are merely preferred embodiments of this application and are not intended to limit this application in any way. Although this application has disclosed preferred embodiments as described above, it is not intended to limit this application. Any person skilled in the art can make some modifications or alterations to the above-mentioned technical content to create equivalent embodiments without departing from the scope of the technical solution of this application. The implementation schemes in the above embodiments can also be further combined or replaced. Any simple modifications, equivalent changes and alterations made to the above embodiments based on the technical essence of this application without departing from the content of the technical solution of this application shall still fall within the scope of this application.

Claims

1. A Boolean range query method supporting privacy protection in access and search modes, characterized in that, Includes the following steps: The cloud server receives search requests from the client; The cloud server receives an encrypted index built by the data owner; Multiple cloud servers perform searches on the stored encrypted index based on the received search requests, and obtain partial search results respectively; The obtained partial search results are sent to the client for summation to obtain the final search results; After each search, multiple cloud servers jointly perform an index shuffling operation; After each search is completed, the data owner reassigns the corresponding index based on the search results, and the cloud server updates its stored index based on the reassigned index, thereby achieving the unlinkability of the search results. The index reassignment operation is as follows: the data owner receives new ID field data sent by the client, which is generated by the client aggregating the search results of each cloud server and randomly splitting them; The data owner sends the new ID field to the cloud server, which then replaces the old ID field stored locally with the new ID field.

2. The method according to claim 1, characterized in that, The index shuffling operation is performed on a cloud server. and cloud servers It takes place between; Each cloud server uses proxy re-encryption and secret shuffle parameters to re-encrypt the keyword field and prefix field, the ID field is further randomized through general re-encryption, and each index entry is randomly arranged to hide its position; A tag is added to each index entry to indicate the index shuffle status, and during each index shuffle, the cloud server... and the cloud server The label is rerandomized using a pseudo-random function F, and the label is communicated to the client to help the client generate a new search token consistent with the current shuffled index entry.

3. The method according to claim 1, characterized in that, The cloud server receives search requests from clients, including: The client uses a secret key. ,state and and shuffling parameters and Generate search token; The search token is randomized using the TPF.Rnd algorithm, so that repeated searches for the same query keywords or query range prefixes generate different search tokens. The cloud server re-encrypts the search token, enabling the use of a secret key. The generated search token is used with the master key of the cloud server. Matching encrypted keyword or prefix fields; The re-encryption step specifically includes: When the index entries for the keyword or prefix fields queried by the client are shuffled to a certain state. or At that time, the key value of the index item is changed from Convert to or ; The cloud server uses an authorization key Convert keyword field values ​​or prefix key field values ​​to or To match the field values ​​of the indexed items after shuffling.

4. The method according to claim 3, characterized in that, The cloud server searches the stored encrypted index based on the received search request, and obtains partial search results, including: Based on the search token received from the client, the two cloud servers perform a search on their respective stored encrypted indexes; The cloud server uses the authorization key to re-encrypt the search token into a main token, and uses the main token to search for index items. The cloud server then partially decrypts the searched ID field and sends it to another cloud server; Another cloud server completely decrypts the ID field, extracts the object's ID, and locates the corresponding encrypted data; Another cloud server returns encrypted data to the client, and the client's final search result is a combination of the search results from the two cloud servers.

5. The method according to claim 2, characterized in that, The cloud server receives an encrypted index built by the data owner, including: The encrypted index includes an encrypted prefix-ID index and an encrypted keyword-ID index; Each encrypted index is split into two encrypted sub-indexes to protect the search pattern. Specifically, the prefix field and keyword field remain unchanged, while only the ID field corresponding to the encrypted index is split, and then the two sub-indexes are sent to the cloud server. and the cloud server ; The cloud server and the cloud server Each stores an encrypted subprefix-ID index and an encrypted subkeyword-ID index.

6. The method according to claim 5, characterized in that, After each subsequent search, multiple cloud servers jointly perform an index shuffling operation, including: The index shuffling operation is performed by the cloud server. and the cloud server Collaborative processing; For the cloud server : The cloud server Send the two stored inverted indexes to the cloud server. ; The cloud server The received inverted index is re-encrypted using its own parameters, and the two inverted indexes are rearranged before being sent to the cloud server. ; The cloud server The received inverted index is re-encrypted and rearranged using its own parameters; In each of the cloud servers, the keyword, prefix, and ID fields are encrypted using re-encryption. Each cloud server updates its ciphertext by re-encrypting the index entries and randomly rearranging each entry to change its position, so that the search token changes with each search, preventing the cloud server from inferring search patterns.

7. The method according to claim 5, characterized in that, The cloud server updates its stored indexes based on the reassigned indexes, including: The client generates an update token based on the status of the updated keyword or updated location, and the cloud server performs an index update operation on the locally stored encrypted index based on the update token.

8. The method according to claim 7, characterized in that, The client generates an update token based on the status of the update keyword or update location, including: For newly added objects Each keyword in or each prefix The client initializes two empty bitmaps and randomly selects one to mark the newly added object. ID information; The client encrypts it using TPF and TUR. To hide the location of the updated index entry, the client applies a permutation function to the original update token. Remove keyword, prefix, and ID fields; If the update token contains new keywords (i.e.) If the update token is not associated with any existing index entry, it ensures that no information is leaked. The update token is not replaced, and the keyword and ID fields are directly added to the index. The client ultimately generates four update tokens and sends them to the cloud server respectively. and the cloud server .

9. The method according to claim 8, characterized in that, The cloud server performs an index update operation on the locally stored encrypted index based on the update token, including: Update the prefix-ID index and the keyword-ID index. Specifically, the steps for updating the prefix-ID index are as follows: The cloud server Replace the stored index entries and send the replaced index to the cloud server. ; The cloud server Update the replaced index using the update token; The cloud server use Replace the index entries, remove the prefix field, re-encrypt the ID field, and send the sorted index to the cloud server. ; The cloud server Re-encrypt the ID field of the index entry that has not been updated, and return the entire index to the cloud server. ; The cloud server use Restore the order of the index entries and insert the newly added prefix index entry.

Images