A Dynamic Searchable Encryption Method and System with Forward and Backward Privacy

Abstract

The present invention discloses a dynamic searchable encryption method and system with forward and backward privacy, which relates to the fields of information retrieval and cryptography technology. The method comprises the following steps: obtaining encrypted data, storing the encrypted data based on a virtual binary tree (VBTree), and generating an encrypted database; managing the encrypted database based on a pre-built version control library to achieve forward privacy of the dynamic searchable encryption, recording data deletions in the encrypted database based on a pre-built Bloom filter (BF) to achieve backward privacy of the searchable encryption; recording search results of the encrypted database based on a cache mechanism; and querying the processed encrypted database 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. The method can achieve complex queries while ensuring forward and backward privacy of the dynamic searchable encryption.

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 cost-effective and convenient, when user 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 during 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 the privacy of users 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 privacy information of the user is leaked to the server. This not only effectively protects the privacy of users 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 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 status 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 achieve complex queries while ensuring the forward privacy and backward privacy of data.

[0007] In a first aspect, the purpose of the present invention can be achieved by the following technical solutions: A dynamic searchable encryption method with forward and backward privacy, the method comprising the following steps:

[0008] Obtain encrypted data, store the encrypted data based on a virtual binary tree VBTree, and generate an encrypted database;

[0009] 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 to obtain a processed encrypted database;

[0010] 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.

[0011] In combination with the first aspect, in certain 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;

[0012] 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.

[0013] In combination with the first aspect, in some implementations of the first aspect, the method further includes: The virtual binary tree VBTree has the following properties:

[0014] 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;

[0015] 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;

[0016] 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;

[0017] The VBTree is stored in a hash table as follows:

[0018] Each tree node contains zero or more different encrypted keywords,

[0019] The hash table only stores the encrypted keywords and does not store any tree nodes and tree branches,

[0020] 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);

[0021] The elements on the hash table are:

[0022] {(H1(Path(V)||F Ks (w||i||v)), t)} V∊Nodes(i)

[0023] 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.

[0024] In combination with the first aspect, in some implementations of the first aspect, the method further includes: The pre - constructed version control library is as follows:

[0025] 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;

[0026] 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;

[0027] 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 ), as follows:

[0028] 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;

[0029] LR(w).V l represents the latest version of keyword w;

[0030] L.R(w).n l represents the file identifier of the last file that matched keyword w;

[0031] 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 the dynamic searchable encryption.

[0032] Combined with the first aspect, in some implementation manners of the first aspect, the method further includes: The process of recording the deletion of data in the encrypted database based on the pre-constructed Bloom filter BF includes:

[0033] 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 in the binary vector, and set the values at the positions to 1 to implement adding the element to BF;

[0034] When performing a search, k hash functions are used again to calculate the k positions corresponding to t in the binary vector, and check whether the values at these positions are all 1. If all are 1, it means that the keyword w and its corresponding file id t exist in the BF, indicating that a deletion operation has been performed, and this id is not returned.

[0035] 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:

[0036] Use the cache 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, then obtain the results of the last search in the cache, and after obtaining the sum of the two results, check one by one whether t exists in the BF, filter out the data existing 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.

[0037] Combined with the first aspect, in some implementation manners of the first aspect, the method further includes: when performing a join query, if you want 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;

[0038] When performing a boolean query, if you want to query whether the 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;

[0039] When performing a range query, if you want 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.

[0040] In a second aspect, in order to achieve the above object, the present invention discloses a dynamic searchable encryption system with forward and backward privacy, including:

[0041] A data storage module for obtaining encrypted data, storing the encrypted data based on a virtual binary tree VBTree, and generating an encrypted database;

[0042] Forward and backward privacy module, which is used to manage an 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 search results of the encrypted database based on a caching mechanism to obtain a processed encrypted database;

[0043] Complex query module, 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 a final query result.

[0044] In another aspect of the present invention, in order to achieve the above - mentioned purpose, 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, it adopts a dynamic searchable encryption method with forward and backward privacy as described above.

[0045] In yet another aspect of the present invention, in order to achieve the above - mentioned purpose, 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, it adopts a dynamic searchable encryption method with forward and backward privacy as described above.

[0046] Advantages of the present invention:

[0047] The present invention can naturally express hierarchical relationships and multi - element 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. Description of the drawings

[0048] 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;

[0049] Figure 1 is a schematic flowchart of the method of the present invention;

[0050] Figure 2 shows the logical view of VBTree and the corresponding hash representation diagram;

[0051] Figure 3 shows a version control library diagram;

[0052] Figure 4 shows a flowchart of keyword insertion;

[0053] Figure 5 Shows a flowchart for searching files containing keywords;

[0054] Figure 6 Is a schematic diagram of the system structure of the present invention;

[0055] Figure 7 Is a schematic diagram of the present invention applied to the vehicle networking for data storage. Detailed implementation manners

[0056] Next, the technical solutions in the embodiments of the present invention will be clearly and completely described in conjunction with the accompanying 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 shall fall within the protection scope of the present invention.

[0057] Embodiment 1:

[0058] As Figure 1 shown, a dynamic searchable encryption method with forward and backward privacy, the method includes the following steps:

[0059] S101: Obtain encrypted data, store the encrypted data based on the virtual binary tree VBTree to generate an encrypted database;

[0060] 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;

[0061] The virtual binary tree VBTree has the following attributes:

[0062] 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;

[0063] 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;

[0064] Nodes(i): Let i ∊ [0, 2 L-1 - 1], leaf i represent the i-th leaf in the tree, and Nodes(i) represents the set of all traversed nodes from the root to the leaf;

[0065] The VBTree is stored in the hash table as follows:

[0066] Each tree node contains zero or more different encrypted keywords.

[0067] The hash table only stores encrypted keywords and does not store any tree nodes or tree branches.

[0068] 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).

[0069] The elements on the hash table are:

[0070] {(H1(Path(V)||F Ks (w||i||v)), t)} V∊Nodes(i)

[0071] 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.

[0072] Specifically, use a virtual binary tree (VBTree) to store encrypted data, and the implementation steps are as follows:

[0073] Step 1.1, Setup phase, input the security parameter λ, and generate λ - bit binary data as keys Ks, Kt: Ks, Kt ← {0, 1} λ ;

[0074] 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;

[0075] 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 one - dimensional data. Given the keyword w and the corresponding attribute "attr", the keyword w is encoded into the string "attr:w";

[0076] 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 node V starts from the root node, i.e., the initial Path(V) = '', and then calculates the binary path of the leaf node according to the id, and sequentially adds '0' or '1' to Path = '', until it is filled L - 1 times. The version number v of keyword w is shown in step 2.2, and the search count i is shown in step 4.4;

[0077] Step 1.5, Update phase, the client sends data to the cloud server, and the cloud server inserts elements into VBTree: {(H1(Path(V)||F Ks (w||i||v)), t)} V∊Nodes(i) , where t←F Kt (w,id).

[0078] S102: Manage the encrypted database based on a pre - constructed version control library to achieve forward privacy of dynamic searchable encryption, record the 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, thereby improving the search efficiency; the pre - constructed version control library includes a local repository and a cloud repository;

[0079] Use the version control library to achieve forward privacy of dynamic searchable encryption, and the implementation steps are as follows:

[0080] 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←⊥;

[0081] Among them, LR contains b, V l , n l Three attributes:

[0082] LR(w).b indicates whether the data user has queried the latest version of keyword w,

[0083] LR(w).V l indicates the latest version of keyword w,

[0084] L.R(w).n l indicates the file identifier of the last file that matches keyword w;

[0085] 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;

[0086] Step 2.3, Then initialize its LR: LR(w).b←false, LR(w).V l ←0, LR(w).nl ← -1;

[0087] Step 2.4, Obtain the version number of keyword w: v ← LR(w).V l ;

[0088] 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 times i can be seen in Step 4.4;

