Dynamic searchable encryption method and system with forward and backward privacy
By adopting virtual binary tree, version control library, Bloom filter and cache mechanism in dynamic searchable encryption technology, front-end privacy protection and complex query functions are realized, and the problems of information leakage and security risks in the existing technology are solved, and search efficiency and security are improved.
Patent Information
- Application Number
- CN202510637601.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-05-19
- Publication Date
- 2025-06-17
- Estimated Expiration
- 2045-05-19
AI Technical Summary
Existing dynamic searchable encryption technology has the risk of information leakage in the data update process, especially cloud servers may record and analyze all past search queries to infer whether the newly added files contain certain specific keywords, resulting in security risks such as file injection attacks.
A dynamic searchable encryption method with front-back privacy is adopted to store encrypted data based on virtual binary tree VBTree, and combined with a pre-built version control library and a Bloom filter to achieve forward and backward privacy of dynamic searchable encryption. At the same time, the search results of the encrypted database are recorded using the cache mechanism, supporting complex queries such as connection queries, boolean queries and scope queries.
It effectively protects users' forward and backward privacy, prevents information leakage and file injection attacks, improves search efficiency and supports complex query functions.
Smart Images

Figure CN120162812A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical fields of information retrieval and cryptography, and specifically, to a dynamic searchable encryption method and system with forward and backward privacy. Background Art
[0002] In recent years, with the rapid progress of network technology, we have entered the big data era. Due to the sharp increase in the amount of data generated in people's daily lives, cloud server storage technology has emerged, such as Amazon's S3 storage service and domestic Baidu Cloud, etc. However, with the continuous development of this technology, people have gradually realized that outsourcing data to cloud servers will cause users to lose control over their data, thereby posing a severe challenge to the privacy and security of users. Although cloud storage services are both economical and convenient, when users' data is stored in an unencrypted form, new security problems will arise. To address this challenge, encryption has become a common solution, that is, users upload encrypted data to the cloud. However, encrypted data makes it difficult for users to retrieve files containing specific keywords or content. A direct method is to download all files to the local for decryption and then query, but this method not only increases the network burden by downloading unnecessary files but also consumes a large amount of computing resources due to the decryption and query processes, so it is not practical. Given the powerful computing capabilities of cloud servers, people expect the server to perform the retrieval task, that is, send the key to the cloud server, and the server decrypts and searches. However, the problem is that cloud servers are usually regarded as "honest but semi-trusted" entities, and users' privacy still faces the risk of leakage in front of cloud servers. To solve the above problems, searchable encryption (SE) technology has emerged. As an innovative cryptographic tool, searchable encryption technology endows users with the ability to perform keyword searches on ciphertext. When data is stored in ciphertext on a cloud server, the powerful computing capabilities of the server can be utilized for keyword retrieval, while ensuring that no user privacy information is leaked to the server. This not only effectively protects users' privacy but also significantly improves the retrieval efficiency with the assistance of the server.
[0003] Subsequently, to support the dynamic update function of data, dynamic searchable encryption technology (DSE) was introduced, which allows operations such as adding and deleting files to be performed on the server. However, DSE has a risk of information leakage in the data update process. Specifically, the cloud server may record and analyze all past search queries, and by comparing these queries with the content of the updated files, infer whether the newly added files contain certain specific keywords. This information leakage phenomenon provides an opportunity for security risks such as file injection attacks.
[0004] To address this issue, a forward privacy protection mechanism for search encryption schemes has emerged. It aims to ensure that update queries do not reveal the keywords being updated or the keywords in the keyword-document pairs, especially for document addition operations, ensuring that newly added documents do not appear in the set of past query results. At the same time, backward privacy protection requires that search and update operations only reveal the current document state in the database (i.e., excluding deleted documents), mainly focusing on document deletion operations to ensure that current queries do not touch any deleted document indexes.
[0005] Currently, although many dynamic searchable encryption schemes have achieved forward and backward privacy protection, most of them are limited to supporting only single-keyword query functions. Summary of the Invention
[0006] To solve the deficiencies mentioned in the above background art, the purpose of the present invention is to provide a dynamic searchable encryption method and system with forward and backward privacy, which can implement complex queries while ensuring the forward privacy and backward privacy of data.
[0007] In the first aspect, the purpose of the present invention can be achieved through the following technical solutions: A dynamic searchable encryption method with forward and backward privacy, the method includes the following steps: Obtain encrypted data, store the encrypted data based on a virtual binary tree VBTree, and generate an encrypted database; Manage the encrypted database based on a pre-constructed version control library to achieve forward privacy of dynamic searchable encryption, record data deletion of the encrypted database based on a pre-constructed Bloom filter BF to achieve backward privacy of searchable encryption; record the search results of the encrypted database based on a caching mechanism to obtain a processed encrypted database; Query the processed encrypted database based on multiple complex queries, where the complex queries include join queries, Boolean queries, and range queries, to obtain a final query result.
[0008] Combined with the first aspect, in some implementation manners of the first aspect, the method further includes: storing the encrypted data based on the virtual binary tree VBTree to organize index elements into the virtual binary tree VBTree in a top-down manner; The pre-constructed version control library includes a local repository and a cloud repository. The complex queries can be transformed into querying all files corresponding to a single keyword, and then taking the intersection of the result sets of multiple keywords for join queries, the union for range queries, or checking whether a certain file exists in the result set for Boolean queries.
[0009] Combined with the first aspect, in some implementation manners of the first aspect, the method further includes: The virtual binary tree VBTree has the following attributes: Full binary tree: A full binary tree is a binary tree with 2 L ^L - 1 tree nodes and 2 L-1 ^L leaves, where L is the height of the tree; Path(V): Given a tree node V, Path(V) represents the string formed by all the tree branches connecting from the root of the tree to the current node V; Nodes(i): Let i ∊ [0, 2 L-1 ^L - 1], leaf i _i represents the i-th leaf in the tree, and Nodes(i) represents the set of all traversed nodes from the root to the leaf; The VBTree is stored in a hash table as follows: Each tree node contains zero or more different encrypted keywords, The hash table only stores the encrypted keywords and does not store any tree nodes and tree branches. For the keyword w of the index file identifier i (i ∊ [0, 2 L-1 ^L - 1]), insert the keyword into each tree node of Nodes(i); The elements on the hash table are: {(H1(Path(V) || F Ks (w || i || v)), t)} V∊Nodes(i) where t = F Kt (w, id), F is a keyed pseudorandom function, H1 is a random oracle, V is the tree node containing the keyword w, Ks, Kt are a set of keys of the data owner, w is the keyword, v is the version number of the keyword w, and i is the search count of the keyword w.
[0010] Combined with the first aspect, in some implementation manners of the first aspect, the method further includes: The pre-constructed version control library is as follows: Given a keyword w, the v-th version is denoted as w || v, and the v-th version trapdoor is denoted as F Ks (w || v), and the historical search queries and updates are managed by the version control library; Version control library: The version control library of the dynamic symmetric searchable encryption scheme includes a local repository LR and a cloud repository CR. LR is a local hash table, and CR is a cloud hash table; On the client side, LR(w) represents the usage information of the keyword w. The client includes a data owner and a data user, and the owner and the user share the same LR. For each keyword w, LR(w) has three attributes, (b, V l , n l ), as follows: LR(w).b indicates whether the data user has queried the latest version of keyword w. The initial state of LR(w).b is false, indicating that the latest version of this keyword has not been leaked. If keyword w has been searched, then LR(w).b is set to true, indicating that the keyword has been leaked to the cloud server according to the search pattern; LR(w).V l represents the latest version of keyword w; L.R(w).n l represents the file identifier of the last file that matches keyword w; On the cloud server side, CR is regarded as multiple encrypted singly linked lists. Let H2 and H3 be different random oracles. The encrypted items in CR are in key-value form (H2(F Ks (w||i||v)), H3(F Ks (w||i||v)) ⊕ F Ks (w||i old ||(v - 1))). The cloud server uses the current trapdoor to obtain the previous trapdoor to search for all results. The cloud server cannot derive the trapdoor of the (v + 1)th version from the vth version, thereby protecting the forward privacy of dynamic searchable encryption.
[0011] Combined with the first aspect, in some implementation manners of the first aspect, the method further includes: The process of recording the data deletion of the encrypted database based on the pre-constructed Bloom filter BF includes: Use the Bloom filter BF to record the deletion of encrypted data. If a deletion operation is performed on (w, id), only calculate t for this item, where t = F Kt (w,id), id is the file identifier, and use k hash functions to map it to k positions of the binary vector, and set the values at the positions to 1 to implement adding the element to BF; When performing a search, use the k hash functions again to calculate the k positions corresponding to t in the binary vector, and check whether the values at the positions are all 1. If all are 1, it means that t of keyword w and its corresponding file id exists in BF, then a deletion operation has been performed, and this id is not returned.
[0012] Combined with the first aspect, in some implementation manners of the first aspect, the method further includes: The process of recording the search results of the encrypted database based on the cache mechanism: Use the cache to record the search results for a single keyword. For this search, only query the newly inserted data between the last search and the current search. Then, obtain the results of the last search from the cache. After obtaining the sum of the two results, check one by one whether t exists in the BF, filter out the data that exists in the BF, return the ids that belong to the sum of the two search results and do not exist in the BF, and update the data in the cache to the returned search results.
[0013] Combined with the first aspect, in some implementation manners of the first aspect, the method further includes: when performing the join query, if it is necessary to query files that jointly contain keywords w1 and w2, finally return the result set, that is, query each keyword, obtain the file ids that contain this keyword and have not been deleted, and finally take the intersection of the query results of all keywords as the result of the join query; When performing a boolean query, if it is necessary to query whether a file with identifier id1 contains keyword w1, that is, query all files that contain keyword w1 and return the result set, and finally check whether id1 is included in the result set; When performing a range query, if it is necessary to query keyword w greater than or equal to a and less than or equal to d, first find the keywords that meet the size requirements. Assume that w1 and w2 meet the requirements. Then, query the files that contain keywords w1 and w2, and finally return the file ids, that is, query each keyword, obtain the file ids that contain this keyword and have not been deleted, and finally take the union of the result sets of all keywords as the result of the range query.
[0014] In a second aspect, in order to achieve the above object, the present invention discloses a dynamically searchable encryption system with forward and backward privacy, including: A data storage module, configured to obtain encrypted data, store the encrypted data based on a virtual binary tree VBTree, and generate an encrypted database; A forward and backward privacy module, configured to manage the encrypted database based on a pre-constructed version control library to implement the forward privacy of dynamically searchable encryption, record the data deletion of the encrypted database based on a pre-constructed Bloom filter BF to implement the backward privacy of searchable encryption; record the search results of the encrypted database based on a caching mechanism to obtain a processed encrypted database; A complex query module, configured to query the processed encrypted database based on multiple complex queries, where the complex queries include join queries, boolean queries, and range queries, to obtain a final query result.
[0015] In another aspect of the present invention, in order to achieve the above object, a terminal device is disclosed, which includes a memory, a processor, and a computer program stored in the memory and capable of running on the processor. The memory stores a computer program capable of running on the processor. When the processor loads and executes the computer program, a dynamic searchable encryption method with forward and backward privacy as described above is adopted.
[0016] In still another aspect of the present invention, in order to achieve the above object, a computer-readable storage medium is disclosed. The computer-readable storage medium stores a computer program. When the computer program is loaded and executed by a processor, a dynamic searchable encryption method with forward and backward privacy as described above is adopted.
[0017] Advantages of the present invention: The present invention can naturally express hierarchical relationships and multiple attributes, which provides strong support for constructing a searchable encryption scheme that supports complex query functions such as join queries, range queries, and Boolean queries. BRIEF DESCRIPTION OF THE DRAWINGS
[0018] In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings required for the description of the embodiments or the prior art. Obviously, for those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings. Figure 1 It is a schematic flowchart of the method of the present invention; Figure 2 It shows the logical view of VBTree and the corresponding hash representation diagram; Figure 3 It shows the version control library diagram; Figure 4 It shows the flowchart of keyword insertion; Figure 5 It shows the flowchart of searching for files containing keywords; Figure 6 It is a schematic structural diagram of the system of the present invention; Figure 7 It is a schematic diagram of the present invention applied to the vehicle networking for data storage. DETAILED DESCRIPTION OF THE EMBODIMENTS
[0019] The following will clearly and completely describe the technical solutions in the embodiments of the present invention with reference to the drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts belong to the scope of protection of the present invention.
[0020] Example 1: As shown in Figure 1 S101: Obtain encrypted data, store the encrypted data based on the virtual binary tree VBTree, and generate an encrypted database; The storing of the encrypted data based on the virtual binary tree VBTree organizes the index elements into the virtual binary tree VBTree in a top-down manner; The virtual binary tree VBTree has the following properties: Full binary tree: A full binary tree is a binary tree with 2 L - 1 tree nodes and 2 L-1 leaves, where L is the height of the tree; Path(V): Given the tree node V, Path(V) represents the string formed by all the tree branches connecting from the root of the tree to the current node V; Nodes(i): Let i ∊ [0, 2 L-1 - 1], leaf i represents the i-th leaf in the tree, and Nodes(i) represents the set of all traversed nodes from the root to the leaf; The VBTree is stored in a hash table as follows: Each tree node contains zero or more different encrypted keywords, The hash table only stores the encrypted keywords and does not store any tree nodes and tree branches, For the keyword w of the index file identifier i (i ∊ [0, 2 L-1 - 1]), insert the keyword into each tree node of Nodes(i); The elements on the hash table are: {(H1(Path(V)||F Ks (w||i||v)), t)} V∊Nodes(i) where t = F Kt (w, id), F is a keyed pseudorandom function, H1 is a random oracle, V is a tree node, Ks, Kt are a set of keys of the data owner, w is the keyword, id is the file identifier, v is the version number of the keyword w, and i is the search count of the keyword w.
[0021] Specifically, use the virtual binary tree (VBTree) to store the encrypted data, and the implementation steps are as follows: Step 1.1, Setup phase, input the security parameter λ, and generate λ-bit binary data as the keys Ks, Kt: Ks, Kt ← {0, 1} λ; Step 1.2, Setup phase, initialize the hash table T to store encrypted data as a virtual binary tree (VBTree). Assume the VBTree stores n files, and the file identifier id ∊ [0, n-1]: T ← ⊥, the tree height L = ⌈ ⌉ + 1; Step 1.3, Update phase, calculate the tag t of the element (w, id) to be inserted: t ← F Kt (w, id). To support the indexing of multi-dimensional data records, all types of index elements are regarded as keywords. By concatenating the keyword with the attribute string, the multi-dimensional data record is encoded into a one-dimensional data. Given the keyword w and the corresponding attribute "attr", the keyword w is encoded into the string "attr:w"; Step 1.4, Update phase, calculate the index of the element (w, id) to be inserted: H1(Path(V) || F Ks (w || i || v)) V∊Nodes(i) , where the node V starts from the root node, that is, the initial Path(V) = '', then calculate the binary path of the leaf node according to id, and add '0' or '1' to Path = '' in turn until it is filled L - 1 times. The version number v of the keyword w is shown in Step 2.2, and the search times i is shown in Step 4.4; Step 1.5, Update phase, the client sends the data to the cloud server, and inserts the element into the VBTree in the cloud server: {(H1(Path(V) || F Ks (w || i || v)), t)} V∊Nodes(i) , where t ← F Kt (w, id).
[0022] S102: Manage the encrypted database based on a pre-built version control library to achieve the forward privacy of dynamic searchable encryption, record the data deletion of the encrypted database based on a pre-built Bloom filter BF to achieve the backward privacy of searchable encryption; record the search results of the encrypted database based on a caching mechanism to obtain the processed encrypted database, thereby improving the search efficiency; the pre-built version control library includes a local repository and a cloud repository; Use the version control library to achieve the forward privacy of dynamic searchable encryption, and the implementation steps are as follows: Step 2.1, Setup phase, the client initializes the local hash table LR, and the cloud server initializes the cloud hash table CR: LR ← ⊥, CR ← ⊥; Among them, LR contains b, V l , n l Three attributes: LR(w).b indicates whether the data user has queried the latest version of the keyword w, LR(w).V l represents the latest version of keyword w, L.R(w).n l represents the file identifier of the last file that matches keyword w; Step 2.2, Update phase, if keyword w to be inserted into the file with identifier id does not exist beforehand, then execute Steps 2.3 - 2.7, otherwise execute Steps 2.8 - 2.16; Step 2.3, Then initialize its LR: LR(w).b ← false, LR(w).V l ← 0, LR(w).n l ← -1; Step 2.4, Obtain the version number of keyword w: v ← LR(w).V l ; Step 2.5, Calculate the elements to be inserted into VBTree in the cloud server: {(H1(Path(V)||F Ks (w||i||v)), t)} V∊Nodes(i), where t = F Kt (w,id), and the search count i is shown in Step 4.4; Step 2.6, Update the cloud hash table CR, and CR records the trapdoor of the keyword: CR[w] ← (H2(F Ks (w||i||v)),H3(F Ks (w||i||v)) ⊕ null); Given a search trapdoor F Ks (w||i||v) to search for keyword w of version v, the cloud server can obtain F Ks (w||i||v) to get F Ks (w||i old ||(v - 1)) ← C R [H2(F Ks (w||i||v))] ⊕ H3(F Ks (w||i||v)) and other sub - versions, where i old is the search count corresponding to keyword w of version (v - 1) stored in CR, and i is the search count corresponding to keyword w of version v stored in CR, Now, the cloud server can use these trapdoors to search for all results. However, the cloud server cannot derive the trapdoor of the (v + 1) - th version from the v - th version, which is a key design consideration of the forward - private dynamic SSE scheme; Step 2.7, After performing the operation of inserting keyword w, update the latest matching document identifier of w: LR(w).n l ← id.
[0023] Step 2.8, Update phase, determine whether the latest version of keyword w has been searched: If LR(w).b = false, it means the latest version has not been searched, then execute Steps 2.9 - 2.11; if LR(w).b = true, it means the latest version has been searched, then execute Steps 2.12 - 2.16; Step 2.9, Obtain the version number of keyword w: v ← LR(w).V l ; Step 2.10, Calculate the element to be inserted into VBTree in the cloud server: {(H1(Path(V)||F Ks (w||i||v)), t)} V∊Nodes(i), where t = F Kt (w, id), and the search times i can be seen in Step 4.4; Step 2.11, After performing the operation of inserting keyword w, update the latest matching document identifier of w: LR(w).n l ← id.
[0024] Step 2.12, Update the version number of the keyword: v ← LR(w).V l + 1, LR(w).V l ← v; Step 2.13, The new version at this time has not been searched: LR(w).b ← false; Step 2.14, Calculate the element to be inserted into VBTree in the cloud server, insert the following element into T and this element into VBTree: {(H1(Path(V)||F Ks (w||i||v)), t)} V∊Nodes(i), where t = F Kt (w, id), and the search times i can be seen in Step 4.4; Step 2.15, Update the cloud server hash table CR, and CR records the trapdoor of the keyword: CR[w] ← (H2(F Ks (w||i||v)), H3(F Ks (w||i||v)) ⊕ F Ks (w||i old ||(v - 1))); Step 2.16, After performing the operation of inserting keyword w, update the latest matching document identifier of w: LR(w).n l ← id.
[0025] The process of recording data deletion of the encrypted database based on the pre - constructed Bloom filter BF includes: Step 3.1. Setup phase: Initialize the Bloom Filter. H,B ← Φ.Gen(λ), where Φ represents the Bloom Filter, and the role of the Gen(λ) algorithm is to generate the initial data structure required for a Bloom Filter, including a set of hash functions and a vector of all zeros. These components will be used for subsequent insert and query operations; Step 3.2. Update phase: If you want to delete the keyword w from the file with identifier id, calculate its tag t: t←F Kt (w,id); Step 3.3. Record this deletion operation in the Bloom Filter: Update BF Φ.Upd(H,B,t), where the role of the Upd(H,B,t) algorithm is to insert the element t into the Bloom Filter and mark the corresponding positions in the bit array B through multiple hash functions; Essentially, use k hash functions to calculate k hash values of the tag t and map them to k positions in the binary vector, and set the values at these positions to 1; Step 3.4. Query phase: Determine whether a certain tag t exists in the Bloom Filter: if Φ.Check(H,B,t) is false, if it returns true, it means t does not exist in the Bloom Filter, otherwise it means it exists. The role of the Check(H,B,t) algorithm is to check whether the element t may exist in the Bloom Filter; Essentially, use k hash functions to calculate k hash values of the tag t and map them to k positions in the binary vector, and determine whether the values at these positions are all 1. If so, it means t exists, and if there is one position with a value of 0, it means it does not exist.
[0026] The use of a cache mechanism to record the search results is implemented as follows: Step 4.1. Setup phase: Initialize the list C to record the search times of each keyword: C←⊥; Step 4.2. Setup phase: After a series of initializations and when returning, return the cache together: return((Ks,Kt),( σ add , C, LR),(T, CR, EDB cache )); Step 4.3. Search phase: If you want to search for all files containing the keyword w and obtain their file identifiers, the client performs the following steps: Step 4.4. Obtain the search times of the keyword w: i←C[w]; Step 4.5. Record that the latest version of the keyword w has been searched: LR(w).b←true; Step 4.6, Generate search trapdoor: tkn←F Ks (w||i||LR(w).V l ); Step 4.7, The cloud server starts searching from the root node and determines whether the current node contains t: flag←T.ContainsKey(H1(Path||tkn)) Among them, the ContainsKey() function is used to determine whether the position pointed to by the index in the virtual binary tree (VBTree) T contains an element. The initial value of Path is ‘’. If it is true, it means that t exists in the current node. Then, ‘0’ or ‘1’ is added to Path in turn to query the left child node or right child node of the current node. If it is false, it means that t does not exist in the current node and the query stops; Step 4.8, The cloud server finally searches for all leaf nodes containing t. Path records the path of the leaf node, which can be corresponding to the file identifier id represented by the leaf node. Record t into the current search result set NewIDt←NewIDt∪{t i} The result set NewIDt only contains the newly inserted encrypted data after the previous search, not all files corresponding to the keyword w; Step 4.9, The cloud server sends NewIDt to the client. The client decrypts it using the key Kt to obtain the set NewID containing file identifiers At this time, NewID only contains the file ids newly inserted after the previous search; Step 4.10, Obtain the previous search result set: OldId←EDB cache [tkn]; At this time, OldId contains all the results obtained in the previous search. Some of these files may have deleted the keyword w and need to determine whether they have been deleted in the Bloom filter again; Step 4.11, For each file id in OldId, calculate the tag t, t←F Kt (w,id), and determine whether the tag t exists in the Bloom filter: if Φ.Check(H,B,t) is false. If it returns true, it means that t is not in the Bloom filter, otherwise it means it exists and is recorded in the deletion set: DelIdt←DelIdt∪{t i} Step 4.12, Delete the data existing in the Bloom filter: OldId←OldId\{(id i ): ∃t i ∊ DleIdt s.t. t=t i} In this way, the results obtained from this search no longer contain the deleted data, and subsequent searches cannot obtain information about the deleted data, thus ensuring backward privacy of dynamic searchable encryption to a certain extent; Step 4.13: Calculate the final result set: Res ← NewId ∪ OldId; Step 4.14: Save the result set to the cache: EDB cache [tkn] ← Res; S103: Query the processed encrypted database based on multiple complex queries, where the complex queries include join queries, boolean queries, and range queries, to obtain the final query result.
[0027] The complex queries can be transformed into querying all files corresponding to a single keyword, and then taking the intersection of the result sets of multiple keywords for join queries, the union for range queries, or checking whether a certain file exists in the result set for boolean queries.
[0028] The implementation steps of the join query are as follows: Step 5.1-1: Search for files containing the keyword {w i}, first obtain the version number and search times of each keyword: v i∊q ← LR(w i ).V i ), i l ← C[w i ; i Step 5.1-2: Record that the latest version of the keyword {w i} i∊q has been searched: LR[w i .b ← true; Step 5.1-3: Generate i search traps: tkn i ← F Ks (w||i i ||v i ); Step 5.1-4: The client sends the search trap to the cloud server, and the cloud server performs a single-keyword search according to steps 4.7 to 4.13 and saves the search results in the cache to obtain i result sets: {Res} i∊q ; Step 5.1-5: Take the intersection in all the result sets: Intersection; The implementation steps of the boolean query are as follows: Step 5.2-1: Query whether the specified file (identifier is id) contains the specified keyword (w), and obtain the version number and search times of the keyword: v ← LR(w).Vl , i ← C[w]; Step 5.2-2, Record that the latest version of the keyword w has been searched: LR[w].b ← true; Step 5.2-3, Generate a search trapdoor: tkn ← F Ks (w||i||v i ); Step 5.2-4, Generate the tag t to be retrieved: t ← F Kt (w, id); Step 5.2-5, The client sends the search trapdoor to the cloud server. The cloud server performs a single-keyword search according to Steps 4.7 to 4.13 and saves the search results in the cache to obtain the result set: Res; Step 5.2-6, Retrieve whether the result t is included in Res to obtain the retrieval result true or false; The implementation steps of the range query are as follows: Step 5.3-1, Search for the files corresponding to the keywords within a specific range. First, the client needs to search for all keywords {w i} i∊q ; Step 5.3-2, First obtain the version number and search times of each keyword: v i ←LR(w i ).V l , i i ←C[w i ; Step 5.3-3, Record that the latest version of the keyword {w i} i∊q has been searched: LR[w i .b ← true; Step 5.3-4, Generate i search trapdoors: tkn i ←F Ks (w||i i ||v i ); Step 5.3-5, The client sends the search trapdoor to the cloud server. The cloud server performs a single-keyword search according to Steps 4.7 to 4.13 and saves the search results in the cache to obtain i result sets: {Res} i∊q ; Step 5.3-6, Take the union of all the result sets: Union; Specifically, the solution of the present invention will be further elaborated through the following embodiments: Next, Figures 2 - 5 will be introduced in detail.
[0029] The logical view of the VBTree and the corresponding hash table are as follows Figure 2 shown, t = F kt (a, id1); i = 0, indicating that the search count is 0; v = 0, indicating that the keyword a is inserted for the first time. The logical view of the VBTree is shown on the left side of the picture, and the corresponding hash table is shown on the right side of the picture. Although all elements are actually stored in the corresponding hash table, they can be converted into a complete binary tree in the logical view of the VBTree according to Path(V), that is, the virtual binary tree VBTree. The elements stored on the hash table are: {(H1(Path(V) || F Ks (a || i || v)), t)} V∊Nodes(i) . According to Path(V), the height of the virtual binary tree is 3. Since the last item of Path(V) is '01', converting the binary code to a decimal number can obtain the file identifier id = 1. The trapdoor is F Ks (a || i || v), indicating that the virtual binary tree stores the keyword a. At this time, i = 0 and v = 0, indicating that the keyword a has not been searched, and the current version is 0, which is the first time to insert the keyword a into the database. At the same time, using the hash function to calculate the index H1(Path(V) || F Ks (a || i || v)) and storing the element t at the corresponding position. t contains the encrypted information of the keyword and the file identifier. Thus, the virtual binary tree on the logical view of the hash table can be obtained. Each leaf node of the virtual binary tree corresponds to a file. Since the height of this virtual binary tree is 3, it can store up to 4 files at most.
[0030] The version control library diagram is as follows Figure 3 shown, the client stores LR which contains w, b, V l , n l . LR(w).b: Whether the data user has queried the latest version of the keyword w; LR(w).V l represents the latest version of the keyword w; L.R(w).n l represents the file identifier of the last file that matches the keyword w. The cloud stores CR, and the encrypted items in CR are in key-value form (H2(F Ks (w || i || v)), H3(F Ks (w || i || v)) ⊕ F Ks (w || i old ||(v - 1))).
[0031] The version control library used in the present invention includes a local repository LR and a cloud repository CR. LR is a local hash table, and CR is a cloud hash table; On the client side, LR(w) represents the usage information of keyword w. The client includes a data owner and a data user. The owner and the user share the same LR. For each keyword w, LR(w) has three attributes, b, V l , n l .
[0032] On the cloud server side, CR is regarded as multiple encrypted singly linked lists. Let H2 and H3 be different random oracles. The encrypted items in CR are in the form of key values (H2(F Ks (w||i||v)), H3(F Ks (w||i||v)) ⊕ F Ks (w||i old ||(v - 1))). The cloud server uses the current trapdoor to obtain the previous trapdoor to search for all results. The cloud server cannot derive the trapdoor of the v + 1 version from the v-th version, thereby protecting the forward privacy of dynamic searchable encryption.
[0033] The keyword insertion process of the present invention is as Figure 4 shown. Determine whether the keyword w is inserted for the first time. If so, initialize the LR information: LR(w).b, LR(w).V l , LR(w).n l , update the VBTree, update the CR, and finally update LR(w).n l . If not, determine whether the latest version of w has been searched. If not, obtain the latest version v of w and search for i at this time, update the VBTree, and finally update LR(w).n l ; if so, update the version LR(w).V of w l , obtain the search count i, and then set that the current version has not been searched: LR(w).b ← false, update the VBTree, update the CR, and finally update LR(w).n l .
[0034] As Figure 5 shown, search for files containing the keyword w: First, send the trapdoor and search on the virtual binary tree; second, record the file identifiers that meet the conditions; third, return NewIDt; fourth, the client decrypts NewIDt; fifth, query the search results of the session; sixth, calculate the tag t of each id in OldID; seventh, record the deleted tag t; eighth, return DelIDt; ninth, the client decrypts DelIDt; tenth, delete the file identifiers in DelID from OldID; eleventh, save NewID and OldID’ to the buffer. If you want to search for files containing the keyword w, you need to calculate the search trapdoor F using the usage information of w stored by the client Ks(w||i||v), after sending it to the cloud server, the cloud server starts searching from the root node on the virtual binary tree VBTree until it reaches the leaf node. Due to the limitation of the search times i, this search can only find the newly inserted data after i - 1 searches. Then, the path Path(V) from the root node to the leaf node is converted from binary encoding to decimal to obtain the file identifier id i (where i is the number of files containing w). The cloud server encrypts the obtained id i and the keyword w, encrypts it as t←F Kt (w,id i ) and records it in NewIDt, and sends it to the client to obtain id i recorded in NewID. Then the client needs to obtain the set of files OldID that met the conditions in the previous search from the cache cache, calculate the tag t with w and send it to the cloud server to check if t exists in the Bloom filter BF. If it exists, it means that this file has deleted w. Then the encrypted record is in DelIDt, which is returned to the client for decryption. Then, the files that have deleted w are removed from OldID, and together with NewID, they are saved in the cache as the result of this search.
[0035] To verify the practicality of the proposed scheme of the present invention, the designed dynamically searchable encryption scheme that satisfies forward and backward security is applied to the location privacy protection in the vehicle - to - everything (V2X) environment, including: As Figure 7 shown, there are two entities in the scheme, the client and the cloud server. When applying the present invention of this scheme, the client uploads the vehicle location data at different time points as privacy data to the virtual binary tree VBTree in the cloud server for storage. Subsequently, various operations are performed based on the virtual binary tree VBTree and the Bloom filter BF. There are mainly three algorithms in this scheme: Setup, Update, and Search; Setup(λ): Input the security parameter λ. The client initializes the secret keys Ks, Kt, the client hash table LR, and the height L of the virtual binary tree; The cloud server initializes the cloud hash table T as the virtual binary tree VBTree and the Bloom filter BF; Update(Ks,Kt,op,(w,id);T): Ks is the key used to construct the encrypted index and the search trapdoor, Kt is the key used to construct the tag t, op indicates whether the update operation is add or delete, (w,id) is the data to be operated on, w is the location information, id is the vehicle number, and T is the virtual binary tree VBTree in the cloud. After inputting the above information, the client performs an update operation on the virtual binary tree. If it is an addition, execute steps 2.2 - 2.16 in S102. If it is a deletion, execute steps 3.2 - 3.4; Search(type, q): type is the query type, and q is the information to be queried; when type = 0, query which vehicles have stayed at a certain location, input the location w for query, and execute steps 4.3 - 4.14 in S102 to obtain the vehicle id; when type = 1, query which vehicles have stayed at these locations, input locations w1, w2,... w u , execute the join query in S103 to obtain the vehicle id; when type = 2, query whether a certain vehicle has stayed at a certain location, input the location w and the vehicle id, and execute the boolean query in S103 to obtain true or false; when type = 3, query which vehicles have stayed within a certain location range, input the location range w1, w2, and execute the range query in S103 to obtain the vehicle id.
[0036] Next, Figure 7 will be elaborated in detail: As Figure 7 shown, different color blocks represent different location information. The location information is used as the keyword w, and the vehicle number is used as the file identifier id. The client can encrypt the vehicle's location information (w, id) at a certain moment and upload it to the cloud server for storage on the virtual binary tree VBTree; after a period of time, the client can upload the new vehicle location information (w', id) to the cloud server to complete data update.
[0037] Embodiment 2: To achieve the above object, as Figure 6 shown, the present invention discloses a dynamic searchable encryption system with forward and backward privacy, including: A data storage module 11, which is used to obtain encrypted data, store the encrypted data based on the virtual binary tree VBTree, and generate an encrypted database; A forward and backward privacy module 12, which is used to manage the encrypted database based on a pre - constructed version control library to achieve the forward privacy of dynamic searchable encryption, record the data deletion of the encrypted database based on a pre - constructed Bloom filter BF to achieve the backward privacy of searchable encryption; record the search results of the encrypted database based on a caching mechanism; A complex query module 13, which is used to query the processed encrypted database based on multiple complex queries, where the complex queries include join queries, boolean queries, and range queries, to obtain the final query result.
[0038] Based on the same inventive concept, the present invention further provides a computer device, which includes: one or more processors, and a memory for storing one or more computer programs; the program includes program instructions, and the processor is configured to execute the program instructions stored in the memory. The processor may be a Central Processing Unit (CPU), or may also be other general-purpose processors, Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field-Programmable Gate Arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. It is the computing core and control core of the terminal, and is used to implement one or more instructions. Specifically, it is used to load and execute one or more instructions in the computer storage medium to implement the above method.
[0039] It should be further noted that, based on the same inventive concept, the present invention further provides a computer storage medium, on which a computer program is stored, and the computer program, when run by a processor, executes the above method. The storage medium may adopt any combination of one or more computer-readable media. The computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium. The computer-readable storage medium may, for example, but is not limited to, an electrical, magnetic, optical, electrical, magnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the above. More specific examples (non-exhaustive list) of the computer-readable storage medium include: an electrical connection having one or more wires, a portable computer disk, a hard disk, a Random Access Memory (RAM), a Read-Only Memory (ROM), an Erasable Programmable Read-Only Memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present invention, the computer-readable storage medium may be any tangible medium that contains or stores a program, and the program may be used by or combined with an instruction execution system, apparatus, or device.
[0040] In the description of this specification, the description with reference to terms such as "one embodiment", "example", "specific example", etc. means that the specific features, structures, materials, or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of the present disclosure. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described may be combined in any one or more embodiments or examples in a suitable manner.
[0041] The above has shown and described the basic principles, main features and advantages of the present disclosure. Those skilled in the art should understand that the present disclosure is not limited by the above embodiments. What is described in the above embodiments and the specification only illustrates the principles of the present disclosure. Without departing from the spirit and scope of the present disclosure, the present disclosure will have various changes and improvements, and these changes and improvements all fall within the scope of the present disclosure claimed.
Claims
1. A dynamic searchable encryption method with forward and backward privacy, characterized in that: The method comprises the following steps: Obtain encrypted data, store the encrypted data based on the virtual binary tree VBTree, and generate an encrypted database; The encrypted database is managed based on the pre-built version control library to achieve dynamic searchable encrypted forward privacy. The data deletion of the encrypted database is recorded based on the pre-built Bloom filter BF to achieve searchable encrypted backward privacy. The search results of the encrypted database are recorded based on the cache mechanism to obtain the processed encrypted database. The processed encrypted database is queried based on a variety of complex queries, wherein the complex queries include join queries, Boolean queries and range queries, to obtain a final query result.
2. A dynamic searchable encryption method with forward and backward privacy according to claim 1, characterized in that: The encrypted data is stored based on the virtual binary tree VBTree to organize the index elements into the virtual binary tree VBTree in a top-down manner; The pre-built version control library includes a local repository and a cloud repository. The complex query can be converted into a query for all files corresponding to a single keyword, and then the result sets of multiple keywords are intersected as a join query, the union is a range query, or checking whether a certain file exists in the result set is a Boolean query.
3. A dynamic searchable encryption method with forward and backward privacy according to claim 2, characterized in that: The virtual binary tree VBTree has the following properties: Full binary tree: A full binary tree is a tree with 2 L -1 tree node and 2 L-1 A binary tree with leaves, where L is the height of the tree; Path(V): Given a tree node V, Path(V) represents a string consisting of all tree branches starting from the root to the current node V; Nodes(i): Let i ∊[0,2 L-1 - 1], leaf i represents the i-th leaf in the tree, and Nodes(i) represents the set of all traversed nodes from the root to the leaf; A VBTree is stored in a hash table as follows: Each tree node contains zero or more different encryption keywords. The hash table only stores encrypted keywords and does not store any tree nodes or branches. is the keyword w of index file identifier i, where i ∊[0,2 L-1 -1], insert the keyword into each tree node of Nodes(i); The elements on the hash table are: {(H1(Path(V)||F Ks (w||i||v)), t)} V∊Nodes(i) Where t = F Kt (w,id), F is a keyed pseudo-random function, H1 is a random oracle, V is a tree node containing keyword w, Ks, Kt is a set of keys of the data owner, w is the keyword, id is the file identifier, v is the version number of keyword w, and i is the number of searches for keyword w.
4. A dynamic searchable encryption method with forward and backward privacy according to claim 3, characterized in that: The pre-built version control libraries are as follows: Given a keyword w, the vth version is denoted as w||v, and the vth version trapdoor is denoted as F Ks (w||v), historical search queries and updates are managed by a version control repository; Version control library: The version control library of the dynamic symmetric searchable encryption scheme includes a local repository LR and a cloud repository CR. LR is a local hash table and CR is a cloud hash table. On the client side, LR(w) represents the usage information of keyword w. The client side includes data owners and data users. Owners and users share the same LR. For each keyword w, LR(w) has three attributes: b, V l , n l ,as follows: LR(w).b indicates whether the data user has queried the latest version of keyword w. The initial state of LR(w).b is false, indicating that the latest version of this keyword has not been leaked. If the keyword w has been searched, LR(w).b is set to true, indicating that the keyword has been leaked to the cloud server according to the search pattern; LR(w).V l Indicates the latest version of keyword w; LR(w).n l Indicates the file identifier of the last match of keyword w; On the cloud server side, CR is viewed as multiple encrypted single linked lists. Let H2 and H3 be different random oracles. The encrypted items in CR are in key-value form (H2(F Ks (w||i||v)), H3(F Ks (w||i||v))⊕F Ks (w||i old ||(v-1))), the cloud server uses the current trapdoor to obtain the previous trapdoor to search all results. The cloud server cannot deduce the trapdoor for version v + 1 from the vth version, thereby protecting the forward privacy of dynamic searchable encryption.
5. A dynamic searchable encryption method with forward and backward privacy according to claim 1, characterized in that: The process of recording data deletion of the encrypted database based on the pre-built Bloom filter BF includes: Use Bloom filter BF to record the deletion of encrypted data. If a deletion operation is performed on (w, id), only t of this item needs to be calculated, where t = F Kt (w,id), use k hash functions to map it to k positions of the binary vector, set the value of the position to 1, and add the element to BF; When performing a search, k hash functions are used again to calculate the k positions of t corresponding to the binary vector, and check whether the values at the positions are all 1. If all are 1, it means that the keyword w and its corresponding file id t exist in BF, then the deletion operation has been performed and this id is not returned.
6. A dynamic searchable encryption method with forward and backward privacy according to claim 1, characterized in that: The process of recording the search results of the encrypted database based on the cache mechanism: Use the cache to record the search results of a single keyword. This search only needs to query the newly inserted data between the last search and the current search, and then get the result of the last search in the cache. After obtaining the sum of the two results, check one by one whether t exists in BF, filter out the data that exists in BF, return the id that belongs to the sum of the two search results and does not exist in BF, and update the data in the cache to the returned search results.
7. A dynamic searchable encryption method with forward and backward privacy according to claim 1, characterized in that: When performing the connection query, if you want to query the files that contain the keywords w1 and w2 together and finally return the result set, that is, query each keyword to obtain the file ID that contains this keyword and has not been deleted, and finally take the intersection of the query results of all keywords as the result of the connection query; When performing a Boolean query, if you want to query whether the file with identifier id1 contains keyword w1, you need to query all files containing keyword w1 and return the result set, and finally check whether id1 is included in the result set; When performing a range query, if you want to query for keyword w that is greater than or equal to a and less than or equal to d, first find a keyword whose size meets the requirement, assume that w1 and w2 meet the requirement, then query the files containing keywords w1 and w2, and finally return the file id, that is, query each keyword, obtain the file id that contains this keyword and has not been deleted, and finally take the union of the result sets of all keywords as the result of the range query.
8. A dynamic searchable encryption system with forward and backward privacy, using a dynamic searchable encryption method with forward and backward privacy as claimed in any one of claims 1 to 7, characterized in that: include: A data storage module is used to obtain encrypted data, store the encrypted data based on a virtual binary tree VBTree, and generate an encrypted database; The forward and backward privacy module is used to manage the encrypted database based on the pre-built version control library to achieve dynamic searchable encrypted forward privacy, record the data deletion of the encrypted database based on the pre-built Bloom filter BF to achieve searchable encrypted backward privacy; record the search results of the encrypted database based on the cache mechanism to obtain the processed encrypted database; The complex query module is used to query the processed encrypted database based on multiple complex queries, wherein the complex queries include connection queries, Boolean queries and range queries, to obtain the final query results.
9. A terminal device, comprising a memory, a processor, and a computer program stored in the memory and capable of running on the processor, characterized in that: The memory stores a computer program that can be run on a processor. When the processor loads and executes the computer program, a dynamic searchable encryption method with forward and backward privacy according to any one of claims 1 to 7 is adopted.
10. A computer-readable storage medium having a computer program stored therein, characterized in that: When the computer program is loaded and executed by the processor, a dynamic searchable encryption method with forward and backward privacy as described in any one of claims 1 to 7 is adopted.
Citation Information
Patent Citations
Encryption method with forward and backward security and recoverable keyword shielding
CN112311781A
Efficient fault-tolerant dynamic phrase searching method based on forward and backward privacy
CN114531220A
Fuzzy keyword searchable encryption method and system with privacy protection
CN115495792A
Dynamic searchable encryption method, decryption method, encryption device and decryption device
CN116418513A
Multilevel data analysis
US12210839B1
Cited By
Cloud file query method and related equipment
CN121560830A