CN108039943B - Verifiable encryption searching method - Google Patents

Verifiable encryption searching method Download PDF

Info

Publication number
CN108039943B
CN108039943B CN201711277295.7A CN201711277295A CN108039943B CN 108039943 B CN108039943 B CN 108039943B CN 201711277295 A CN201711277295 A CN 201711277295A CN 108039943 B CN108039943 B CN 108039943B
Authority
CN
China
Prior art keywords
server
key
client
mpt tree
tree structure
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201711277295.7A
Other languages
Chinese (zh)
Other versions
CN108039943A (en
Inventor
李琦
朱洁
王骞
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shenzhen Graduate School Tsinghua University
Original Assignee
Shenzhen Graduate School Tsinghua University
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Shenzhen Graduate School Tsinghua University filed Critical Shenzhen Graduate School Tsinghua University
Priority to CN201711277295.7A priority Critical patent/CN108039943B/en
Publication of CN108039943A publication Critical patent/CN108039943A/en
Application granted granted Critical
Publication of CN108039943B publication Critical patent/CN108039943B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0643—Hash functions, e.g. MD5, SHA, HMAC or f9 MAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computational Linguistics (AREA)
  • Power Engineering (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

The invention discloses a verifiable encryption searching method, which comprises the following steps: u1, the client calculates the reverse index for the file set, and calculates a group of key value pairs for each keyword in the reverse index; inserting each set of key value pairs into the MPT tree structure; calculating and storing a root hash of the MPT tree structure; u2, the client uploads the initialized MPT tree to the server, and when the file set is updated, the updated key value pair is uploaded to the server; u3, the client sends a challenge token to the server and receives the search result returned by the server and the reference information for verification; u4, the client matches the challenge token and the reference information, and reconstructs the root hash of the MPT tree structure according to the matching result; and U5, comparing the reconstructed root hash with the root hash stored by the client. The encryption searching method can simultaneously verify freshness attack and integrity attack caused by the dishonest of the server, and has the advantages of wide application range and low cost.

Description

Verifiable encryption searching method
[ technical field ] A method for producing a semiconductor device
The invention relates to the field of encrypted searching, in particular to a verifiable encrypted searching method.
[ background of the invention ]
Cloud storage enables users to access data anytime and anywhere, and greatly facilitates data sharing among users. However, at the same time, cloud storage brings about many security problems, and can be generally classified into the following two categories:
(1) availability (availability). The cloud server is required to ensure that data is not lost, and a user can use the cloud end as a data center to perform data backup and synchronization. At present, a general cloud service provider adopts a multi-copy mode to ensure the availability of data, that is, multiple copies of data are respectively written into other storage nodes, when one node fails, data on other nodes continue to provide services, and meanwhile, lost data on the failed node is quickly recovered through data copies in other nodes. Currently, relevant academic research on data availability includes Proof of Possession of Data (PDP) and Proof of recoverability of data (PoR).
(2) Privacy (privacy). The cloud server is required to guarantee the privacy of the data and not reveal the data. At present, a cloud service provider generally adopts a data Encryption mode to protect private data, but data Encryption often causes reduction of data availability, for example, data loses searchability, and thus encrypted search (secure Encryption) is due.
The Encryption search technology is mainly divided into two categories, namely, symmetric Encryption search (SSE) and Asymmetric Encryption Search (SAE). Due to the efficiency problem of asymmetric encryption search, the current encryption search field pays more attention to symmetric encryption search.
A model of symmetric encrypted search is shown in fig. 1. The user encrypts the data and uploads the data to the cloud, and meanwhile, the user needs to additionally upload an encryption index (index) to enable the cloud to search the data through the index. When a user needs to search for data, a trapdoor (trapdoor) is generated, which is associated with a keyword, so that the user can perform content search without exposing the content of the keyword.
The encrypted search enables a user to meet the search requirement while protecting data privacy, but the encrypted search cannot guarantee the correctness of the search result. That is, the encrypted search is based on the premise that the cloud server is honest, that is, the server can follow the protocol with the user to correctly perform the search operation, but in practical applications, the cloud server is often not trusted, for example, the cloud server may return a small amount of search results to the user or may not return the search results to the user in order to save the computation overhead and the communication overhead. To prevent dishonest behavior of cloud servers, the academia has proposed a Verifiable Symmetric Encryption search mechanism (VSSE). The verifiable encrypted search allows a user to verify the search result to detect the dishonest behavior of the server, and ensures the correctness of the encrypted search.
In verifiable encrypted searches, security attacks due to server dishonest can be mainly classified into the following two types:
data Freshness Attack (Data Freshness attach): in encrypted searching, a data freshness attack refers to a server (attacker) attempting to return old search results, rather than the latest search results. For example, byn＝{1,2,…,nRepresents the old version of the data set, withn+1To represent the latest data set, the search results returned by the server are data setsiWherein 1 ≦ i ≦ n.
Data Integrity Attack (Data Integrity Attack): in encrypted searching, a data integrity attack refers to an attempt by a server (attacker) not to get the complete search results from the user. For example, let τ denote the user's search trapdoor in the encrypted search, the search result that the user should obtain is F (τ), and the search result returned by the server is G (τ), where
Figure GDA0002474001730000021
And G (τ) may be
Figure GDA0002474001730000022
Data freshness attacks exist only in dynamic cryptographic search schemes, and not in the case of database statics. However, in reality, dynamic databases are common, so that protection against data freshness attacks is a problem that must be solved for verifiable encrypted searches. The data integrity attack includes not only the case that the server returns few search results, but also the case that the server does not return search results to avoid result verification. This problem is a serious one, but few studies have been made to consider it.
The above background disclosure is only for the purpose of assisting understanding of the inventive concept and technical solutions of the present invention, and does not necessarily belong to the prior art of the present patent application, and should not be used for evaluating the novelty and inventive step of the present application in the case that there is no clear evidence that the above content is disclosed at the filing date of the present patent application.
[ summary of the invention ]
The technical problem to be solved by the invention is as follows: the defects of the prior art are overcome, the verifiable encryption searching method is provided, freshness attack and integrity attack caused by the dishonest of the server can be verified at the same time, the application range is wide, and the cost is low.
The technical problem of the invention is solved by the following technical scheme:
a verifiable encrypted searching method executed by a client, comprising the following steps: u1, the client calculates an inverted index for the file set, and calculates a group of key value pairs for each keyword in the inverted index, wherein the key is a token corresponding to the keyword, and the value is the incremental hash sum of the file containing the keyword; inserting each group of key value pairs into an MPT tree structure to obtain an initialized MPT tree; calculating and storing root hash of the MPT tree structure constructed by each group of key value pairs; u2, the client uploads the initialized MPT tree to the server, and when the file set is updated, the updated key value pair is uploaded to the server; u3, the client sends challenge token to the server, receives the search result returned by the server and the reference information for verification, the reference information is the key and key value pair of the node in the MPT tree structure extracted by the server according to the existence or nonexistence of the leaf node in the MPT tree structure corresponding to the challenge token; u4, the client matches the challenge token and the reference information, and reconstructs the root hash of the MPT tree structure according to the matching result; u5, comparing the reconstructed root hash with the root hash stored by the client, if the root hash is the same as the reconstructed root hash, indicating that the server has no tampering behavior and the search result is accurate; if the results are different, the server is indicated to have tampering behaviors, and the search result is inaccurate.
A verifiable encryption search method executed by a server, S1, the server receives an initialized MPT tree uploaded by a client, receives an updated key value pair, and updates the initial MPT tree structure according to the updated key value pair to obtain a latest MPT tree structure; s2, the server searches according to the challenge token sent by the client to obtain a search result; s3, the server judges whether leaf nodes in the MPT tree structure corresponding to the challenge token exist or not according to the challenge token sent by the client, and the key and key value pair of the node in the MPT tree structure extracted according to the judgment result is used as reference information for verification; and S4, the server sends the search result and the reference information to the client.
A verifiable encryption searching method relates to a client and a server; a1, the client calculates an inverted index for the file set, and calculates a group of key value pairs for each keyword in the inverted index, wherein the key is a token corresponding to the keyword, and the value is the incremental hash sum of the file containing the keyword; inserting each group of key value pairs into an MPT tree structure to obtain an initialized MPT tree; calculating and storing root hash of the MPT tree structure constructed by each group of key value pairs; a2, the client uploads the initialized MPT tree to the server, and when the file set is updated, the updated key value pair is uploaded to the server; a3, the server receives the initialized MPT tree uploaded by the client, receives the updated key value pair, and updates the initial MPT tree structure according to the updated key value pair to obtain the latest MPT tree structure; a3, the client sends a challenge token to the server; the server searches according to the challenge token sent by the client to obtain a search result; the server judges whether leaf nodes in an MPT tree structure corresponding to the challenge token exist or not according to the challenge token sent by the client, and keys and key value pairs of the nodes in the MPT tree structure extracted according to the judgment result are used as reference information for verification; the server sends the search result and the reference information to the client; the client receives a search result returned by the server and reference information for verification; a4, the client matches the challenge token with the key in the reference information, and reconstructs the root hash of the MPT tree structure according to the matching result; a5, comparing the reconstructed root hash with the root hash stored by the client, if the root hash is the same as the reconstructed root hash, indicating that the server has no tampering behavior and the search result is accurate; if the results are different, the server is indicated to have tampering behaviors, and the search result is inaccurate.
Compared with the prior art, the invention has the advantages that:
the verifiable encryption searching method utilizes a novel MPT tree data structure and designs a reasonable mechanism to perfect defense against data freshness and data integrity attacks, and particularly can defend a server to return an empty result to avoid result verification. By constructing the MPT, the index used for result verification is separated from the index of encrypted search, so that the verification process can be combined with the search results obtained by any encrypted search scheme, and result verification service can be provided in a wide range. The challenge token is matched with the key in the reference information, the root hash of the MPT tree structure is reconstructed from the matching result, and the root hash stored by the client are compared and verified. According to the method, the server and the client can complete verification through one-round communication, the number of communication rounds is small, and the cost is low. In conclusion, the invention not only is a universal verifiable encryption search framework, but also perfectly solves the result verification problem in the encryption search with lower cost.
[ description of the drawings ]
FIG. 1 is a schematic diagram of a prior art symmetric cryptographic search model;
FIG. 2a is a diagram illustrating a case where key-value pairs are inserted into branch nodes of an MPT tree structure in a search method according to an embodiment of the present invention;
FIG. 2b is a diagram illustrating another situation in which key-value pairs are inserted into branch nodes of an MPT tree structure in the search method according to an embodiment of the present invention;
FIG. 2c is a diagram illustrating a situation where key-value pairs are inserted into leaf nodes of an MPT tree structure in the search method according to an embodiment of the present invention;
FIG. 2d is a diagram illustrating another situation where key-value pairs are inserted into leaf nodes of an MPT tree structure in the search method according to an embodiment of the present invention;
FIG. 3 is a diagram of an inverted index and key-value pairs in a search method according to an embodiment of the present invention;
FIG. 4 is a diagram illustrating an MPT tree structure constructed in the search method according to an embodiment of the present invention;
FIG. 5a is a diagram illustrating proof of results in the presence of a token searched by a user in a search method according to an embodiment of the present invention;
fig. 5b is a schematic diagram of a result certification when a token searched by a user does not exist in the search method according to the embodiment of the present invention.
[ detailed description ] embodiments
The present invention will be described in further detail with reference to the following detailed description and accompanying drawings.
The system framework capable of verifying the encryption search scheme comprises a client and a server, wherein the client uploads a verification index (index) corresponding to data of the client to a cloud; the cloud server (server) provides storage, search and verification services for the client; and verifying the search result returned by the cloud server after the client searches. Before describing the workflow of the system, the following gives the meanings of the labels and parts of the concepts that will be used in this embodiment.
Figure GDA0002474001730000051
The workflow of the system is defined as follows:
KGenC(1k)→{K1,K2is a probability calculation operation performed by the Client. Its input is a safety parameter and its output is a symmetric key set K1,K2。
InitC(K1,K2D) → { λ } is an initialization operation performed by the Client. Its input is a set of symmetric keys K1,K2And document binding D, the output of which includes a validation index λ. The Client uploads the authentication index lambda to the server.
PreUpdateC(K1,K2,f)→{τuIs a pre-update operation performed by the Client. The input of the system is a symmetric key set K and a file f to be updated, and the output is an update token set tauu. The Client will update the token setTo the cloud.
UpdateS(λ,τu) → λ', π is the update operation performed by Server. Its inputs are the authentication index lambda and the update token set tauuAnd the output is the updated verification index lambda' and the updated path pi. And the Server sends the update path to the Client.
UpdateC(rt, π) → { rt' } is the update operation performed by the Client. The input of the method is verification index root hash rt and an updating path pi, and the output is an updated root hash value.
ChallengeC(K1,w)→{τwIs a challenge operation initiated by the Client. Its input is a set of symmetric keys K1Outputting the challenge token tau corresponding to the key ww. The Client submits the token to the cloud.
ProveS(λ,τw) → ρ is the attestation operation performed by the Server. Its inputs are the authentication index lambda and a challenge token tauwThe output is the proof of result ρ. The server sends the result proof p to the Client that initiated the challenge.
VerifyC(K1,K2,Cw,ρ,τwRt): is a verification operation performed by the Client. The input of the key is a symmetric key set K1,K2Search results C returned by the serverwReference information p, challenge token τwAnd a root hash rt retained by the Client, and finally outputting an accept or a reject by the Verify algorithm.
MPT denotes the Mercker Patriella Tree (Merkle Patricia Tree, MPT). It was first proposed in Ethereum (Ethereum) to combine the traditional Trie Tree with the Merkle Tree, making the Tree function for both lookup and verification. The MPT has four types of nodes, which are a Blank Node (BN), a leaf Node (leaf Node, LN), a Branch Node (Branch Node, BN) and an Extension Node (EN). The hollow node is only a node which does not store any information, the leaf node stores a key-value pair (key-value pair), the extension node also stores a key-value pair, and the key values of the extension node are respectively the public prefixes of the child nodes and the hash values of the child nodes. The branch node has 17 elements, wherein the first 16 elements represent possible branches on the node, i.e. 16 hexadecimal numbers, and the 17 th element is a value range, when a key is matched at the branch node, the corresponding value of the key is stored in the element. Each node in the MPT is encoded by RLP and the encoded value is hashed, and a key value pair for each node is stored in the database, where the key is the hash of the RLP encoding for that node and the value is the RLP encoding for that node. Thus, each node can be referred to by the hash value, and the searchability and verifiability of the MPT are guaranteed at the same time. In this way, the root hash of the MPT becomes the fingerprint information of the whole tree, the value of the root hash is determined by the hash values of all the nodes at the lower layer, and any slight change of the nodes can cause the value of the root hash to change.
Incremental Hash functions (IHs) were first proposed by bellore et al and adopted by the CS2 scheme. The IH function is collision-resistant, defined as IH: {0,1}*→{0,1}lThe addition or subtraction of two random strings in the IH function does not produce a collision.
The flow of the encryption search method of the present embodiment will be specifically described below. First, how to establish and update the verification index will be described, and then a process of generating the result proof will be given, and how to perform verification using the result proof to ensure the correctness of the search result will be explained in detail.
1. Establishing authentication indexes
Firstly, the Client calculates an inverted index delta according to the file set D, wherein the inverted index delta refers to an index formed by a keyword and a file containing the keyword. For each keyword w in the inverted indexiIts key-value pair is computed, where the key is a token generated by a cryptographic process (e.g., a pseudorandom function) for each key and the value is a delta hash sum of all files containing the key. The validation index is formed by inserting these key-value pairs into the MPT.
Inserting key-value pairs into the MPT tree includes inserting key-value pairs into a branch node or a leaf node.
Typing a key-value pair into a branch node involves two possible scenarios: in the first case, the key is empty, and the value is stored directly at the 17 th position of the branch node. As shown in fig. 2a, a schematic diagram of inserting [ key, value ] into a branch node is shown. In the second case, the key value is not null, a new leaf node is generated, the unmatched key and value are stored in the leaf node and point to the leaf node through the original branch node. As shown in fig. 2b, to insert [ key, value ], [ 345 ", dog ] into the branch node, a schematic diagram is shown.
Inserting a key-value pair into a leaf node also includes two cases: in the first case, the inserted key is completely matched with the key of the leaf node, and at this time, the value of the original leaf node is only required to be modified into a new value. As shown in fig. 2c, a schematic diagram of inserting [ key, value ] into a leaf node is shown in [ 123 ", dog ]. In the second case, if the inserted key is not matched with the key of the leaf node, an extended node needs to be generated by using the matched public prefix, and then the multi-branch characteristic of the branch node is used to point to a plurality of leaf nodes to store a new key-value pair [ 1200, dog ] and a key-value pair [ 123, cat ] in the original leaf node. As shown in fig. 2d, a schematic diagram of inserting [ key, value ] into a leaf node is shown as [ 1200 ], dog ].
The code for establishing the verification index is implemented as follows:
Figure GDA0002474001730000081
the updating operation of the verification index supports three modes, namely inserting, deleting and editing files, wherein the editing of a file is equivalent to deleting a file and then adding a file. For the operation of inserting new file, firstly, the file f is analyzed to obtain the keyword set W contained in the filefFor each keyword wi∈WfGenerating its token by a pseudo-random function
Figure GDA0002474001730000082
And pseudo-random results of the file
Figure GDA0002474001730000083
While uploading to the cloud. The Server receives the token and updates the token
Figure GDA0002474001730000084
Find the corresponding leaf node and will
Figure GDA0002474001730000085
(the value obtained by performing the incremental hash operation on the file f containing the key word K) is added to the value of the original leaf node. The delete operation is the same process, except that the original leaf node value is subtracted
Figure GDA0002474001730000086
It should be noted that the designation of "key" is a designation corresponding to a node placed in the MPT tree; the designation of the token (or trapdoor trapwood) corresponds to during transmission. An encrypted key is a token, and after the encrypted key is stored in the MPT, each path from the root node to the leaf node forms a token. That is, the path of the MPT from the root to the leaf is the token, the encrypted key.
Specifically, as shown in fig. 3, taking a file set D including files f1 to f4 as an example, after the inverted index is calculated, keywords w1, w2, w3 and w4 are included. The first column and the second column in fig. 3 are the inverted indexes composed of the keywords and the files containing the keywords. The third column is a key, i.e., a token (token) corresponding to each keyword. The fourth column is the value, i.e., the delta hash sum of the file containing the key. The key-value pairs shown in fig. 3 are inserted into the MPT tree structure, and the resulting MPT tree structure is shown in fig. 4.
The client generally uploads an initial structure of the MPT tree structure to the server, and after the server stores the MPT tree structure of the initial structure, when there is an update, the server receives an updated key value pair, and updates the initial MPT tree structure according to the updated key value pair to obtain a latest MPT tree structure. For example, when a file f is newly added to the file set DAnd 5, obtaining the keyword sets contained in the file as w2 and w 5. For each key, generating its token by a pseudo-random function
Figure GDA0002474001730000091
And calculates a delta hash value for file f5
Figure GDA0002474001730000092
For each key, the key-value pair (token and delta hash value for file f 5)
Figure GDA0002474001730000093
) While uploading to the cloud. After the Server receives the key word, it will send the key word w to the existing one2Pass token
Figure GDA0002474001730000094
Find the corresponding leaf node and will
Figure GDA0002474001730000095
And added to the value of the original leaf node. For non-existent keyword w5Then a new leaf node is created and will
Figure GDA0002474001730000096
As its node value. Using light colours in figures 3 and 4
Figure GDA0002474001730000097
This update process is illustrated. Note that after the MPT is updated, the server needs to send an update path back to the client, so that the user can verify and update the root hash value.
During searching, the client sends a challenge token to the server. And the server searches according to the challenge token sent by the client to obtain a search result. In addition, the server searches a search path corresponding to the token in the MPT tree structure according to the challenge token sent by the client, and extracts the key value pair on the search path as reference information.
2. Generating a proof of result (i.e. reference information for verification)
The Server is according to the challenge token submitted by the user
Figure GDA0002474001730000098
And generating a proof of result by validating the index lambda. First, the Server finds a search path based on the challenge token. If it is not
Figure GDA0002474001730000099
If the corresponding leaf node exists, namely the keyword inquired by the user exists, the server returns the 'key' on the search path as the result proof from the node on the upper layer of the leaf node. For the branch nodes, the server also returns key-value pairs that are not on the search path, thereby facilitating subsequent reconstruction of the root hash of the MPT tree structure. If it is not
Figure GDA00024740017300000910
If the corresponding terminal node does not exist, that is, the keyword queried by the user does not exist, the server needs to return a "key" in the search path from the terminal node to the top as the result proof, and for the terminal node to be searched, the server returns a complete key value pair.
The following is the code that achieves the above proof of the generated result:
Figure GDA0002474001730000101
and after receiving the result proof value, the client can execute verification operation.
3. Performing result verification
When the Client receives the search results and the corresponding result proof, the Client can start to verify the freshness and integrity of the data.
First, the Client passes the token of the keyword uploaded at the time of the search
Figure GDA0002474001730000102
Matching with the key in the proof of result.
If the key in the proof of outcome is the prefix of the challenge token, then the remaining _ key is set to store the remaining keys in the challenge token. The path from the root node to the leaf node is actually a complete key, but the path from the root node to the node on the upper layer of the leaf node returned in the result proof is incomplete, so that the defined domain _ key is used to refer to the key remaining after the matching between the token and the result proof is completed. For example, when matching the token a5432 in fig. 3, the result returned by the server proves that the path includes BN2, EN1, BN1, and the path only includes a54, and the remaining _ key is 32 after matching the token a 5432.
If the key in the proof of outcome is not the prefix of the challenge token, then the remaining _ key is set to
Figure GDA0002474001730000103
Second, the root hash value of the MPT tree structure is reconstructed. And if the search result and the remaining _ key are both empty sets, directly calculating the root hash value through result certification. If the two are not null, firstly generating the hash value of the leaf node through the search result and the remaining _ key to obtain a complete result proof value, and then reconstructing a root hash value through the result proof value. In addition to these two cases, the server is considered to have intentionally returned a null result, or the server has tampered with the contents of the proof of result.
And finally, judging the freshness and the integrity of the data by comparing whether the reconstructed root hash is equal to the root hash stored and reserved by the client side by the user. If the two are equal, the verification is passed, and if the two are not equal, the server rarely returns the search result or the server falsifies the result proof.
The code to achieve the above result verification is as follows:
Figure GDA0002474001730000111
the specific process of generating the result certification and verification steps described above is described below in conjunction with the specific structures of fig. 3 and 4.
One of the situations is:
when the client wants to searchThe keyword is w2Then, according to the corresponding relationship shown in fig. 3, the submitted challenge token corresponding to the keyword is "a 5432". Since the key token already exists in the MPT tree (i.e., the validation index) shown in fig. 4, the server can find the search path corresponding to the token as { BN1, EN1, BN2, LN 3. According to the above procedure of generating the proof of result, the server then returns the keys of the nodes on the path other than the LN3 (starting from the node BN2 higher than the leaf node to the root node BN1) together with the key-value pairs for the branch nodes that are not on the path as the proof of result. The results obtained prove that C is shown in FIG. 5an2,Cn1,Cn0As shown. Wherein the results demonstrate Cn2Corresponding to the extracted content on the branch node BN2, i.e., the key "4", whose value is null (because the content of LN3 is not extracted), the key "c" and its value LN4, and the key "f" and its value LN 5. The results demonstrate Cn1Corresponding to the extracted content on the extended node EN1, i.e., the key "5" and its value, which is Cn2. The results demonstrate Cn0Corresponding to the extracted contents on the branch node BN1, i.e., the key "4" and its value LN1, the key "a" and its value Cn1The key "f" and its value LN 2.
After the result proof value is extracted, the result f can be searched according to the proof2,f5The root hash of the MPT tree structure is reconstructed. First the user matches the token "a 5432" with a key in the proof of results, finding "a 54" as the prefix of the token and "32" for the remaining _ key. The user follows "32" and search result f2,f5Regenerating node LN3, the proof of the result can be refined. Thus, the root hash value is constructed from the bottom up through the contents of the completed result proof. And finally, the user judges whether the data is complete or not by comparing the reconstructed root hash with the root hash reserved by the user side. If the server has only returned the file f2Then the reconstructed root hash will not match the correct root hash.
In another case:
when the token corresponding to the keyword that the user wants to search is "a 5433", as can be seen from fig. 3 and 4, the token is in the MPT tree (i.e., the verification index)) But its search path is the same as "a 5432", except that the token has not matched at LN 3. At this time, the server extracts key-value pairs of nodes on the bottom-up path from the LN3 node to generate a proof of result, as C in fig. 5bn3,Cn2,Cn1,Cn0As shown. With respect to the situation shown in FIG. 5a, the key "32" and the value "H" of the leaf node LN3 are extracted more2As Cn3. Note that, before adding the file f5, the leaf node has a value of H2. If the file f5 is added for an update, then the leaf node has a value of H2+ IH (G)K(f5))。
After the user receives the proof of result, because the token "a 5433" is found not to match the key a5432 in the proof of result, the remaining _ key is set to null. The user will reconstruct the root hash directly from the result proof. Similarly, by comparing with the correct root hash, if the root hash is not the same, the server is indicated to falsify the result proof, and malicious behavior is generated.
In summary, the present embodiment constructs an index by using a Merkle Patricia Tree (MPT), and provides a perfect result verification mechanism based on the index. And during verification, the verification is carried out through the root hash of the MPT tree. Since the first generation of the root hash is performed by the user, the correctness of the root hash can be guaranteed. Subsequent root hash updates are also verified and updated by the user, so that the correctness and freshness of the root hash can be guaranteed. In the result verification process, the final comparison judgment is performed based on the root hash reserved by the user, and any node change causes that the reconstructed root hash cannot be matched with the root hash reserved by the user. Therefore, the reference object in the verification link can be ensured to be accurate and reliable, and the search result taken by the user is ensured to be fresh and complete after verification.
The searching method of the specific embodiment can prevent data integrity attack and data freshness attack. In particular, the method can detect the situation that the server intentionally returns a null result under the condition that the user does not reserve the keyword set. The method is a universal result verification scheme, and the traditional encryption search scheme is used as a black box, so that the result verification function can be provided for various encryption search schemes. In addition, verification search can be realized through one communication turn, and the method has the advantage of low overhead. In conclusion, the method has the characteristics of low cost, simple implementation and independence on the original encryption searching scheme.
The foregoing is a more detailed description of the invention in connection with specific preferred embodiments and it is not intended that the invention be limited to these specific details. For those skilled in the art to which the invention pertains, several alternatives or obvious modifications can be made without departing from the spirit of the invention, and all equivalents in performance or use should be deemed to fall within the scope of the invention.

Claims (6)

1. A verifiable encrypted searching method executed by a client, characterized in that: the method comprises the following steps: u1, the client calculates an inverted index for the file set, and calculates a group of key value pairs for each keyword in the inverted index, wherein the key is a token corresponding to the keyword, and the value is the incremental hash sum of the file containing the keyword; inserting each group of key value pairs into an MPT tree structure to obtain an initialized MPT tree; calculating and storing root hash of the MPT tree structure constructed by each group of key value pairs; u2, the client uploads the initialized MPT tree to the server, and when the file set is updated, the updated key value pair is uploaded to the server; u3, the client sends challenge token to the server, receives the search result returned by the server and the reference information for verification, the reference information is the key and key value pair of the node in the MPT tree structure extracted by the server according to the existence or nonexistence of the leaf node in the MPT tree structure corresponding to the challenge token; u4, the client matches the challenge token and the reference information, and reconstructs the root hash of the MPT tree structure according to the matching result; u5, comparing the reconstructed root hash with the root hash stored by the client, if the root hash is the same as the reconstructed root hash, indicating that the server has no tampering behavior and the search result is accurate; if the results are different, the server is indicated to have tampering behaviors, and the search result is inaccurate.
2. A client-executed verifiable encrypted searching method according to claim 1, characterized in that: in the step U1, a token corresponding to the keyword is obtained by encrypting the keyword; and realizing an encryption processing process through a pseudo-random function, and generating a token corresponding to the keyword.
3. A client-executed verifiable encrypted searching method according to claim 1, characterized in that: in step U2, when a file f is newly added or deleted in a file set, a keyword set W included in the file f is obtained for the file ffFor each one belongs to WfKey word w ofiGenerating its corresponding token
Figure FDA0002621717700000011
Token to be transmitted
Figure FDA0002621717700000012
And uploading the incremental hash sum corresponding to the file f to the server as an updated key value pair.
4. A client-executed verifiable encrypted searching method according to claim 1, characterized in that: in step U3, the reference information is extracted as follows: when a leaf node in the MPT tree structure corresponding to the challenge token exists, the server extracts a key of a node located on a search path as the reference information from a node at the upper layer of the leaf node; for the branch nodes on the search path, extracting key value pairs which are not on the search path as the reference information; when the leaf node in the MPT tree structure corresponding to the challenge token does not exist, the server extracts the key value pair at the terminal node and the key of the node on the search path as the reference information from the terminal node on the search path; for the branch nodes on the search path, key-value pairs which are not on the search path are also extracted together as the reference information.
5. A client-executed verifiable encrypted searching method according to claim 1 or 4, characterized in that: in step U4, if the key in the reference information is the prefix of the challenge token, setting a domain _ key as the remaining key in the challenge token, regenerating a key value pair at a leaf node in the MPT tree structure according to the domain _ key and the search result, perfecting the reference information, and reconstructing a root hash of the MPT tree structure according to the perfected reference information; and if the key in the reference information cannot be matched with the challenge token, setting the domain _ key as an empty set, and reconstructing the root hash of the MPT tree structure directly according to the reference information.
6. A verifiable encryption searching method relates to a client and a server; the method is characterized in that: a1, the client calculates an inverted index for the file set, and calculates a group of key value pairs for each keyword in the inverted index, wherein the key is a token corresponding to the keyword, and the value is the incremental hash sum of the file containing the keyword; inserting each group of key value pairs into an MPT tree structure to obtain an initialized MPT tree; calculating and storing root hash of the MPT tree structure constructed by each group of key value pairs; a2, the client uploads the initialized MPT tree to the server, and when the file set is updated, the updated key value pair is uploaded to the server; a3, the server receives the initialized MPT tree uploaded by the client, receives the updated key value pair, and updates the initial MPT tree structure according to the updated key value pair to obtain the latest MPT tree structure; a3, the client sends a challenge token to the server; the server searches according to the challenge token sent by the client to obtain a search result; the server judges whether leaf nodes in an MPT tree structure corresponding to the challenge token exist or not according to the challenge token sent by the client, and keys and key value pairs of the nodes in the MPT tree structure extracted according to the judgment result are used as reference information for verification; the server sends the search result and the reference information to the client; the client receives a search result returned by the server and reference information for verification; a4, the client matches the challenge token with the key in the reference information, and reconstructs the root hash of the MPT tree structure according to the matching result; a5, comparing the reconstructed root hash with the root hash stored by the client, if the root hash is the same as the reconstructed root hash, indicating that the server has no tampering behavior and the search result is accurate; if the results are different, the server is indicated to have tampering behaviors, and the search result is inaccurate.
CN201711277295.7A 2017-12-06 2017-12-06 Verifiable encryption searching method Active CN108039943B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201711277295.7A CN108039943B (en) 2017-12-06 2017-12-06 Verifiable encryption searching method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201711277295.7A CN108039943B (en) 2017-12-06 2017-12-06 Verifiable encryption searching method

Publications (2)

Publication Number Publication Date
CN108039943A CN108039943A (en) 2018-05-15
CN108039943B true CN108039943B (en) 2020-10-30

Family

ID=62095509

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201711277295.7A Active CN108039943B (en) 2017-12-06 2017-12-06 Verifiable encryption searching method

Country Status (1)

Country Link
CN (1) CN108039943B (en)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110830539B (en) * 2018-08-14 2022-09-06 贵州白山云科技股份有限公司 Network storage system and method
CN112955961B (en) * 2018-08-28 2024-06-11 皇家飞利浦有限公司 Method and system for normalization of gene names in medical text
CN110263579B (en) * 2018-11-16 2021-05-11 腾讯科技（深圳）有限公司 Data processing method, system and related equipment
CN109710620B (en) * 2018-12-29 2021-03-16 杭州复杂美科技有限公司 Data storage method, data reading method, device and storage medium
CN110334526B (en) * 2019-05-30 2023-01-03 西安电子科技大学 Forward security searchable encryption storage system and method supporting verification
CN110347744B (en) * 2019-06-03 2020-07-24 阿里巴巴集团控股有限公司 Data storage method, device and equipment for multilayer block chain type account book
US10949118B2 (en) 2019-06-03 2021-03-16 Advanced New Technologies Co., Ltd. Data storage method, apparatus, and device for multi-layer blockchain-type ledger
CN110597825B (en) * 2019-09-24 2021-07-27 腾讯科技（深圳）有限公司 Data processing method and device based on block chain and node equipment
CN110602148B (en) * 2019-10-10 2021-07-06 深圳前海微众银行股份有限公司 Method and device for generating state tree of block and verifying data on chain
CN111221780B (en) * 2019-12-31 2022-05-17 浙江工业大学 Server file safe storage method based on block chain
CN111523148B (en) * 2020-04-16 2023-10-27 丝链(常州)控股有限公司 Data storage method based on block chain
CN111614470A (en) * 2020-05-27 2020-09-01 贵州大学 Verifiable multi-keyword search method based on improved Merkle-Tree authentication method
CN115641141A (en) * 2022-09-30 2023-01-24 蚂蚁区块链科技(上海)有限公司 State verification method and device in block chain system, node and block chain system

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102938767B (en) * 2012-11-13 2016-08-10 西安电子科技大学 The fuzzy keyword search methodology that efficiently can verify that based on the outer packet system of cloud data
CN103607405B (en) * 2013-11-27 2016-11-23 东北大学 A kind of cipher text searching authentication method of facing cloud storage
CN104038349B (en) * 2014-07-03 2017-05-03 西安电子科技大学 Effective and verifiable public key searching encryption method based on KP-ABE
CN106815350B (en) * 2017-01-19 2020-02-14 安徽大学 Dynamic ciphertext multi-keyword fuzzy search method in cloud environment

Also Published As

Publication number Publication date
CN108039943A (en) 2018-05-15

Similar Documents

Publication Publication Date Title
CN108039943B (en) Verifiable encryption searching method
CN109165224B (en) Indexing method for key words on block chain database
EP3693886B1 (en) Optimizations for verification of interactions system and method
AU2017269736B2 (en) Multiple-link cryptologic blockchain
CN110138561B (en) Efficient ciphertext retrieval method based on CP-ABE automatic correction and cloud computing service system
US10754848B2 (en) Method for registration of data in a blockchain database and a method for verifying data
Maniatis et al. Secure history preservation through timeline entanglement
US8978155B2 (en) Apparatus, methods, and computer program products providing dynamic provable data possession
Zhang et al. Provable multiple replication data possession with full dynamics for secure cloud storage
CN103607405B (en) A kind of cipher text searching authentication method of facing cloud storage
Li et al. Integrity-verifiable conjunctive keyword searchable encryption in cloud storage
CN111209591B (en) Storage structure sorted according to time and quick query method
US20200259663A1 (en) One-Time Data Signature System and Method with Untrusted Server Assistance
CN109088719A (en) Outsourced database multi-key word can verify that cipher text searching method, data processing system
US8510566B1 (en) Authentic time-stamping for archival storage
Goodrich et al. Efficient verification of web-content searching through authenticated web crawlers
CN106611136A (en) Data tampering verification method in cloud storage
Mo et al. Enabling non-repudiable data possession verification in cloud storage systems
Zhang et al. Redactable transactions in consortium blockchain: Controlled by multi-authority CP-ABE
CN110851848B (en) Privacy protection method for symmetric searchable encryption
CN112699123A (en) Method and system for verifying existence and integrity of data in data storage system
Mykletun et al. Providing authentication and integrity in outsourced databases using merkle hash trees
CN117194418A (en) Verifiable multi-mode space-time data index structure and space-time range query verification method
Chen et al. Ensuring dynamic data integrity with public auditability for cloud storage
Junxiang et al. Dynamic provable data possession with batch-update verifiability

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant