CN108471405A - A kind of positive secrecy dynamic based on cloud disk can search for encrypted Protocol Design Method - Google Patents

Abstract

The present invention provides a protocol design method for forward secrecy dynamic searchable encryption based on cloud disk. The method makes search and update by innovatively designing the protocol for initializing index, protocol for adding files, protocol for searching files and protocol for deleting files, respectively. The time complexity of and , is more efficient and safer, and is parallelizable.

Description

A protocol design method for forward secrecy dynamic searchable encryption based on cloud disk

technical field

The present invention relates to the field of information security, and more specifically, relates to a cloud disk-based forward secrecy dynamic searchable encryption protocol design method.

Background technique

Searchable Encryption (Searchable Encryption) is a cryptographic primitive developed in recent years that supports users to search for keywords on ciphertext. It can save users a lot of network and computing overhead, and make full use of the huge cloud server. The searchable encryption technology mainly solves how to use the server to complete the safe keyword search under the premise that the server is not completely trusted when the data is stored in the cloud. Searchable encryption mainly includes two types: symmetric searchable encryption (SSE) and asymmetric searchable encryption (ASE), both of which have different emphases in terms of functions and performance, and are used for Solve the business needs of different cloud computing scenarios. In a symmetric environment, the generator of data, the generator of search credentials, and the decryptor are all the same user. The searchable symmetric encryption system enables a user to store his data remotely on a semi-trusted cloud server in a private manner, and retains the ability to selectively restore the required files. The basic framework of searchable secrets is: first, the data owner encrypts the data and creates a security index, and then uploads the encrypted data and its security index to the cloud server for storage. When the user needs to search for the document, the key is used to calculate the search voucher for the search keyword and send it to the server, and the cloud server uses the search voucher to search for the required file data for the user. Data owners and users can be designated as different or the same user entities in different network environments. In an asymmetric environment, it is assumed that the generator of data, the generator of search credentials, and the decryptor are different user entities, which is an extension and promotion of searchable encryption in a symmetric environment.

Forward secrecy requires that a key can only access the data protected by it; the elements used to generate the key are changed one at a time, and no other keys can be generated; one key is cracked, and the security of other keys is not affected sex. An important feature of forward secrecy is that the server cannot know whether the newly added file contains any keywords in the previously searched file, which makes it more resistant to adaptive attacks. The first searchable encryption scheme supporting forward secrecy was proposed by Stefanov, whose search and update time complexities are O(dlog ³ N) and O(log ² N), respectively. This paper proposes a more efficient and secure forward secrecy scheme, whose search and update time complexities are O(d) and O(r) respectively, and can be parallelized, so it can be compared with the distributed Combined with cloud storage system.

Contents of the invention

The invention provides a cloud disk-based forward secrecy dynamic searchable encryption protocol design method, the method and the protocol designed by the method make the dynamic searchable encryption more efficient and safer.

In order to achieve the above-mentioned technical effect, the technical scheme of the present invention is as follows:

A protocol design method for forward secrecy dynamic searchable encryption based on cloud disk, comprising the following steps:

S1: Design initialization index protocol;

S2: Design and add file protocol;

S3: Design search file protocol;

S4: Design a delete file protocol.

Further, the process of step S1 is:

S11: Generate K _G using a pseudo-random function that meets the requirements;

S12: Generate the secret key K _SKE of the symmetric encryption algorithm;

S13: store the two secret keys in the client;

S14: Generate 3 local indexes: FileCnt, SearchCnt and WordCnt;

Among them, K _G is mainly used to generate the secret key K _w when adding files and searching files, and generating the deletion key K _f when deleting files, while K _SKE is used to encrypt files using the AES-128-CBC symmetric encryption algorithm .

Further, the process of step S2 is:

S21: count the number of keywords contained in f, and generate a record n _f =WordCnt[f];

S22: The client uses K _G and id(f) to generate f's deletion key K _f =G(K _G ,id(f));

S23: The client judges all w _i in f: if FileCnt[ _wi ] is empty, then FileCnt[ _wi ]=1, if SearchCnt[ _wi ] is empty, then SearchCnt[ _wi ]=0;

S24: Otherwise, FileCnt[w _i ]++ indicates that f is the number one containing the keyword w _i ;

S25: The client uses SearchCnt[w _i ] to calculate the key corresponding to w _i then use Compute the WPairs in and

S26: The client uses K _f to calculate the And the corresponding The value is equal to WPairs value;

S27: The client encrypts the file to obtain the ciphertext c, and sends c, WPairs and FPairs to the server;

S28: The server saves c, and inserts WPairs and FPairs into directories DictW and DictF respectively.

Further, the process of step S3 is:

S31: The user generates a key corresponding to w

S32: the user sends the search credential (K _w , cnt=FileCnt[w]) to the server;

