Research on Dynamic Searchable Encryption Method Based on Bloom Filter

Abstract

Data outsourcing has become more and more popular due to its low cost and flexibility. However, there is a problem that the cloud server used to store data is partially trusted. Searchable encryption is an efficient technology that is devoted to helping people conduct accurate searches without leaking information. Nonetheless, most existing schemes cannot support dynamic updates or meet the privacy requirements of all users. There have been some experiments to solve these issues by implementing a dynamically searchable asymmetric encryption scheme. This paper proposes an efficient searchable encryption scheme based on the Authenticator Bloom Filter (ABF). The solution can support dynamic updates and multiple users and meet forward and backward security. This paper uses an ABF to improve the efficiency of searches and updates while playing a significant role in dynamic updates. This paper designs a new token encryption scheme and file set encryption scheme, which not only helps users reduce time in searches and updates but also supports multi-user modes. Experiments show that the proposed scheme takes less time in searching and updating algorithms, especially when the keyword does not exist. The solution also takes into account the problem of history storage when updating, which reduces the unnecessary consumption of memory and avoids multiple storage states for the same file.

1. Introduction

In the age of big data, both individuals and businesses need to store large amounts of data. The identification information, preferences, and habits generated by users when using various applications are stored and analyzed. To protect the privacy of users, cloud servers fade in people’s sight. As cloud servers are semi-trusted, unencrypted information being stored in a server can be insecure in two ways: In the first case, some malicious users will access the server. These malicious users will copy the information from the server, which will cause the user’s information to be compromised. In the second scenario, the cloud server is honest but curious. In Chai and Gong [1], the definition of an honest but curious server in the paper is: (1) storing outsourced data without modifying it; (2) honestly performing all operations such as searching and returning text data separately; and (3) attempting to learn the users’ initial data.

An honest but curious adversary is also defined as a legitimate server that will try to find out all the useful information from the obtained content but will not deviate from the set protocol in the communication channel mentioned by Paverd et al. [2]. As a result, users need to encrypt their important information and store it on cloud servers; otherwise, their information security will be at risk. For example, threat actors broke into Amazon’s web servers and caused a breach of the sensitive information of 3.7 million users. The stolen data were then posted on various hacking forums for sale. In the same time frame, the FlexBooker cloud server was also compromised and the personal data of up to 19 million users were leaked. The investigation found that the company was using AWS S3 storage buckets to store data but had not implemented any security measures. It is therefore essential that data in cloud servers are kept encrypted.

While encrypting the data keeps them from being compromised, it also prevents the cloud server from being able to manipulate the data. The reality is that users do not want to download data and process them again; they want to be able to add, delete, change, and check their encrypted data directly on the cloud server. As a result, the concept of symmetric searchable encryption (SSE) has been introduced and investigated. SSE enables the execution of keyword searches in ciphertext, one of the most basic data operations [3].

Users encrypt their private data and outsource them to a semi-trusted server, after which they send a search token to the server to perform a keyword search without revealing sensitive information  [4,5,6,7,8]. Searchable encryption is divided into symmetric searchable encryption and asymmetric searchable encryption. In earlier research, symmetric searchable encryption was mainly studied in the static case. However, the static case is not applicable to practical work. Dynamic searchable encryption implements dynamic updates on the basis of the former. However, in order to improve the efficiency of the search, each of these options allows some information to be divulged within certain limits. The file injection attack was confirmed by Zhang et al. [9]. This attack is performed by injecting a relatively small number of files to learn a large portion of the keywords searched by the client. To resist this attack, forward security has received attention.

Bost et al. [10] proposed a definition of forward security for searchable encryption and proposed a scheme for a type of DSSE based on forward security. Later, Bost et al. [11] proposed a definition of backward security and gave several schemes. He et al. [12] propose a searchable solution that satisfies backward and forward security. However, this scheme is only applicable to individual users for searching their own data stored in cloud servers and is not applicable to practical applications.

As most practical application environments are not closed, the implementation of symmetric searchable encryption always falls short of the requirements. We therefore introduce asymmetric searchable encryption.

Our main contributions are summarized as follows.

(1)

In this paper, a new multi-user dynamic searchable scheme is proposed on the basis of the predecessors. A new validation Bloom filter structure (ABF) based on the existing Bloom filter is proposed. The new ABF not only includes the original features of the Bloom filter but also adds a counter module, which makes the solution easy to implement in dynamic updates and greatly reduces the error rate.

(2)

In this paper, a new file set encryption scheme is designed, which uses a lightweight algorithm to reduce the overhead of initialization and update. At the same time, the ABF and state op of encrypted files are used to realize dynamic update of data.

(3)

The scheme satisfies forward and backward safety. Forward security is satisfied by updating the search token, and backward security is realized by a new file set encryption scheme. Compared with other schemes, the scheme in this paper not only has a great advantage in time cost but also fully considers the problem of historical storage, avoiding multiple different storage states for the same file.

2. Related Work

Asymmetric encryption utilizes a pair of keys, known as the public key and private key. The public key is made publicly available and is used for encrypting data, while the private key is kept secret and is used for decrypting data. For asymmetric searchable encryption, it was first proposed by again Boneh et al. [13] in their article. But this scheme requires a secure communication channel to pass the trapdoor. However, establishing a secure communication channel is very difficult and expensive. Therefore, Beak et al. devised a scheme that does not require a secure communication channel [14]. Tang and Chen et al. [15] designed a PKI-based asymmetric searchable encryption scheme. It improves on the flaw that an attacker can obtain the relationship between the trapdoor and the ciphertext, as proposed by Baek et al. Park et al. [16] propose two structures for link keyword search with public key encryption. However, this solution involves many connections between the user and the server and has a large storage overhead.

Guo et al. [17] analyze the scheme of Li et al. [18] and demonstrate that its trapdoor indistinguishability is not satisfied. A security scheme that satisfies the requirements of the test-specified server and provides stronger security guarantees for the confidentiality of keywords is also proposed. However, these two schemes do not address the encryption algorithm for files and only enhance the security of keywords, without much advantage in terms of practical application.

A spatial keyword query satisfying forward–backward security was proposed by Wang et al. [19]. The article uses Hilbert curves to simplify geometric range queries to range queries and uses prefix encoding to cover range queries. This solution allows other users to search for data, but this solution is not designed to update steps regarding data that already exist on the cloud server. Although this solution proposes a change to the bitmap when updating, the part of the update algorithm and storage file involved is not further described. Chen et al. [20] proposed a blockchain-based public-key searchable encryption scheme in the paper. The scheme, BSPEFB, not only makes use of smart contracts for searching, which can ensure the correctness and immutability of the returned results, but also satisfies backward and forward security. The solution reduces the number of computationally intensive operations and has a high search efficiency. However, each trapdoor in the scheme corresponds to a separate keyword, which causes a huge inconvenience to the data owner each time the data user requests a search token while giving the data owner an idea of the range of keywords the data user is interested in. If a malicious data owner uses this for analysis, it could easily compromise the data user’s privacy.

3. Preliminaries

3.1. Forward and Backward Privacy

The definition of forward–backward security was first proposed by Stefanov et al. [21] with the first scheme to support dynamic keywords. Then, forward–backward security was first formalized by Bost et al. [10,11]. As for the definition of forward security, Bost et al. argue that an update does not reveal information about the updated keywords. Importantly, the server does not know if the updated file matches the keyword that the user searched for. The definition is as follows:

Definition 1.

The update leak function  $L^{Updt}$  can be written as:

$$L^{Updt}\left(op,in\right)=L^{\prime }\left(op,\left\{in{d}_i,{\mu }_i\right\}\right)$$

(1)

For $\left(op,in\right)$ pairs, op is the update query and in is the input. $\left\{in{d}_i,{\mu }_i\right\}$ is a collection of update files, in which ${\mu }_i$ is the key of the update and $ind$ is the updated document. If the update function can be written as the above expression, then the L adaptive secure SSE scheme is forward private.

Bost et al.’s [10] definition here extends forward privacy as proposed by Stefanov et al. [21]. Also, this definition focuses only on adding documents, not updating them.

In backward security, the server cannot associate the currently searched keyword with the results of a previous search. That is, every time a user adds a document $ind$ corresponding to a keyword to the database, then it is removed later [21]. After this series of operations, when searching this keyword, the search result will not appear in the document ind, so the SSE scheme is backward safe. Bost et al. defined three types of backward security in their paper: backward privacy with insertion pattern, backward privacy with update pattern, and weak backward privacy. In this paper, backward security is judged according to the second one: backward privacy with update mode. It leaks the documents currently matching w, when they were inserted, and when all the updates on w happened (but not their content).

3.2. Bilinear Pairing

Let q be a prime, ${\mathbb{G}}_1$ and ${\mathbb{G}}_2$ be two cycle groups of prime order q, on which the operations are addition and multiplication, respectively. The bilinear mapping $e:{\mathbb{G}}_1\times {\mathbb{G}}_1\to {\mathbb{G}}_2$ from ${\mathbb{G}}_1$ to ${\mathbb{G}}_2$ satisfies the following properties:

• Bilinearity: For all $P,Q,R\in$${\mathbb{G}}_1$ and $a,b\in Z$, there are $e\left(aP,bQ\right)={e\left(P,Q\right)}^{ab}$, or $e\left(P+Q,R\right)=e\left(P,R\right)·e\left(Q,R\right)$ and $e\left(P,Q+R\right)=e\left(P,Q\right)·e\left(P,R\right)$ then the mapping is said to be bilinear.
• Non-degeneracy: If P is the generator of ${\mathbb{G}}_1$, then $e\left(P,P\right)$ is the generator of ${\mathbb{G}}_2$.
• Computability: For all $P,Q\in$${\mathbb{G}}_1$, there is an efficient algorithm for calculating $e\left(P,Q\right)$.

3.3. Bloom Filter

The Bloom filter was proposed by Bloom in 1970 [22]. It is actually a very long binary vector and a series of random mapping functions. The Bloom filter can be used to search whether an element is in a set; its advantage is that the space efficiency and query time are much better than the general algorithm, and the disadvantage is that there is a certain misrecognition rate and deletion difficulty.

For each datum, the data owner hashes it into the Bloom filter through k unbiased hash functions. For the number of unbiased hash functions k, this paper uses the following formula to calculate:

$$k=\left(\frac{m}{n}\right)\ast ln\left(2\right),$$

(2)

where m is the size of the filter’s bit array, and n is the number of elements expected to be inserted.

For the false positive rate of the Bloom filter, the following definition is given:

$$BFR={(1-e^{-\frac{kn}{m}})}^k,$$

(3)

where k is the number of the hush function, n is the number of elements to be stored, and m is the size of the bit array. In this paper the false positive rate of ${10}^{-6}$ is specified based on the size of the experimental data.

4. Proposed Construction

We propose a new chain structure which includes two parts: keyword-security encryption and file-security encryption. Forward–backward security can be satisfied by performing these two parts.

4.1. System Model

In our design, there are three parts: data owner (DO), data user (DU) and cloud server (CS). The cloud server stores and manages the data owner’s ciphertext set and helps legitimate data users search for the corresponding data. The system model is shown in Figure 1. First, the data owner collects the public keys of all legitimate users to be used to compute the relevant data pp for the search token. In the second step, the data owner sends the encrypted EDB, ABF, and B to the cloud server for storage. The above is the initialization preparation. Next, if there is a user (legitimate or not), he/she can request the data about the search token from the data owner (Step 3). After that, the data owner sends pp to the data user (Step 4). In step 5, the data user uses the data pp to calculate the corresponding keyword search token. Here, only legitimate users can calculate the correct search token using their private key; otherwise, they will only obtain the wrong data. In the next step, the data user sends the search token to the cloud server to apply for the search. In the seventh step, the cloud server sends a collection of encrypted files from the search to the data user, and finally, in the eighth step, the data user decrypts the data in the res to obtain the plaintext.

The scheme proposed in this paper consists of eight algorithms:

$Setup\left(\lambda \right)\to para$: Input the security parameter $\lambda$ and generate the hash function, pseudo-random function, bilinear mapping, and other data required in the next step.

$KeyGen(H_0,id,g)\to s{k}_{d{u}_i},p{k}_{d{u}_i}$: Each DU generates her/his own public/private keys using its own id.

$Initial\left(W_{ind},para\right)\to \left(ABF,EDB,B,NE\right)$: data owner initializes the related data. Encrypts (keyword, file set) pairs and sends the encrypted data to cloud server.

$Trapdoor\left(w,para,h,s\right)\to s{t}_w$: DU runs this algorithm, enters its private key (the data are sent from the DO into the algorithm), calculates the search token, and sends it to the cloud server.

$Search\left(s{t}_w,para,EDB,ABF\right)\to res$: The data user sends the keyword search token to the cloud server, and the server runs the algorithm to send the corresponding encrypted file set to the data user.

$Update\left(Doc,para,EDB,ABF\right)$: The algorithm is used to update the data. This algorithm is run by the DO to encrypt the newly stored keywords or files and put them in the corresponding location.

$UpdateST\left(W,para,EDB,ABF\right)\to EDB,ABF$: This algorithm is run by the DO, which updates all keyword search tokens at the end of each update, and then sends all the updated data to the server.

$Dec\left(res,w,H_2\right)\to tal$: The data user decrypts the collection from the server to obtain the required file.

4.2. Keyword-Security Encryption

For the encryption of the search token of the keyword, this paper sets the following definition in order to meet the search conditions of multiple users.

Let $U=\left(i{d}_1,i{d}_2,i{d}_3,i{d}_4,\dots ,i{d}_n\right)$ be the id set of legitimate search users and the number of users be n. Then, set $\overrightarrow{X}=\left(x_1,x_2,x_3,\dots ,x_l\right)=({\left(H_0\left(id\right)\right)}^0,{\left(H_0\left(id\right)\right)}^1,{\left(H_0\left(id\right)\right)}^2,\dots ,$${\left(H_0\left(id\right)\right)}^l,)$ to the hashed set of a user’s id, where $x_0=1$. Set $\overrightarrow{Z}=\left(z_1,z_2,z_3,\dots ,z_l\right)$, where $z_j$ in $\overrightarrow{Z}$ is the coefficient of $z^j$ of the expansion of ${\prod }_{j=1}^n\left(z-H_0\left(i{d}_j\right)\right)$, and $i{d}_j$ is the id of the j-th user. In this article, the data owner sends the following data to the data user:

$$pp=\left(p_0,p_1,p_2,para\right),$$

(4)

where $p_0=g^r$, andr is the random number; $p_1=g^{r{\prod }_{i=1}^l\left(z_i\right)}$, and $z_i$ is the data of $\overrightarrow{Z}$; $p_2=g^{z_0}$.

Assuming that a data user with id wants to search for the keyword w, all the data need to be organized into the following form:

$$\begin{array}{c}{t}_w=e\left(g^{{\prod }_{i=1}^l\left(x_i\right)},p_1\right)e\left(g^w{p}_2,p_0\right)\\ =e\left(g^{{\prod }_{i=1}^l\left(x_i\right)},g^{r{\prod }_{i=1}^l\left(z_i\right)}\right)e\left(g^w{g}^{z_0},g^r\right)\\ =e{\left(g,g\right)}^{-x_0{z}_{0}r}e{\left(g,g\right)}^{wr+z_{0}r}.\end{array}$$

(5)

As $H_0\left(id\right)$ is the root of ${\prod }_{j=1}^n\left(z-H_0\left(i{d}_j\right)\right)$, and $〈\overrightarrow{X},\overrightarrow{Z}〉={\prod }_{i=0}^l{x}_i{z}_i=0$, so that ${\prod }_{i=1}^l{x}_i{z}_i=-x_0{z}_0$. However, $x_0=1$, we can obtain $x_0{z}_{0}r=z_{0}r$.

4.3. Keyword Storage Scheme

For keyword storage, this paper designs an Authenticator Bloom Filter (ABF). As shown in Figure 2, the Bloom filter has been modified to add a counting module, and the authenticator is designed to support dynamic updates.

In the ABF structure, for each keyword, the Data Wwner hashes it into the Bloom filter through k unbiased hash functions. For the problem that there may be multiple keywords corresponding to one location, this article adds the counter A[]. Each time A keyword is computed and mapped to the Bloom filter, the count is increased by one for each position A[i]. This means that there is a keyword mapped in the i-th position.

Figure 3 and Figure 4 show the process of adding and deleting data for the ABF. Add data as shown in Figure 3. Hash keyword A and map it to bits 1, 3, 5, and 8 in the Bloom filter. Since bits 1, 5, and 8 are already mapped with keywords, only one is added to the counter. On the third bit, not only a one is added to the counter, but also a one is placed on the corresponding bit of the filter. The deletion process is shown in Figure 4. After keyword B is hashed, it is mapped to the first, fifth, sixth, and eighth bits. First, the corresponding counters are reduced by one, and it is found that the eighth counter is reduced to 0. This means that there are no more keywords mapped to this location, so place 0 in the Bloom filter.

4.4. File-Security Encryption

The ind in this paper’s scheme refers to the address of the file, and the user can find the encrypted file by decrypting to obtain the ind plaintext. This paper uses a symmetric encryption scheme to encrypt the contents of the file, which is not specifically described because it is not very relevant to the scheme of this paper.

The encryption for the document set is as follows:

$$I{E}_{s{t}_w}^j=H_2\left(w\left|\right|j\right)\oplus \left(ind\left[j\right]\left|\right|op\right),$$

(6)

where $op$ is the state of the file (add/del).

The form of the encrypted file collection is put into the server, but the form of the first key-value pair of each keyword is different from the other; the first set of key-value pairs is as follows:

$$ad{d}_{s{t}_w}^1=H_3\left(s{t}_w\right),$$

(7)

$$va{l}_{s{t}_w}^1=\left(I{E}_{s{t}_w}^1\left|\right|r{n}_1\right)\oplus H_3\left(s{t}_w\right).$$

(8)

Here the first set of key-value pairs requires a search token and a randomly generated number that is used to search for the next key-value pair, and the rest of the key-value pairs are as follows:

$$ad{d}_{s{t}_w}^i=H_3\left(r{n}_{i-1}\right),$$

(9)

$$va{l}_{s{t}_w}^i=\left(I{E}_{s{t}_w}^1\left|\right|r{n}_i\right)\oplus H_3\left(r{n}_{i-1}\right).$$

(10)

Each key-value pair here is calculated from the previous set of key-value pairs, as shown in Figure 5.

For document deletion operations, this article does not physically delete an existing document but sets the op state corresponding to the document to delete. When the server runs the search algorithm, it obtains an encrypted file, thus supporting backward security.

5. Construction

In this section, we introduce our method. This method can be used in many different situations. We will describe and analyze the following Algorithms 1–8.

Algorithm 1 Setup

Input: $\lambda$

Output: $para$

1: Generates the paramenters about the pairing operation $({\mathbb{G}}_1,{\mathbb{G}}_2,e,g,q)$   2: Generate the sets$\overrightarrow{Z}$   3: Select the Hash functions $\left(H_{i\in \left\{0,2\right\}},h_{i\in \left\{1,4\right\}}\right)$   4: $para=\left({\mathbb{G}}_1,{\mathbb{G}}_2,e,g,q,H_{i\in \left\{0,2\right\}},h_{i\in \left\{1,4\right\}}\right)$

Algorithm 2 KeyGen

Input: $H_0,id,g$

Output: $s{k}_{d{u}_i},p{k}_{d{u}_i}$

1: Generate the sets $\overrightarrow{X}$ of user i   2: $s{k}_{du}=g^{{\prod }_{i=1}^l{x}_i}$   3: $p{k}_{du}=H_0\left(id\right)$

Algorithm 3 Initial

Input: $W_{ind},para$

Output: $ABF,EDB,B,NE$

1: while$W_{ind}\ne null$do   2:     $w_{ind}\stackrel{R}{\leftarrow }{W}_{ind}$   3:     $W_{ind}\leftarrow W_{ind}\setminus \left\{w_{ind}\right\}$   4:     $Parse{w}_{ind}as\left(w,s{t}_w,ind\left[j\right]\right)$   5:     $ABF\leftarrow H^{\prime }=\left(h_1\left(s{t}_w\right),h_2\left(s{t}_w\right),h_3\left(s{t}_w\right),h_4\left(s{t}_w\right)\right)$   6:     $c_{s{t}_w}=1$,$B\left[s{t}_w\right]=c_{s{t}_w}$   7:     $I{E}_{s{t}_w}^1=H_2\left(w\left|\right|1\right)\oplus \left(ind\left[1\right]\left|\right|op\right)$   8:     $ad{d}_{s{t}_w}^1=H_3\left(s{t}_w\right)$   9:     $r{n}_1\leftarrow {\left\{0,1\right\}}^{\lambda }$ 10:     $va{l}_{s{t}_w}^1=\left(I{E}_{s{t}_w}^1\left|\right|r{n}_1\right)\oplus H_3\left(s{t}_w\right)$ 11:     $EDB\left[ad{d}_{s{t}_w}^1\right]=va{l}_{s{t}_w}^1$,$NE\left[s{t}_w\right]=r{n}_1$ 12:     for$i=2$to$j$do 13:           $I{E}_{s{t}_w}^i=H_2\left(w\left|\right|i\right)\oplus \left(ind\left[i\right]\left|\right|op\right)$ 14:           $r{n}_i\leftarrow {\left\{0,1\right\}}^{\lambda }$,$rn\leftarrow NE\left[s{t}_w\right]$ 15:           $ad{d}_{s{t}_w}^i=H_3\left(rn\right)$ 16:           $va{l}_{s{t}_w}^i=\left(I{E}_{s{t}_w}^i\left|\right|r{n}_i\right)\oplus H_3\left(s{t}_w\right)$ 17:           $EDB\left[ad{d}_{s{t}_w}^i\right]=va{l}_{s{t}_w}^i$ 18:           $NE\left[s{t}_w\right]=r{n}_i$,$c_{s{t}_w}\leftarrow B\left[s{t}_w\right]$ 19:           $B\left[s{t}_w\right]=c_{s{t}_w}+1$ 20:     end for 21: end while 22: send $ABF$,$EDB$,B and $NE$ to the cloud server

Algorithm 4 Trapdoor

Input: $w,pp$

Output: $s{t}_w$

1: $s{t}_w=H_0\left(e\left(g^{{\prod }_{i=1}^l\left(x_i\right)},p_1\right)e\left(g^w{p}_2,p_0\right)\right)$   2: $Sends{t}_{w}toCloudServer$

Algorithm 5 Search

Input: $s{t}_w,para,EDB,B$

Output: $res$

1: $res\leftarrow \varnothing$   2: $H^{\prime }=\left(h_1\left(s{t}_w\right),h_2\left(s{t}_w\right),h_3\left(s{t}_w\right),h_4\left(s{t}_w\right)\right)$   3: if$H^{\prime }ca{n}^{\prime }tbemappedtoABF,break;$   4: else   5:     $c_{s{t}_w}\leftarrow B\left[s{t}_w\right]$   6:     $va{l}_{s{t}_w}^1\leftarrow EDB\left[H_3\left(s{t}_w\right)\right]$   7:     $\left(I{E}_{s{t}_w}^1\left|\right|r{n}_1\right)=va{l}_{s{t}_w}^1\oplus H_3\left(s{t}_w\right)$   8:     $res=res\cup I{E}_{s{t}_w}^1$,$temp=r{n}_1$   9:     for$y=2$to$c_{s{t}_w}$do 10:        $va{l}_{s{t}_w}^y\leftarrow EDB\left[H_3\left(temp\right)\right]$ 11:        $\left(I{E}_{s{t}_w}^y\left|\right|r{n}_y\right)=va{l}_{s{t}_w}^y\oplus H_3\left(temp\right)$ 12:         $res=res\cup \left\{I{E}_{s{t}_w}^y\right\}$,$temp=r{n}_y$ 13:     end for 14: send res to DataUser

Algorithm 6 Update

Input: $Doc,para,EDB,B$

Output:

1: while$Doc\ne null$do   2:     $doc\stackrel{R}{\leftarrow }Doc$,$Doc\leftarrow Doc\setminus \left\{doc\right\}$,$flag=0$   3:     $Prasedocas\left(w,ind,s{t}_w,o{p}^{\prime }\right)$   4:     While$flag==0$ do   5:        if $s{t}_w$ not exit   6:            update ABF   7:            $c_{s{t}_w}=1$,$B\left[s{t}_w\right]=c_{s{t}_w}$   8:            $ad{d}_{s{t}_w}^1=H_3\left(s{t}_w\right)$, $r{n}_1\stackrel{R}{\leftarrow }{\left\{0,1\right\}}^{\lambda }$   9:            $I{E}_{s{t}_w}^1=H_2\left(w\left|\right|1\right)\oplus \left(ind\left[1\right]\left|\right|o{p}^{\prime }\right)$ 10:            $va{l}_{s{t}_w}^1=\left(I{E}_{s{t}_w}^1\left|\right|r{n}_1\right)\oplus H_3\left(s{t}_w\right)$ 11:            $flag=1$,$updateEDB,NE$ 12:            $Putsearchtokens{t}_{w}intheABF$ 13:        else 14:            $c\leftarrow B\left[s{t}_w\right]$,$rn\leftarrow NE\left[s{t}_w\right]$ 15:            $va{l}_{s{t}_w}^1\leftarrow EDB\left[H_3\left(s{t}_w\right)\right]$ 16:            $\left(I{E}_{s{t}_w}^1\left|\right|r{n}_1\right)=va{l}_{s{t}_w}^1\oplus H_3\left(s{t}_w\right)$ 17:            $\left(ind\left[1\right]\left|\right|op\right)=I{E}_{s{t}_w}^1\oplus H_2\left(w\left|\right|1\right)$ 18:            $temp=r{n}_1$ 19:            if$ind==ind\left[1\right]$ 20:                  $op=o{p}^{\prime }$,$flag=1$ 21:            else 22:               for$y=2$to$c$do 23:                   $va{l}_{s{t}_w}^y\leftarrow EDB\left[H_3\left(temp\right)\right]$ 24:                   $\left(I{E}_{s{t}_w}^y\left|\right|r{n}_y\right)=va{l}_{s{t}_w}^y\oplus H_3\left(temp\right)$ 25:                   $\left(ind\left[y\right]\left|\right|op\right)=I{E}_{s{t}_w}^y\oplus H_2\left(w\left|\right|y\right)$ 26:                   if$ind==ind\left[y\right]$ 27:                         $op=o{p}^{\prime }$,$flag=1$ 28:               end for 29:            $r{n}_{c+1}\stackrel{R}{\leftarrow }{\left\{0,1\right\}}^{\lambda }$, $NE\left[s{t}_w\right]=r{n}_{c+1}$ 30:            $ad{d}_{s{t}_w}^{c+1}=H_3\left(rn\right)$ 31:            $I{E}_{s{t}_w}^{c+1}=\left(ind[c+1]\left|\right|op\right)\oplus H_2\left(w\left|\right|c+1\right)$ 32:            $va{l}_{s{t}_w}^{c+1}=\left(I{E}_{s{t}_w}^{c+1}\left|\right|r{n}_{c+1}\right)\oplus H_3\left(rn\right)$,$flag=1$ 33:     end while 34: end while

Algorithm 7 UpdateST

Input: $W,para$

Output: $EDB,ABF$

1: $r\stackrel{R}{\leftarrow }{\left\{0,1\right\}}^{\lambda }$   2: for each keyword $w_i\in W$ do   3:       $t_w=e{(g,g)}^{w_{i}r}$   4:       $s{t}_w=H_0\left(t_w\right)$   5:       $ad{d}_{s{t}_w}^1=H_3\left(s{t}_w\right)$   6:       $va{l}_{s{t}_w}^1=\left(I{E}_{s{t}_w}^1\left|\right|r{n}_1\right)\oplus H_3\left(s{t}_w\right)$   7:       $UpdateEDBABF$   8: end for   9: $SendEDBABFtoCloudServer$

Algorithm 8 Dec

Input: $res,w,H_2$

Output: $tal$

1: $tal\leftarrow \varphi$   2: for$j=1$to$\left|res\right|$do   3:       $I{E}_{s{t}_w}^j\leftarrow res$   4:       $\left(ind\left[j\right]\right|\left|op\right)=I{E}_{s{t}_w}^j\oplus H_2\left(w\left|\right|j\right)$   5:       if$op==add$   6:            $tal=tal\cup \left\{ind\left[j\right]\right\}$   7: end for   8: return tal

$Setup\left(\lambda \right)\to para$: The algorithm is run by the DO and the initialization parameters are defined. First, the data owner inputs the security parameter $\lambda$ to the algorithm, then generatea the addition group ${\mathbb{G}}_1$, whose order is a prime q. Let the multiplicative group ${\mathbb{G}}_2$ have the same order. Let $e:{\mathbb{G}}_1\times {\mathbb{G}}_1\to {\mathbb{G}}_2$ be a map. So, we have g as the generator of group ${\mathbb{G}}_1$. Then, the Hash function is selected and we also need to generate vector $\overrightarrow{Z}$ based on the set of public keys of all users.

$KeyGen(H_0,id,g)\to s{k}_{d{u}_i},p{k}_{d{u}_i}$: Each DU generates her/his own public/private keys using its own id.

$Initial\left(W_{ind},para\right)\to \left(ABF,EDB,B,NE\right)$: The data owner runs Algorithm 3 to initialize all the data. The data owner encrypts all the data before sending it to the cloud server. The initialization data for each keyword are placed in $w_{ind}=\left(w,s{t}_w,ind\left[j\right]\right)$, where $ind\left[j\right]$ is a document collection of keywords (line 4–5). The search token corresponding to this keyword is evaluated by four hashes and mapped to the Bloom filter, while the counter A[i] at each corresponding position of the filter is increased by one.

The next step is to encrypt the file set. The first document of each keyword is encrypted differently from the other documents, so it needs to be calculated separately. This scheme requires key-value pairs to store encrypted file sets. Key-value pairs are represented in this paper by $(add/val)$, and the corresponding $val$ value is represented in this paper by $EDB\left[add\right]$. This scheme needs to create an $NE$ to store the random number generated by the latest keyword file for future updates. Finally, $ABF,EDB,B,NE$ are sent to the cloud server.

$Trapdoor\left(w,pp\right)\to s{t}_w$: The DU runs this algorithm, enters its private key and the data sent from the DO into the algorithm, and calculates the search token and sends it to the cloud server.

$Search\left(s{t}_w,para,EDB,ABF\right)\to res$: The CS runs this algorithm, uses the keyword search token to put its corresponding set of encrypted files into the set res, and sends the res to the DU. First, the cloud server needs to map the search token to the vABF to determine whether the token exists (Line 2–3). If the search token exists, the key-value pair of the encrypted file is found through the token. First, the first value $va{l}_{s{t}_w}^1$ is found by searching the token, and then the encrypted file and $rn$ value are calculated by $va{l}_{s{t}_w}^1$. Then, the key pair of the next encrypted file is found by the $rn$ value found in turn, and all the encrypted files $IE$ are put into the set $res$ through calculation. Finally, the cloud server sends the set $res$ to the DU.

$Update\left(Doc,para,EDB,ABF\right)$: This algorithm is run by the DO to encrypt the newly stored keywords or files and put them in the corresponding location.

Updates in this scheme are batch updates (including additions and deletions), and the data owner packages the files that need to be added along with other keywords, update status, and search tokens into a quadruple doc, and puts all the docs into a collection, Doc.

There are four situations that need to be determined during the update:

• When the keyword corresponding to the updated document does not exist (line 8–18). At this point, you need to initialize the keyword and its files and update the ABF;
• When the keyword exists, and the corresponding first document is the target document (line 20–28). When determining that the first document is the target document, change the status op directly to the target op′;
• When the keyword exists, and the target file corresponds to a subsequent known file set (line 30–36). Check whether all the files correspond to the target file at one time, and change the corresponding state of the file op to the target state op′ (add or del state) if found;
• If the target file has not been stored (line 38–43). Add the target file to the end of the file set while updating $EDB$ and file counters B and $NE$.

$UpdateST\left(W,para,EDB,ABF\right)\to EDB,ABF$: This algorithm is run by the DO, which updates all keyword search tokens at the end of each update and then sends all the updated data to the server. This algorithm is run when the data owner is sure that all the data that need to be updated have been updated. When updating the search token, the data owner needs to randomly select a random number r to replace the original r to achieve the purpose of data update. Since the generation of a key-value pair for the first document of the encrypted document set corresponding to each keyword involves a search token, the EDB needs to be updated after each search token is updated. Finally, the new $EDB$ and $ABF$ are sent to the cloud server.

$Dec\left(res,w,H_2\right)\to tal$: The DU runs this algorithm to take the encrypted data from the cloud server and decrypt it one by one. After obtaining the file state $op$, determine whether it is the state $add$, and if it is, put the file into the collection $tal$. Finally, send $tal$ to the DU.

6. Security Analysis

6.1. Forward–Backward Privacy

First, forward security means that an update does not reveal any information about the updated keywords. Since the hash function is one-way, the server cannot decrypt the stored identifier unless the client can generate a previous search token. At the same time, every time the data owner updates, the updated keyword search token is updated, so even if the previous search token is leaked, it will not affect future security. Therefore, the scheme in this paper realizes forward privacy.

Backward security ensures that search queries do not show indexes that were previously added but later removed. In this scenario, the file and its file state $op$ are encrypted. Because the search results are still in ciphertext, even if it is stored in a curious server, an attacker cannot learn useful information about the index without knowing exactly what the keyword is. Thus, we support backward privacy.

6.2. Adaptive Security

In order to improve the efficiency of the solution, most existing solutions will leak some information to the cloud server. Therefore, the confidentiality of searchable encryption schemes means that no more information is leaked than is allowed. To demonstrate confidentiality, we follow a true-ideal simulation paradigm similar to the work [23].

Let $\Pi =\left(Setup,KeyGen,Initial,Trapdoor,Search,Update,UpdateST,Dec\right)$ be this article’s scheme, S be the simulator, and $\mathcal{A}$ be the adversary. We defined the following two games:

$Rea{l}_{\mathcal{A}}^{\Pi }\left(\lambda \right)$: Run the algorithm $Setup\left(\lambda \right)$ and the algorithm $KeyGen\left(para\right)$. Then, the game is published $\left(para,p{k}_{du}\right)$ and $s{k}_{du}$ is saved. After that, The attacker then selects a database DB, executes various queries against it, including update queries, search queries, and decryption queries, and returns the answers to these queries by executing the corresponding algorithms or protocols update, search, and dec, respectively. Finally, $\mathcal{A}$ outputs a bit $b\in \left\{0,1\right\}$.

$Idea{l}_{\mathcal{A}}^{\Pi }\left(\lambda \right)$: In an ideal world, the opponent selects A safety parameter, and the simulator selects the leak functions ${\mathcal{L}}^{Setup}$ and ${\mathcal{L}}^{KeyGen}$ to generate system parameters and return them to the $\mathcal{A}$. The adversary then selects a database, DB, and executes various queries against it, including update queries, search queries, and decryption queries. The experiment returns the answers to these queries by calling the leak function $\mathcal{L}=\left({\mathcal{L}}_{Setup},{\mathcal{L}}_{KeyGen},{\mathcal{L}}_{Initial},{\mathcal{L}}_{Trapdoor},{\mathcal{L}}_{Search},{\mathcal{L}}_{Update},{\mathcal{L}}_{Dec}\right)$. Finally, $\mathcal{A}$ outputs a bit $b\in \left\{0,1\right\}$.

Theorem 1.

Let H be the password hash function. The scheme is $\mathcal{L}$ adaptively safe in the stochastic prediction model, where the set of leakage functions $\mathcal{L}$ is defined as follows:

$$\mathcal{L}=\left({\mathcal{L}}_{Setup},{\mathcal{L}}_{KeyGen},{\mathcal{L}}_{Initial},{\mathcal{L}}_{Trapdoor},{\mathcal{L}}_{Search},{\mathcal{L}}_{Update},{\mathcal{L}}_{Dec}\right),$$

(11)

where ${\mathcal{L}}_{Setup}=\perp ,{\mathcal{L}}_{KeyGen}=\perp ,{\mathcal{L}}_{Initial}=\perp ,{\mathcal{L}}_{Trapdoor}=\perp ,{\mathcal{L}}_{Dec}=\perp$.

Proof. 

Our proof uses a hybrid argument consisting of a series of games. The first game is exactly the same as the game in the real world, while the last game is exactly the same as the game in the ideal world.

G0: This game is the real world SSE security game Real. So, we can obtain:

$$Pr\left[Rea{l}_A^{EDAEFB}\left(\lambda \right)=1\right]=Pr\left[Gam{e}_0=1\right].$$

(12)

G1: In this game, we need to randomly select the user’s public key $I{D}_i$ to replace the original public key $p{k}_{d{u}_i}=H_0\left(i{d}_i\right)$. It is easy to see here that G1 and G0 are indistinguishable.

$$Pr\left[Gam{e}_0=1\right]=Pr\left[Gam{e}_1=1\right].$$

(13)

G2: In this game, we create a table $TOKEN$ to store search tokens. Each search token is replaced by a random number. Whenever a keyword search token is called, we call the number in the table $TOKEN$ instead of the number in the text. In the case of updates, we will randomly select a string in ${\left\{0,1\right\}}^{\lambda }$ to act. Here we have:

$$\left|Pr\left[G_2=1\right]-Pr\left[G_1=1\right]\right|\le Ad{v}_{\mathcal{A}}^{hash}\left(\lambda \right)$$

(14)

G3: In this game, we need to create four tables $H{a}_1,H{a}_2,H{a}_3,H{a}_4$ to answer the random oracle query, which are used to record the $h_{i\in \left\{1,4\right\}}$ that needs to be mapped to the ABF. In the game, whenever these four values need to be calculated, they are directly taken at random from ${\left\{0,1\right\}}^{\lambda }$ and put into the four $H{a}_1,H{a}_2,H{a}_3,H{a}_4$ tables. If the opponent can distinguish between game 2 and game 3, then the hash function can be distinguished from the real random function, which is obviously impossible. Thus, we have:

$$\left|Pr\left[G_3=1\right]-Pr\left[G_2=1\right]\right|\le Ad{v}_{\mathcal{A}}^{hash}\left(\lambda \right).$$

(15)

G4: In this game, two tables, H1 and H2, need to be created to answer $\mathcal{A}$’s query. $H1$ is to record the response to $H_2\left(w\left|\right|j\right)$ and H2 is to record the response to $H_3$(). In our game, we only consider the leak function in the algorithms update, so we can define ${\mathfrak{L}}_{Update}\left(DOC\right)={\Sigma }_{w\in W}\left|EDB\left(w\right)\right|$, which only leaks the number of keyword/document pairs. In game 2, we generate the search token $s{t}_w$ in the update algorithm as a random string instead of the search token generated in the algorithm. In addition, the $H_1\left(s{t}_w,w_i\right)$ and $H_2^{c_{s{t}_w}}\left(s{t}_w\right)$ during token generation is also replaced by the random strings. If the adversary can distinguish between games 2 and 3, we can distinguish between hashed and truly random functions. Then, we have:

$$Pr\left[Gam{e}_4=1\right]-Pr\left[Gam{e}_3=1\right]\le Ad{v}_{\mathcal{A}}^{hash}\left(\lambda \right).$$

(16)

G5: In this game, we maintain a table $UPDATE$ to generate the encrypted document. In the update protocol, game 5 uses random numbers instead of encrypted document $IE$. It can be seen that games 4 and 5 are the same.

$$Pr\left[Gam{e}_4=1\right]=Pr\left[Gam{e}_5=1\right].$$

(17)

G6: Simulator S simulates the adversary’s point of view with a leak function L that includes search patterns and add history. From the opponent’s point of view, G4 and G5 are exactly the same. Thus, they are indistinguishable:

$$Pr\left[Gam{e}_6=1\right]=Pr\left[Gam{e}_5=1\right]=Pr\left[Idea{l}_A^{\Pi }\left(\lambda \right)=1\right].$$

(18)

Conclusion: To sum up the contributions of G0, G1, G2, G3, G4, G5, and G6 we have:

$$Pr\left[Rea{l}_{\mathcal{A}}^{\Pi }\left(\lambda \right)=1\right]=Pr\left[Idea{l}_{\mathcal{A}}^{\Pi }\left(\lambda \right)=1\right]\le Ad{v}_{\mathcal{A}}^{hash}\left(\lambda \right)$$

(19)

□

Since the hash function is a one-way function, this scheme is an $\mathcal{L}$-adaptively-secure searchable encryption scheme.

7. Performance Analysis

This chapter analyzes our scheme through performance and experiments. Comparing multiple thesis schemes with the scheme of this paper, we draw a conclusion.

We use python cryptographic libraries on a machine with 16 GB of RAM, Intel CORE i7-9700 (8-core, 3.6 GHz), running Windows 10 to implement our algorithm. The experiment took Enron email as the data set, mainly tested the algorithm of updating and searching, and compared the time spent in processing all the keywords and file pairs. In the experiment, the security parameter $\lambda$ = 128 was set, and MD5 was used to implement the hash function. The scheme in this paper will also be compared with the schemes in papers of Chen1 [24], Liu [25], and Chen2 [20].

7.1. Functional Comparison

The functional comparison is shown in

Table 1. Functional comparison.

Scheme	FP	BP	Multi-User	Cryptosystem
Chen1 [24]	✓	✓	×	symmetric
Liu [25]	✓	×	×	symmetric
Chen2 [20]	✓	✓	✓	asymmetric
our	✓	✓	✓	asymmetric

. The scheme of Chen1 et al. [24] can satisfy the anterograde safety. However, this scheme uses symmetric encryption and does not satisfy multiple users. Liu et al.’s [25] scheme satisfies forward security but not backward security or multiple users and uses symmetric key encryption. The scheme proposed by Chen2 et al. [20] satisfies both forward and backward security, supports multiple users, and uses asymmetric key encryption. However, the multiple users of this scheme will consume more time but not in the main scheme, which the article author only mentioned in the article. As can be seen from the table, the scheme in this paper is one of the best.

7.2. Time Consuming for Different ABF Hash Function Numbers

In order to improve the search efficiency, this paper uses the ABF to search keywords. In the ABF, the main factor affecting its efficiency is the number of hashes. Since the use of Bloom filters saves on the error rate, there are generally two solutions: increase the number of hashes and increase the storage array. Since the ABF is stored in the cloud, the error rate can be reduced by increasing the array size so only a few hash functions need to be considered for the most efficient update time. As shown in Figure 6 and Figure 7, the experiment compares the time spent adding and deleting the hash numbers of 4, 6, 8, and 10. It can be seen that when the number of hashing times is four, the time required is the least, and the time required increases slowly as the number of keywords increases.

Based on the conclusion drawn above, it can be determined that the number of hash functions used by this paper’s scheme in the ABF is four. Therefore, Formula (3) can be utilized to calculate the size of the bit set in this paper. It can be obtained as m = 47,925,315 bits so that the false positive rate of this paper scheme can be ${10}^{-6}$.

7.3. Time Cost of Search Algorithm

When the user initiates a query operation, a token for the corresponding keyword is generated, and the token is then sent to the server. Figure 8 shows the relationship between the number of keyword document pairs and the search time when the server performs a search. In the experiment, the three schemes Chen1 [24], Liu [25], and Chen2 [20] were compared. In order to obtain a more fair result, the experiment added up the search token generation time of each scheme for comparison, equivalent to calculating the total process of the data user to obtain the encrypted file of the file.

As we can see from Figure 8, the search time in this article is less than in other scenarios, whether the keyword is present or not. If it does not exist, simply return and prompt. As can be seen from the Figure 8, the search time without keywords is between 0.03 ms and 0.05 ms, which can greatly improve the search rate and reduce the waiting time for users to receive feedback. Compared with other experiments, it is necessary to conduct a chain search for all keywords and then give feedback.

For the search of non-existent keywords, since the other three experiments are all using the same chain storage mode, they are combined into one for comparison (shown in Figure 9). It can be seen that once the keywords exceed 100,000, the chain search method will gradually increase the time. However, the time consumed in the search method in this paper is basically stable, and the time consumed is not increased due to the growth of the total number of searches. The data will only fluctuate in a small range, and the feedback time of users will be greatly shortened.

7.4. Time Cost of Update Algorithm

In the update algorithm, this paper is compared with the schemes of Chen1 [24], Liu [25], and Chen2 [20]. Since these schemes are added and deleted with this algorithm, they are all shown in the following figure.

As can be seen from Figure 10, the solution update of Chen2 et al. [20] took more time. In this scheme, for each keyword that needs to be updated, the file corresponding to it needs to be re-encrypted once. That is, the data owner does not care about the previous encrypted file set; she/he re-encrypts the new file set, and then sends it directly into the database. The reason for the time consumed is that some calculations used in the encryption process, such as pseudo-random function F, bilinear pair e, etc., will be more time-consuming than hashing operations. In addition, the update scheme of Chen2 et al.’s [20] scheme does not take into account whether the newly added file has been added before, which will lead to repeated searches, or whether the new file is deleted and the old version is added, resulting in the deleted file being obtained by the data user.

In Liu et al.’s [25] scheme, the previous addition of files was also not taken into account in the update. Although the time is shorter, with the increase in the number of files, the time is the fastest growing, even exceeding the original time-consuming Chen2 scheme.

Among the schemes proposed by Chen1 et al. [24], the time is second only to that proposed in this paper. However, the problem is the same as that in the previous two schemes; the existing files and their status are not considered. This not only adds unnecessary storage space but also affects subsequent search results. Finally, the scheme in this paper is superior to the other three schemes both in terms of rationality and time.

8. Conclusions

In this paper, we design a new dynamic searchable scheme which satisfies forward and backward security. A new ABF based on the original Bloom filter is proposed to reduce the misjudgment rate. At the same time, new key encryption and file encryption schemes are designed. The solution supports forward and backward security, multiple users, and dynamic updates. Compared with other existing schemes on the premise of forward and backward security, especially when the keyword does not exist, the scheme in this paper greatly reduces the time and improves the efficiency. And the keyword search time in this paper has been maintained between 0.03 ms and 0.05 ms. The scheme of this paper takes into account the history of file storage, avoids the situation of multiple storage states of a file when searching, and greatly meets the needs of users.