[0089] Step 2.6, Update the cloud hash table CR, where CR records the trapdoor of the keyword: CR[w] ← (H2(F Ks (w||i||v)), H3(F Ks (w||i||v)) ⊕ null);

[0090] 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)) ← CR[H2(F Ks (w||i||v))] ⊕ H3(F Ks (w||i||v)) and other previous versions, where i old is the search times corresponding to keyword w of version (v - 1) stored in CR, and i is the search times corresponding to keyword w of version v stored in CR,

[0091] 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 vth version, which is a key design consideration of the forward private dynamic SSE scheme;

[0092] Step 2.7, After performing the operation of inserting keyword w, update the latest matching document identifier of w: LR(w).n l ← id.

[0093] 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;

[0094] Step 2.9, Obtain the version number of keyword w: v ← LR(w).Vl ;

[0095] Step 2.10. 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;

[0096] Step 2.11. After performing the operation of inserting the keyword w, update the latest matching document identifier of w: LR(w).n l ← id.

[0097] Step 2.12. Update the version number of the keyword: v ← LR(w).V l + 1, LR(w).V l ← v;

[0098] Step 2.13. At this time, the new version has not been searched: LR(w).b ← false;

[0099] Step 2.14. Calculate the elements to be inserted into VBTree in the cloud server, and insert the following elements 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 count i is shown in Step 4.4;

[0100] 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)));

[0101] Step 2.16. After performing the operation of inserting the keyword w, update the latest matching document identifier of w: LR(w).n l ← id.

[0102] The process of recording data deletion of the encrypted database based on the pre - constructed Bloom filter BF includes:

[0103] 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;

[0104] Step 3.2. Update phase: If you want to delete the keyword w in the file with identifier id, calculate its tag t: t←F Kt (w,id);

[0105] 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;

[0106] 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;

[0107] 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;

[0108] 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.

[0109] The use of a cache mechanism to record the search results is implemented as follows:

[0110] Step 4.1. Setup phase: Initialize the list C to record the search times of each keyword: C←⊥;

[0111] 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 ));

[0112] 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:

[0113] Step 4.4. Obtain the search count of keyword w: i ← C[w];

[0114] Step 4.5. Record that the latest version of keyword w has been searched: LR(w).b ← true;

[0115] Step 4.6. Generate a search trapdoor: tkn ← F Ks (w||i||LR(w).V l );

[0116] 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))

[0117] 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 sequence 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;

[0118] 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},

[0119] The result set NewIDt only contains the newly inserted encrypted data after the previous search, not all files corresponding to keyword w;

[0120] Step 4.9. The cloud server sends NewIDt to the client, and the client decrypts it using the key Kt to obtain the set NewID containing file identifiers,

[0121] At this time, NewID only contains the file ids newly inserted after the previous search;

[0122] Step 4.10. Obtain the previous search result set: OldId ← EDB cache [tkn];

[0123] At this time, OldId contains all the results obtained in the previous search. Some of these files may have deleted keyword w and need to be determined whether they have been deleted in the Bloom filter again;

[0124] Step 4.11. For each file id in OldId, calculate the tag t, t ← FKt (w, id), determine whether tag t exists in the Bloom filter: if Φ.Check(H, B, t) is false, if it returns true, it means t is not in the Bloom filter, otherwise it means it exists and record it in the deletion set: DelIdt ← DelIdt ∪ {t i};

[0125] Step 4.12, delete the data existing in the Bloom filter: OldId ← OldId \ {(id i ): ∃t i ∊ DleIdt s.t. t = t i}

[0126] 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;

[0127] Step 4.13, calculate the final result set: Res ← NewId ∪ OldId;

[0128] Step 4.14, save the result set to the cache: EDB cache [tkn] ← Res;

[0129] 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.

[0130] 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.

[0131] The implementation steps of the join query are as follows:

[0132] Step 5.1 - 1, search for files containing the keyword {w i} i∊q , first obtain the version number and search count of each keyword: v i ←LR(w i ).V l , i i ←C[w i ;

[0133] Step 5.1 - 2, record that the latest version of the keyword {w i} i∊q has been searched: LR[w i .b ← true;

[0134] Step 5.1-3, generate i search trapdoors: tkn i ←F<s Ks (w||i i ||v i );

[0135] Step 5.1-4, the client sends the search trapdoor 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 ;

[0136] Step 5.1-5, take the intersection in all the result sets: Intersection;

[0137] The implementation steps of the boolean query are as follows:

[0138] Step 5.2-1, query whether the specified file (with identifier id) contains the specified keyword (w), and obtain the version number and search times of the keyword: v←LR(w).V l , i←C[w];

[0139] Step 5.2-2, record that the latest version of the keyword w has been searched: LR[w].b←true;

[0140] Step 5.2-3, generate a search trapdoor: tkn←F Ks (w||i||v i );

[0141] Step 5.2-4, generate the tag t to be retrieved: t←F Kt (w,id);

[0142] Step 5.2-5, the client sends the search trapdoor 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 the result set: Res;

[0143] Step 5.2-6, retrieve whether Res contains the result t to obtain the retrieval result true or false;

[0144] The implementation steps of the range query are as follows:

[0145] Step 5.3-1, search for the files corresponding to the keywords within a specific range. First, the client needs to search for all the keywords {w i} i∊q ;

[0146] Step 5.3-2, first obtain the version number and search times of each keyword: vi ←LR(w i ).V l ,i i ←C[w i ;

[0147] Step 5.3-3, Record the latest version of the keyword set {w i} i∊q has been searched: LR[w i .b ← true;

[0148] Step 5.3-4, Generate i search trapdoors: tkn i ←F Ks (w||i i ||v i );

[0149] 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 ;

[0150] Step 5.3-6, Take the union of all result sets: Union;

[0151] Specifically, the solution of the present invention will be further elaborated by the following embodiments:

[0152] Next, Figures 2 - 5 will be introduced in detail.

[0153] The logical view of VBTree and the corresponding hash table are as Figure 2 shown. t = F kt (a, id1); i = 0, indicating that the number of searches is 0; v = 0, indicating that the keyword a is inserted for the first time. The logical view of 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 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) indicates 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, the current version is 0, and it is the first time to insert the keyword a into the database. At the same time, use the hash function to calculate the position corresponding to the index H1(Path(V)||F Ks (a||i||v)) and store the element t at that 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.

[0154] The version control library diagram is as 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))).

[0155] 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;

[0156] On the client side, LR(w) represents the usage information of the 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 .

[0157] 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 version from the vth version, thereby protecting the forward privacy of dynamic searchable encryption.

[0158] 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, 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 the current version as not searched: LR(w).b ← false, update the VBTree, update the CR, and finally update LR(w).n l .

[0159] As Figure 5 shown, search for the file 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 the file containing the keyword w, you need to calculate the search trapdoor F Ks (w||i||v), send it to the cloud server, and 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 count i, this search can only search for the newly inserted data after i - 1 searches. Then, convert the path Path(V) from the root node to the leaf node from binary encoding to decimal to obtain the file identifier id i (here 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 iIt is recorded in NewID. Then the client needs to obtain the set of files OldID that met the search criteria last time from the cache cache, calculate the tag t with w and send it to the cloud server to check whether t exists in the Bloom filter BF. If it exists, it means that this file has deleted w. Then the encrypted content is recorded in DelIDt and returned to the client for decryption. After that, the files that have deleted w are removed from OldID, and together with NewID, they are saved in the cache as the search results for this time.

[0160] To verify the practicality of the solution designed in the present invention, the designed dynamically searchable encryption scheme that meets forward and backward security is applied to the location privacy protection in the vehicle networking environment, including:

[0161] As Figure 7 shown, there are two entities in the solution, the client and the cloud server. When applying the invention of this solution, the client will upload 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: Setup, Update, and Search in this solution;

[0162] Setup(λ): Input the security parameter λ. The client initializes the secret keys Ks and 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;

[0163] 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;

[0164] Search(type, q): type is the query type, and q is the information to be queried; 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; type = 1, query which vehicles have stayed at these several locations. Input the locations w1, w2,... w u, perform the join query in S103 to obtain the vehicle ID; when type = 2, query whether a certain vehicle has stopped at a certain location, input the location w and the vehicle ID, and perform the boolean query in the steps of S103 to obtain true or false; when type = 3, query which vehicles have stopped within a certain location range, input the location range w1, w2, and perform the range query in the steps of S103 to obtain the vehicle ID.

[0165] Next, Figure 7 will be elaborated in detail:

[0166] 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 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.

[0167] 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:

[0168] 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;

[0169] 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;

[0170] 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.

[0171] 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.

[0172] 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 be, for example, but 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.

[0173] 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 expressions 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.

[0174] 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 includes the following steps: Obtain encrypted data, store the encrypted data based on the 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 the 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; 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 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 includes data owners and data users, and the 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 represents whether the data user has queried the latest version of the 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, then LR(w).b is set to true, indicating that the keyword has been leaked to the cloud server side according to the search pattern; LR(w).V l represents the latest version of keyword w; L.R(w).n l Indicates the file identifier of the last matching keyword w; On the cloud server side, the CR is regarded as multiple encrypted singly linked lists. Let H2 and H3 be different random oracles, and the encrypted items in the 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 deduce the trapdoor of the v+1th version from the vth version, thereby protecting the forward privacy of dynamic searchable encryption; 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 the t of this item, where t = F Kt (w, id), and use k hash functions to map it to k positions in the binary vector, and set the values at the positions to 1 to add the element to BF; When performing a search, use 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 the keyword w and its corresponding file id t exist in BF, then a deletion operation has been performed, and this id is not returned; Query the processed encrypted database based on multiple complex queries. Among them, the complex queries include join queries, Boolean queries, and range queries to obtain the final query result.

2. The dynamic searchable encryption method with forward and backward privacy according to claim 1, wherein, Store the encrypted data based on the virtual binary tree VBTree, and organize the 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 query 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 a join query, the union for a range query, or checking whether a certain file exists in the result set for 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 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 the tree node V, Path(V) represents the string formed by connecting all the tree branches from the root of the tree to the current node V; Nodes(i): Let \(i\in[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 encrypted keywords and does not store any tree nodes and tree branches, For the keyword w of the 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 are 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 search times of keyword w.

4. 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 caching 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 BF, filter out the data that exists in BF, return the ids that belong to the sum of the two search results and do not exist in BF, and update the data in the cache to the returned search results.

5. A dynamic searchable encryption method with forward and backward privacy according to claim 1, characterized in that, When performing a join query, if you want to query files that commonly 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 for all keywords as the result of the join query; When performing a boolean query, if you want 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 you want 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. Suppose w1 and w2 meet the requirements, and then query the files that contain keywords w1 and w2. 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 for all keywords as the result of the range query.

6. A dynamic searchable encryption system with forward and backward privacy adopts a dynamic searchable encryption method with forward and backward privacy described in any one of claims 1 to 5, characterized in that Including: A data storage module for obtaining encrypted data, storing the encrypted data based on the virtual binary tree VBTree, and generating an encrypted database; A forward and backward privacy module for managing the encrypted database based on a pre-constructed version control library to achieve the forward privacy of dynamic searchable encryption, recording the data deletion of the encrypted database based on a pre-constructed Bloom filter BF to achieve the backward privacy of searchable encryption; recording the search results of the encrypted database based on a caching mechanism to obtain a processed encrypted database; A complex query module for querying 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.

7. 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 run on a processor. When the processor loads and executes the computer program, it adopts a dynamic searchable encryption method with forward and backward privacy described in any one of claims 1 to 5.

8. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is loaded and executed by the processor, it adopts a dynamic searchable encryption method with forward and backward privacy described in any one of claims 1 to 5.

Images