S33: The server performs a search operation on i=1to cnt:

calculate Calculate all id(f) that meet the requirements;

S34: The server passed Locate to the corresponding item in DictF, in order Store in queue q ₁ , and delete corresponding entries in DictW and DictF at each step;

S35: the server returns all f-lists to the user;

S36: the user maintains the SearchCnt index, SearchCnt++;

S37: Generate a new K _w , calculate new WPairs and FPairs and send them to the server;

S38: The server receives and updates the directories DictW and DictF.

Further, the process of step S4 is:

S41: The client generates a deletion key K _f =G(K _G ,id(f));

S42: The client acquires n _f =WordCnt[id(f)], and deletes WordCnt[id(f)];

S43: the client sends (K _f , n _f ) to the server;

S44: the server deletes the file f;

S45: The server calculates respectively for i=1 ton _f delete and remove

Compared with the prior art, the beneficial effects of the technical solution of the present invention are:

The present invention makes innovative designs on the initialization index protocol, adding file protocol, searching file protocol and deleting file protocol, so that the time complexity of searching and updating is respectively O(d) and O(r), which is more efficient. It is also safer and parallelizable.

Description of drawings

Figure 1 initialization protocol design diagram;

Fig. 2 Encrypted file upload protocol design diagram;

Figure 3 is based on the design diagram of the file search protocol on the encrypted index;

Figure 4 file deletion protocol design diagram;

Figure 5 is a schematic diagram of client/server indexing after adding files for the first time;

Figure 6 is a schematic diagram of the client/server index after searching for the keyword w once;

Fig. 7 Schematic diagram of client/server indexing after file f is deleted.

Detailed ways

The accompanying drawings are for illustrative purposes only and cannot be construed as limiting the patent;

In order to better illustrate this embodiment, some parts in the drawings will be omitted, enlarged or reduced, and do not represent the size of the actual product;

For those skilled in the art, it is understandable that some well-known structures and descriptions thereof may be omitted in the drawings.

The technical solutions of the present invention will be further described below in conjunction with the accompanying drawings and embodiments.

As shown in Figure 1-7, this scheme is the same as other index-based symmetric searchable encryption schemes. The server stores an encrypted index, which represents the correspondence between each file and the keywords they contain. The server performs search operations on this encrypted index according to the needs of the client. In this solution, the client needs to store three tables: FileCnt is used to store the number of occurrences of each keyword in all files; SearchCnt is used to store the number of times each keyword has been searched; WordCnt is used to store the number of times each keyword The number of keywords contained in the encrypted file. Correspondingly, the server needs to store two tables: DictW is an encrypted index for searching; DictF is an encrypted index for updating corresponding entries in DictW when deleting. The form of information stored in DictW and DictF is (addr _w , val _w ).

When uploading a file, you first need to give the keywords contained in the file. Then the client will update the contents of the three dictionaries stored locally, and generate each keyword key and the contents inserted into the DictW and DictF dictionaries respectively according to the formula of the protocol. At the same time, the files are encrypted and finally sent to the server together.

When searching for a file, you first need to give the keyword w you want to search for, and then the client will extract the corresponding information from the local FileCnt and SearchCnt, generate w's corresponding search key k _w , and send a search token to a server, and the server Use the content in this token to perform a series of calculations according to the protocol, find all target files in DictW, and return them. Finally, the client and the server also need to update the relevant content in the five indexes to achieve forward secrecy. In addition, due to the need to achieve forward secrecy, at the end of each search, the corresponding index of the keyword w in DictW needs to be updated. Correspondingly, we also need to update the corresponding index in DictF according to DictW.

When deleting a file, we need to delete all the entries about the file in DictW, but since the content in DictW is encrypted, we need to add a DictF dictionary for assistance. The DictF dictionary is equivalent to a pointer. We Use it to locate the content in DictW, so as to realize the update of DictW.

For ease of understanding, first introduce the five indexes of the client and server. The client stores three dictionaries, where FileCnt stores the number of occurrences of each keyword in all files, and SearchCnt stores the number of times each keyword is searched. WordCnt stores the number of keywords contained in each encrypted file. SearchCnt[w] is used to generate and update the search key k _w (mainly to achieve forward secrecy). FileCnt[w] is used to generate DictW=(addr _w , val _w ) together with k _w . These contents will also be used in the search to restore the id of the target file. WordCnt[f] is mainly used to generate DictF=(addr _w , val _w ) together with the file id when the file is deleted. The value of val _w in DictF is the value of addr _w in DictW, so we can regard DictF as a pointer. It is used to find and delete every item about f in the index DictW when deleting a file f. Both FileCnt and SearchCnt are O(m) in size (m is the number of all keywords), and WordCnt is O(n) in size (n is the number of all files).

Two dictionaries are stored on the server side, DictW and DictF respectively, and their size is O(N)=O(nm), that is, each keyword of each file will be used as a record. The data stored in DictW and DictF are all in the form of key-value: one of them and All information is encrypted with the corresponding key. we can put Think of it as an address for locating the corresponding

In DictW, is determined by the secret key After encrypting with FileCnt[w _i ] ( is generated by w _i and SearchCnt[wi _] ). It is the encrypted information about the file identifier of a file containing the keyword w _i . The information in DictW is related to each keyword w and FileCnt[w] (the number of times w appears in the file). If f is the i-th one containing w, then encrypt the file identifier id(f) corresponding to f using K _w and i. Among them, K _w is generated by w and SearchCnt[w] (the number of times w is searched). The storage location of the encrypted value in DictW is also generated by w and FileCnt[w]. Therefore, as long as a keyword w and its search times SearchCnt[w] and the corresponding FileCnt[w] are given, the server can search the encrypted index DictW by locates all entries that contain the keyword, and passes the Decrypt to get id(f), and then return the corresponding encrypted file f.

In DictF, It is obtained by encrypting with the secret key k _f and n _f =WordCnt[f] (from 1 to n _f ) (k _f is generated by id(f)). and The value is equal to DictW in value. Because after deleting a file f, all entries about f in DictW need to be updated. Since all the information in DictW is encrypted, how to find the corresponding index according to f becomes a difficult problem. In order to solve this problem, we use DictF and WordCnt to assist. Through the id of a file, we can find the indexes of all keywords of the file in DictF, and then find the corresponding addr value in DictW through the val value of these indexes, so as to delete it. In addition, since the operation of the updated DictW is involved at the end of each search, the content in the corresponding DcitF also needs to be updated. It is easy to prove that each addr and val in DictF is unique by the generation rules of addr and val in DictF, so it is equivalent to a two-way map. Then when we update DictW, we can use the addr of DictW to locate the corresponding entries in DictF and update their val.

From the above, we can see that DictW and DictF store a piece of information for each keyword in each file, and their forms are the same. The difference is that DictW is built with keywords as the core and is mainly used for searching, while DictF is built with the id of the file as the core and is mainly used to maintain DictW when deleting.

The protocol design of the present invention is introduced below. The four protocols provided by the present invention include: initializing index, adding files, searching files, and deleting files. The four protocols are described in detail below.

The design initialization index protocol is mainly divided into 4 steps:

Step 1: Generate K _G using a pseudo-random function that meets the requirements;

Step 2: Generate the secret key K _SKE of the symmetric encryption algorithm;

Step 3: Store these two keys to the client;

Step 4: Generate 3 local indexes: FileCnt, SearchCnt and WordCnt.

Among them, K _G is mainly used to generate a secret key K _w when adding a file and searching for a file, and generate a deletion key K _f when deleting a file. And K _SKE is used to encrypt files using AES-128-CBC symmetric encryption algorithm.

The design add file protocol is mainly divided into 8 steps:

Step 1: count the number of keywords contained in f, and generate a record n _f =WordCnt[f];

Step 2: The client uses K _G and id(f) to generate f's deletion key K _f =G(K _G ,id(f));

Step 3: The client judges all w _i in f: if FileCnt[ _wi ] is empty, then FileCnt[ _wi ]=1, if SearchCnt[ _wi ] is empty, then SearchCnt[ _wi ]=0;

Step 4: Otherwise, FileCnt[w _i ]++ indicates that f is the number one containing the keyword w _i ;

Step 5: The client uses SearchCnt[w _i ] to calculate the key corresponding to w _i then use Compute the WPairs in and

Step 6: The client uses K _f to calculate in FPairs And the corresponding The value is equal to WPairs value;

Step 7: The client encrypts the file to obtain the ciphertext c. And send c, WPairs and FPairs to the server;

Step 8: The server saves c, and inserts WPairs and FPairs into directories DictW and DictF respectively.

From the above content, we can see that when adding a file, we hide the id(f of the file in the index according to the design of the protocol, and generate an encrypted index. In the subsequent search, we can restore the id(f ), enabling searchable encryption.

Designing encrypted files based on keyword search is mainly divided into 8 steps:

Step 1: The user generates the key _Kwi =G(K _G , _wi ||SearchCnt[ _wi ]) corresponding to w;

Step 2: The user sends the search credential (K _w , cnt=FileCnt[w]) to the server;

Step 3: The server performs a search operation on i=1tocnt:

calculate Calculate all id(f) that meet the requirements;

Step 4: The server passes Locate to the corresponding item in DictF, in order Store in queue q ₁ , and delete corresponding entries in DictW and DictF at each step;

Step 5: The server returns all f-lists to the user;

Step 6: The user maintains the SearchCnt index, SearchCnt++;

Step 7: Generate new K _w , calculate new WPairs and FPairs and send them to the server;

Step 8: The server receives and updates the directories DictW and DictF;

Through the design of the search protocol, the system can restore the file id(f) containing the keyword w through calculation, and update SearchCnt[w] to recalculate, and the update contains the keyword w, thereby achieving forward secrecy. a characteristic.

The design of the delete file protocol is mainly divided into 5 steps:

Step 1: The client generates the deletion key K _f =G(K _G ,id(f));

Step 2: the client obtains n _f =WordCnt[id(f)], and deletes WordCnt[id(f)];

Step 3: The client sends (K _f , n _f ) to the server;

Step 4: The server deletes the file f;

Step 5: The server calculates respectively for i=1 ton _f delete and remove

Since the indexes are all encrypted, we cannot update DictW when deleting files, so we designed a deletion protocol. From the above content, we can see that we have added an index DictF, which can be regarded as a pointer to the corresponding item in DictW , so DictW can be maintained through DictF, which ensures that after deleting a file, its related indexes will also be deleted.

The same or similar reference numerals correspond to the same or similar components;

The positional relationship described in the drawings is only for illustrative purposes and cannot be construed as a limitation to this patent;

Apparently, the above-mentioned embodiments of the present invention are only examples for clearly illustrating the present invention, rather than limiting the implementation of the present invention. For those of ordinary skill in the art, other changes or changes in different forms can be made on the basis of the above description. It is not necessary and impossible to exhaustively list all the implementation manners here. All modifications, equivalent replacements and improvements made within the spirit and principles of the present invention shall be included within the protection scope of the claims of the present invention.

Claims (5)

1. A protocol design method based on cloud disk forward secrecy dynamic searchable encryption, is characterized in that, comprises the following steps: S1: Design initialization index protocol; S2: Design and add file protocol; S3: Design search file protocol; S4: Design a delete file protocol. 2. the protocol design method based on cloud disk forward secrecy dynamic searchable encryption according to claim 1, is characterized in that, the process of described step S1 is: S11: Generate K _G using a pseudo-random function that meets the requirements; S12: Generate the secret key K _SKE of the symmetric encryption algorithm; S13: store the two secret keys in the client; S14: Generate 3 local indexes: FileCnt, SearchCnt and WordCnt; Among them, K _G is mainly used to generate the secret key K _w when adding files and searching files, and generating the deletion key K _f when deleting files, while K _SKE is used to encrypt files using the AES-128-CBC symmetric encryption algorithm . 3. The protocol design method of forward secrecy dynamic searchable encryption based on cloud disk according to claim 2, characterized in that, the process of the step S2 is: S21: count the number of keywords contained in f, and generate a record n _f =WordCnt[f]; S22: The client uses K _G and id(f) to generate f's deletion key K _f =G(K _G ,id(f)); S23: The client judges all w _i in f: if FileCnt[ _wi ] is empty, then FileCnt[ _wi ]=1, if SearchCnt[ _wi ] is empty, then SearchCnt[ _wi ]=0; S24: Otherwise, FileCnt[w _i ]++ indicates that f is the number one containing the keyword w _i ; S25: The client uses SearchCnt[w _i ] to calculate the key corresponding to w _i then use Compute the WPairs in and S26: The client uses K _f to calculate the And the corresponding The value is equal to WPairs value; S27: The client encrypts the file to obtain the ciphertext c, and sends c, WPairs and FPairs to the server; S28: The server saves c, and inserts WPairs and FPairs into directories DictW and DictF respectively. 4. the protocol design method of forward secrecy dynamic searchable encryption based on cloud disk according to claim 3, is characterized in that, the process of described step S3 is: S31: The user generates a key corresponding to w S32: the user sends the search credential (K _w , cnt=FileCnt[w]) to the server; S33: The server performs a search operation on i=1to cnt: calculate Calculate all id(f) that meet the requirements; S34: The server passed Locate to the corresponding item in DictF, in order Store in queue q ₁ , and delete corresponding entries in DictW and DictF at each step; S35: the server returns all f-lists to the user; S36: the user maintains the SearchCnt index, SearchCnt++; S37: Generate a new K _w , calculate new WPairs and FPairs and send them to the server; S38: The server receives and updates the directories DictW and DictF. 5. the protocol design method based on the forward secrecy dynamic searchable encryption of cloud disk according to claim 4, is characterized in that, the process of described step S4 is: S41: The client generates a deletion key K _f =G(K _G ,id(f)); S42: The client acquires n _f =WordCnt[id(f)], and deletes WordCnt[id(f)]; S43: the client sends (K _f , n _f ) to the server; S44: the server deletes the file f; S45: The server calculates respectively for i=1to n _f delete and remove