Towards efficient verifiable multi-keyword search over encrypted data based on blockchain

Searchable symmetric encryption

Since SSE was proposed, a number of works have been done to improve search efficiency, rich expression and advanced security. The first SSE scheme (Song, Wagner & Perrig, 2000) enables users to search keywords through full-text scanning, search time increases linearly with the size of files, which is impractical and inefficient. To improve efficient, Curtmola et al. (2006) proposed an inverted index SSE, which achieves sub-linear search time, and gives a definition of SSE security, but this scheme does not support dynamic operations. Wang et al. (2010) expanded the scheme of Curtmola et al. (2006) to support dynamic operations, and proved that the scheme was adaptively secure against chosen-keyword attacks (CKA2-secure). For the schemes that support dynamic operation, forward security is critically crucial. The research of  Cash et al. (2013), Cash et al. (2015) and Zhang, Katz & Papamanthou (2016) indicated that in the SSE scheme without forward security, the adversary can recover most of the sensitive information in ciphertext at a small cost, their research shows the importance of forward security.

Multi-keyword search is a crucial means to improve search efficiency. In single-keyword search scheme (Song, Wagner & Perrig, 2000; Curtmola et al., 2006; Wang et al., 2010; Kamara, Papamanthou & Roeder, 2012), the server returns some irrelevant results, while the multi-keyword search (Cash et al., 2013; Lai et al., 2018; Xu et al., 2018; Wang et al., 2018; Liang et al., 2020; Hozhabr, Asghari & Javadi, 2021; Liang et al., 2021) gains higher search accuracy and more accurate results. To further improve search efficiency, Abdelraheem et al. (2016) proposed an SSE scheme on encrypted bitmap indexes to support multi-keyword search, but requires two rounds of interactions with the cloud server. Zuo et al. (2019) proposed a secure SSE scheme based on bitmap index which supports dynamic operations with forward and backward security, but this scheme lacks the verification of the results.

Verifiable searchable symmetric encryption

In SSE, it is necessary to verify the results since the server is untrusted. Chai & Gong (2012) proposed the concept of verifiable searchable symmetric encryption (VSSE) and constructed a VSSE scheme based on word tree. Along this direction, some other VSSE schemes (Kurosawa & Ohtaki, 2012; Zhu, Liu & Wang, 2016; Liu et al., 2017; Miao et al., 2019; Ge et al., 2019) are proposed. These schemes are the verification of single keyword search results, Azraoui et al. (2015) combined polynomial-based accumulators and Merkle trees to achieve conjunctive keyword verification. Wan & Deng (2016) used homomorphic MAC to verify the results of multi-keyword search. Li et al. (2021) utilized bitmap index to gain high efficiency of multi-keyword search, and verified the results by RSA accumulator. Ge et al. (2021) and Liu et al. (2021) proposed their verifiable schemes in the Internet of things. These schemes verify the results of multi-keyword search by public key cryptography primitives, which is computationally expensive and inefficient. What is more, these multi-keyword search verifiable schemes mainly focus on verifying the returned files are valid and whether the files really contains the query keywords, but they didn’t ensure all files containing the query keywords are returned.

Verifiable searchable symmetric encryption based on blockchain

In the existing SSE schemes, the verification of search results is performed by users. However, users may forge verification results for economic benefits, which damages the fairness of verification. To solve this, a flexible and feasible method is to adopt blockchain to verify search results, which uses the non-repudiable property of the blockchain to ensure the reliability and fairness of verification. Hu et al. (2018) built a distributed, verifiable and fair ciphertext retrieval scheme based on blockchain. Li et al. (2019) proposed a verifiable scheme combined blockchain and SSE, which can verify the results automatically and reduce the calculation of users. Guo, Zhang & Jia (2020) used the blockchain to realize the public authentication of search results, and ensures forward security of dynamic update. Although these schemes realize the fair verification of search results, but they are mainly for single keyword search, whereas there is little research on the fair verification of multi-keyword. Comparison results with existing schemes are shown in Table 1.

Bitmap

To improve search efficiency, we use the bitmap (Spiegler & Maayan, 1985) to build inverted index. Bitmap uses a binary string to store a set of information, which can effectively save storage space, and it has been widely used in the field of ciphertext retrieval. In our scheme, each keyword w_i corresponds to a bitmap, which contains ℓ bits, ℓ is the number of files in the system, if the i −th document contains w_i the value of ℓ in position i is 1, otherwise 0. For example, there are four files (f₁, f₂, f₃, f₄) and two keywords (w₁, w₂), in Fig. 1, w₁ is contained in f₁ and f₃, w₂ is contained in f₂ and f₃, the bitmap of w₁ and w₂ are 1010 and 0110. If we want to search files that contains both (w₁ and w₂, we need to do AND operation on the two bitmaps, i.e., 1010∧0110 = 0010, that indicates that f₃ contains both w₁ and w₂.

Blockchain

Blockchain is a distributed database, which is widely used in emerging cryptocurrencies to store transaction information such as bitcoin. The blockchain has the features of decentralization, transparency and unforgeability. There is no central server in the blockchain, all nodes participate in the operation and generate the calculation results, the information stored on the blockchain can be seen by all nodes in the network. All nodes of the blockchain share the same data record, under the action of the consensus mechanism, a single node cannot modify the data stored on the chain. The above characteristics of blockchain make it suitable to be a trusted third party for fair verification.

System model

The system model of our scheme is shown in Fig. 2, there are four entities in the system: data owner, cloud server, data user, blockchain. For the files F in the system, data owner extracts all keywords and generates a keyword set W. Data owner encrypts files to a database T, builds an encrypted index ${\mathrm{T}}_{\mathcal{B}}$ and a checklist B, ${\mathrm{T}}_{\mathcal{B}}$ and T are sent to cloud server, ${\mathrm{T}}_{\mathcal{B}}$ and B are sent to blockchain. When a data user joins the system, it sends an authentication request to the data owner, obtains keys and system parameters. During a query, the data user generates search token TK_i,Q according to the keywords to be queried with the help of keys and system parameters, and then sends it to cloud server and blockchain, respectively. Cloud server provides storage services for index ${\mathrm{T}}_{\mathcal{B}}$ and T. In addition, the cloud server performs ciphertext retrieval according to the search token TK_i,Q, and sends the matched results to blockchain for verification.

To verify the search results of multiple keywords, the blockchain performs two steps: (1) benchmark. On receiving TK_i,Q, the blockchain performs multi-keyword search on the index ${\mathrm{T}}_{\mathcal{B}}$ to get the identifiers ID of files that meets the query, then gets the corresponding hash values ℍ of files from the checklist B according ID, and computes the benchmark Acc using ℍ; (2) verification. After receiving the results returned by cloud server, the blockchain computes the hash values ℍ′ of results and computes the verification value Acc′, then the blockchain compares Acc and Acc′ to generate the proof. The proof and search results are sent to data user, the verification is completed.

Threat model

Like other verifiable SSE schemes (Soleimanian & Khazaei, 2019), we assume that the cloud server is malicious, which may return an incorrect or incomplete search result for selfish reasons, such as saving bandwidth or storage space. In addition, we assume that the data user is also untrusted, since it may forge the verification results for economic benefits. The data owner and blockchain are trusted, they execute the protocols in the system honestly.

Algorithm definitions

Our scheme includes eight polynomial time algorithms, ∏ = {KeyGen, Setup, ClientAuth, TokenGen, Search, Verify, UpdateToken, Update}, and the details are as follows:

• K←KeyGen(1^λ), takes system parameter λ as input, and outputs system keys K.

• $\left(\mathrm{T},{\mathrm{T}}_{\mathcal{B}},\mathrm{B}\right)\leftarrow \mathbf{Setup}\mathrm{(}K,\mathbf{W},\mathbf{F}\mathrm{)}$, takes system keys K, the keyword set W and the set of files F as input, outputs a database of encrypted files T, an encrypted index ${\mathrm{T}}_{\mathcal{B}}$ and a checklist B.

• (K₁, ∑)←ClientAuth(𝔸_i), takes the attribute 𝔸_i of user as input, outputs secret key K₁ and the keyword status ∑ .

• $T{K}_{i,Q}\leftarrow \mathbf{TokenGen}\mathrm{(}{K}_1\mathrm{,}\overline{\mathrm{W}}\mathrm{)}$, takes secret key K₁, a set of keywords to query $\overline{\mathrm{W}}=\left\{w_1,w_2,\dots ,w_t\right\}$, outputs the search token TK_i,Q.

• $\left(R,Acc\right)\leftarrow \mathbf{Search}\left(\mathrm{T},{\mathrm{T}}_{\mathcal{B}},\mathrm{B},T{K}_{i,Q}\right)$, takes search token TK_i,Q, the encrypted database T, encrypted index ${\mathrm{T}}_{\mathcal{B}}$ and the checklist B as input, and outputs the search results R and the benchmark Acc.

• (R, proof)←V erify(R, Acc), takes the search results R, and the benchmark Acc as input, outputs the verification proof proof and results R.

• $\left({\tau }_s,{\tau }_b\right)\leftarrow \mathbf{UpdateToken}\left(\overline{F},W^{\prime },K\right)$, takes the set of files to update $\overline{F}$, the set of keywords W′ and system keys K = {K₁, K₂, K₃} as input, and outputs the update token (τ_s, τ_b).

• $\left({\mathrm{T}}^{\prime },{{\mathrm{T}}_{\mathcal{B}}}^{\prime },{\mathrm{B}}^{\prime }\right)\leftarrow \mathbf{Update}\left(\mathrm{T},{\mathrm{T}}_{\mathcal{B}},\mathrm{B},{\tau }_s,{\tau }_b\right)$, takes encrypted database T, encrypted index ${\mathrm{T}}_{\mathcal{B}}$ and the update token (τ_s, τ_b) as input, outputs the updated database T′, updated index ${{\mathrm{T}}_{\mathcal{B}}}^{\prime }$ and the updated checklist B′.

Security definitions

We prove the security of our scheme with the random oracle model, which can be executed by two probabilistic games $\mathrm{Rea}{\mathrm{l}}_{\mathcal{A}}\left(\lambda \right)$ and $\mathrm{Idea}{\mathrm{l}}_{\mathcal{A},\mathcal{S}}\left(\lambda \right)$, and we have the following definitions:

Definition 1: CKA2-security, for the verifiable multi-keyword search scheme ∏ = {KeyGen, Setup, ClientAuth, TokenGen, Search, Verify, UpdateToken, Update}, let $\mathcal{L}\mathrm{=\; \{}{\mathcal{L}}_{\mathrm{setup}}{\mathcal{L}}_{\mathrm{search}}{\mathcal{L}}_{\mathrm{update}}\mathrm{\}}$ be the leakage function, $\mathcal{A}$ is the adversary and $\mathcal{S}$ is the simulator, there are two probabilistic experiments:

$\mathrm{Rea}{\mathrm{l}}_{\mathcal{A}}\left(\lambda \right)$: The challenger runs KeyGen(1^λ) to generate secret key K = {K₁, K₂, K₃}, the adversary $\mathcal{A}$ outputs F and W. The challenger triggers this experiment to run Setup(K, W, F), outputs the index ${\mathrm{T}}_{\mathcal{B}}$, T and B, which are sent to $\mathcal{A}.\mathcal{A}$ generates a series of adaptive queries Q = {q₁, q₂, …, q_t}, for each q_i ∈ Q, the challenger generates search or update tokens, $\mathcal{A}$ receives those tokens and generates a bit b as the output of this experiment.

$\mathrm{Idea}{\mathrm{l}}_{\mathcal{A},\mathcal{S}}\left(\lambda \right)$: The adversary $\mathcal{A}$ outputs F and W, the simulator $\mathcal{S}$ generates the index ${\mathrm{T}}_{\mathcal{B}}$, T and B through ${\mathcal{L}}_{\mathrm{Setup}}$, $\mathcal{A}$ receives them. $\mathcal{A}$ generates a series of adaptive queries Q = {q₁, q₂, …, q_t} , for each q_i ∈ Q, the simulator $\mathcal{S}$ generates search or update tokens with ${\mathcal{L}}_{\mathrm{Search}}$ and ${\mathcal{L}}_{\mathrm{Update}}$, $\mathcal{A}$ receives those tokens and generates a bit b as the output of this experiment. If for any probabilistic polynomial time (PPT) adversary $\mathcal{A}$, there exist an efficient simulator $\mathcal{S}$, which satisfies that:

$\mathrm{|}Pr\left[\mathrm{Rea}{\mathrm{l}}_{\mathcal{A}}\left(\lambda \right)=1\right]-Pr\left[\mathrm{Idea}{\mathrm{l}}_{\mathcal{A}\mathrm{,}\mathcal{S}}\left(\lambda \right)=1\right]\le negl\left(\lambda \right)$

we say ∏ is $\mathcal{L}-$secure against CKA2, where negl is an negligible function and λ is the security parameter.

Proposed construction

Our scheme contains eight algorithms ∏ = {KeyGen, Setup, ClientAuth, TokenGen, Search, Verify, UpdateToken, Update}, let F:{0, 1}^∗ → {0, 1}^m, H:{0, 1}^∗ → {0, 1}ⁿ, be two Pseudo-Random Functions (PRFs), the constructions of our scheme are as follows.

K←KeyGen(1^λ): This algorithm is executed by the data owner, given a security parameter λ ∈ ℕ, this algorithm generates the secret key K = {K₁, K₂, K₃}, where K₁, K₂, K₃←{0, 1}^λ , K₁, K₂ are used to encrypt the bitmap index for each keyword w_i ∈ W, K₃ is used to encrypt files f_i ∈ F and store the hash value of files.

$\left(\mathrm{T},{\mathrm{T}}_{\mathcal{B}},\mathrm{B}\right)\leftarrow \mathbf{Setup}\mathrm{(}K,W,F\mathrm{)}$: Given a set of files F, a set of keywords W and the secret keys K, this algorithm builds an encrypted index ${\mathrm{T}}_{\mathcal{B}}$, a checklist B and a ciphertext database T, as is shown in Algorithm 1. For each file f_i ∈ F, id_i is the identifier of f_i , the data owner encrypts f_i by calculating c_i←Enc(K₃,f_i), and computes the hash value using hash_i←H(c_i). Then data owner stores c_i and hash_i in T[l_i] and B[l_i], respectively.

 
_______________________ 
Algorithm 1 Setup_____________________________________________________________________________ 
Require: K1,K2,K3,W,F 
Ensure: TB,B,T 
  1:  Data Owner DO: 
  2:  TB ←{}, T ←{}, B ←{} 
 3:  for fi ∈ F do 
 4:       li ← H(idi||K3); ci ← Enc(K3,fi) 
  5:       hashi ← H(ci); B[li] ← hashi; T[li] ← ci 
  6:  end for 
 7:  for wi ∈ W do 
 8:       Generate a bitmap index Bwj  for each wj 
  9:       uwi ← F(K1,H(wi)); sti  $ 
   ←{0,1}λ; twi ← H(uwi||sti) 
10:       vB ←Bwi ⊕ H(uwi||sti);TB[twi] ← vB;∑ 
  [wi] = sti 
11:  end for 
12:  send (TB,B) to blockchain, send (T,TB) to cloud server_________________________    

For each keyword w_i ∈ W, data owner generates a bitmap ${\mathcal{B}}_{w_i}$, if id_j contains keyword w_i, then ${\mathcal{B}}_{w_i}\left[m\right]=1$ , where m = H(id_j||K₃), and the other positions of ${\mathcal{B}}_{w_i}$ are all 0′s. The data owner encrypts ${\mathcal{B}}_{w_i}$ through $v_{\mathcal{B}}\leftarrow {\mathcal{B}}_{w_i}\oplus H\left(t_w\left|\right|s{t}_{i+1}\right)$, and store $v_{\mathcal{B}}$ in ${\mathrm{T}}_{\mathcal{B}}\left[t_w\right]$. At the end of the Setup, $\left({\mathrm{T}}_{\mathcal{B}},\mathrm{B}\right)$ and $\left(\mathrm{(T),}{\mathrm{T}}_{\mathcal{B}}\right)$ are sent and stored on blockchain and cloud server, respectively.

(K₁, ∑)←ClientAuth(𝔸_i): It needs to register to the data owner when a new data user who wants to query files on the cloud server joins the system. The data user submits attribute 𝔸_i to the data owner through this algorithm to obtain the keyword status ∑ and the key K₁.

$T{K}_{i,Q}\leftarrow \mathbf{TokenGen}\mathrm{(}{K}_1\mathrm{,}\overline{\mathrm{W}}\mathrm{)}$: It takes the key K₁ and the set of keywords to query $\overline{\mathrm{W}}=\left\{w_1,w_2,\dots ,w_t\right\}$ as input, output a search token TK_i,Q, as is shown in Algorithm2. For each keyword $w_i\in \overline{\mathrm{W}}$, the data user computes the position l_wi of w_i in index ${\mathrm{T}}_{\mathcal{B}}$ as l_wi←H(u_wi||st_i), where u_wi←F(K₁, H₁(w_i)), st_i←∑[w_i]. Data user sends TK_i,Q to cloud server and blockchain, respectively.

$\left(R,Acc\right)\leftarrow \mathbf{Search}\left(\mathrm{T},{\mathrm{T}}_{\mathcal{B}},\mathrm{B},T{K}_{i,Q}\right)$: This algorithm takes search token TK_i,Q, index ${\mathrm{T}}_{\mathcal{B}}$ and ciphertext database T as input, and outputs search results R. On receiving the search token, the cloud server and blockchain perform the same operations for multi-keyword search. They all parse out the position l_wi of the keyword in the token TK_i,Q, and get the bitmap ${\mathcal{B}}_{w_i}$ through ${\mathcal{B}}_{w_i}\leftarrow v_{\mathcal{B}}\oplus H\left(K_{w_i}\left|\right|l_i\right)$, $v_{\mathcal{B}}\leftarrow {\mathrm{T}}_{\mathcal{B}}\left[l_{w_i}\right]$. To achieve multi-keyword search, they compute $\mathcal{B}={\mathcal{B}}_1\wedge {\mathcal{B}}_2\wedge \dots \wedge {\mathcal{B}}_t$, the cloud server gets files in T according to $\mathcal{B}$ with regard to $\mathcal{B}\mathrm{[}i\mathrm{]\; =\; 1}$, and sends them to the blockchain to verify. Similarly, the blockchain gets hash values {hash₁, hash₂, …, hash_s} of files in B according to $\mathcal{B}$, computes Acc = hash₁⊕hash₂⊕⋯⊕hash_s as the benchmark for verification, and the details are shown in Algorithm 2.

 
_______________________________________________________________________________________________________ 
Algorithm 2 Search____________________________________________________________________________ 
Require: K1, ___W = {w1,w2,...,wt}, T, TB, B 
Ensure: TKi,Q, R, Acc 
 1:  Data user: 
 2:  for wi ∈_W do 
 3:       sti ←∑ 
  [wi]; uwi ← F(K1,H(wi)); lwi ← H(uwi||sti) 
  4:  end for 
 5:  return TKi,Q ← (lw1,lw2,...,lwt) 
  6:  Send TKi,Q to cloud server and blockchain 
  7:  Server, Blockchain: 
 8:  for lwi ∈ TKi,Q do 
 9:       vB ← TB[lwi]; Bwi ← vB⊕ H(lwi) 
10:  end for 
11:  B = B1 ∧B2 ∧ ... ∧Bt 
12:  Server: 
13:  gets ciphertext R = {c1,c2,...,cs} form T 
14:  Blockchain: 
15:  gets checklist L = {hash1,hash2,...,hashs} from B with B 
16:  Acc = hash1 ⊕ hash2 ⊕⋅⋅⋅⊕ hashs_____________________________________________________    

(R, proof)←V erify(R, Acc): This algorithm takes search results R and benchmark Acc as input, outputs search results R and proof, and the verify process is shown in Algorithm 3. To verify the integrity of files, the data owner calculates the hash value of each file through hash_i←H(c_i) in the Setup, and adds hash_i to the checklist B, then B is sent to the blockchain. Through algorithm Search, the blockchain gets the search result of multiple keywords, obtains the hash value of each file in the result from B, and computes the benchmark Acc. To verify the search results, the blockchain calculates $H_{\overline{W}}$ of R and compares it with Acc.

 
__________________________________________________________________________________________________________ 
Algorithm 3 Verify____________________________________________________________________________ 
Require: R,Acc 
Ensure: proof, Result 
  1:  Blockchain: 
 2:  H__W ← ϕ 
 3:  for ci ∈ R do 
 4:       H__W ← H__W ⊕ H(ci) 
  5:  end for 
 6:  if H__W = Acc then 
 7:       proof = true, Result ← R 
 8:  else 
 9:       proof = false, Result ← ϕ 
10:  end if 
11:  sends (proof, Result) to data user______________________________________________________    

In Algorithm 3, for all ciphertexts c_i ∈ R, blockchain computes $H_{\overline{W}}\leftarrow H_{\overline{W}}\oplus H\left(c_i\right)$, where H(c_i) denotes the hash value of c_i. Blockchain compares $H_{\overline{W}}$ and Acc, if they are equal, the proof is true, otherwise false. At last, the search results R and proof are sent to data user. During the verification, Acc is calculated through the hash value stored on the blockchain, due to the unforgeability of blockchain, thus Acc is unforgeable. In addition, the verification is completed by the blockchain, so the proof is also unforgeable, which ensures the fairness of verification.

(τ_s, τ_b)←UpdateToken(F, W′, K): The data owner generates an update token through this algorithm, which takes files $\overline{\mathrm{F}}$, a keyword set W′ and secret key K as input, and outputs update token(τ_s, τ_b). For files ${\mathrm{f}}_k\in \overline{\mathrm{F}}$, the data owner encrypts and calculates the hash value of f_k by c_k←Enc(K₃,f_k) and hash_k←H(c_k), respectively. For keywords W′ = {w₁,w₂,…,w_s} that contained in f_k, the data owner generates a bitmap ${\mathcal{B}}_{w_j}$ for each w_j ∈ W′, and encrypts ${\mathcal{B}}_{w_j}$ with $v_{\mathcal{B}}\leftarrow {\mathcal{B}}_{w_j}\oplus H\left(l_{w_j}\left|\right|st\right)$, where l_wj←H(u_wj||st), u_wj←F(K₁, H(w_j)), st←F(K₂, st₀).

$\left({\mathrm{T}}^{\prime },{{\mathrm{T}}_{\mathcal{B}}}^{\prime },{\mathrm{B}}^{\prime }\right)\leftarrow \mathbf{Update}\left(\mathrm{T},{\mathrm{T}}_{\mathcal{B}},\mathrm{B,}{\tau }_{\mathrm{s}},{\tau }_b\right)$: This algorithm takes encrypted database T, index ${\mathrm{T}}_{\mathcal{B}}$, checklist B, update token (τ_s, τ_b) as input, and outputs updated database T′, updated index ${\mathrm{T}}_{\mathcal{B}}^{\prime }$ and updated checklist B′. The details are shown in Algorithm 4.

 
_______________________________________________________________________________________________________ 
Algorithm 4 Update__________________________________________________________________________ 
Require: __F, K = {K1,K2,K3}, W′, T,TB,B 
Ensure: τs,τb,T′,TB′,B′ 
 1:  Data owner: 
 2:  for fk ∈_F do 
 3:       lk ← H(idk||K3), ck ← Enc(K3,fk), hashk ← H(ck) 
  4:       fk, W′ = {w1,w2,...,ws} 
 5:       for wj ∈ W′ do 
 6:            generates a bitmap index Bwj  for wj 
  7:            if ∑ 
  [wj] = ϕ then, then st0  $ 
    ←{0,1}λ 
  8:            else 
 9:                  st0 ←∑ 
  [wj], st ← F(K2,st0) 
10:                  uwj ← F(K1,H(wj)), lwj ← H(uwj||st) 
11:                  vBj ←Bwj ⊕ H(uwj||st), ∑ 
  [wj] = st 
12:            end if 
13:       end for 
14:       return τs = {(lk,ck),(lwj,vBj)}, τb = {(lk,hashk),(lwj,vBj)} 
15:  end for 
16:  Server: T[lk] ← ck, TB[lwj] ← vBj, T′ ← T, TB′ ← T 
B 
17:  Blockchain: B[lk] ← hashk, TB[lwj] ← vBj, B′ ← B, TB′ ← T 
B________    

Forward security

As described above, dynamic update is the foundation function of an SSE scheme, and forward security is an indispensable component of dynamic update. In Algorithm 4, when updating a file f_i that contains keyword w_j, the data owner retrieves the previous state st₀ from the local state store ∑, and generates a new state st through st←F(K₂, st₀), where F is a pseudo random function and K₂ is kept in local. To search a keyword w_j, the data user retrieves the current state st₀ from ∑, with st₀ data user generates a token to be sent to the cloud server and blockchain. Without the key K₂, the server cannot compute the current state st from a previous state st₀, therefore it cannot get the current token from a previous, considering that the newly added file f_i corresponds to the current token, that means the previous tokens cannot match f_i, then forward security is achieved.

Evaluation of setup

In setup phase, data owner encrypts the files, calculates the initial verification values of ciphertexts, generates the bitmap indexes of keywords, stores them in T, B and ${\mathrm{T}}_{\mathcal{B}}$, respectively.

First, we compare the setup time of our scheme with Li et al. (2021) and Guo, Zhang & Jia (2020), the setup time is related to the number of files in the index and the number of keywords included in each file. Figure 3 shows the setup time with different number of keywords in each file while the number of files is fixed at 3137, Fig. 4 shows the setup time with different number of files when the number of keywords in each file is fixed at 20. Both figures show that the setup time is affected by the number of keywords in each file and the number of files, and the setup time increases linearly concerning the number of keywords and files.

Furthermore, Figs. 3 and 4 illustrate that our scheme is more efficient than Li et al. (2021) and Guo, Zhang & Jia (2020) under the same condition in setup time. Since Guo, Zhang & Jia (2020) utilizes the linked list instead of bitmap to build the index, it requires more time than the other schemes. Our scheme takes less time than Li et al. (2021), the reason is that Li et al. (2021) adopts RSA accumulator based on public key encryption to verify multi-keyword search results, in contrast, our scheme utilizes hash functions to verify search results, which reduces the computational overhead greatly.

Evaluation of search

For the performance of our scheme, we compare the search time of our scheme with Li et al. (2021). Moreover, to better evaluate the performance of the scheme in multi-keyword search, we perform two settings in a query: 5 keywords and 10 keywords, respectively. In figures, the suffix of the icon indicates the number of keywords in a query, i.e., our scheme_5 indicates the search time spent in our scheme during a query which contains five keywords: our scheme_10 indicates the search time spent in our scheme during a query which contains 10 keywords, similarly, Li et al. (2021)_5 and Li et al. (2021)_10 indicates the search time spent in Li et al. (2021) during a query which contains five keywords and 10 keywords, respectively.

Figure 5 shows the search time with different number of keywords in each file when the number of files is fixed at 3,137, and Fig. 6 shows the search time with different number of files when the number of keywords in each file is fixed at 20. Both figures show that the search time is affected by the number of keywords in each file and the number of files, and the search time increases sub-linearly with the number of keywords and files.

From Figs. 5 and 6, we can see that the more keywords included in a query, the more time it takes, this is because the more keywords, the search algorithm spends more time to calculate matched files. Another conclusion can be drawn that our scheme is more efficient than Li et al. (2021) in search, the reason is that the same as the setup algorithm, Li et al. (2021) takes more time to calculate the verification values.

Evaluation of verify

Here, we evaluate the performance of our scheme in verification, we verify the results of searching for 5 keywords and 10 keywords respectively, and compares the verification time with Li et al. (2021), the comparison results are shown in Figs. 7 and 8. Figure 7 shows the verification time with different number of keywords in each file when the number of files is fixed at 3,137, and Fig. 8 shows the verification time with different number of files when the number of keywords in each file is fixed at 20. From those two figures, we can see that the verification time is affected by the number of keywords in each file and the number of files, the verification time increases with the number of keyword and files.

Both figures shows that our scheme gains a higher verification efficiency than Li et al. (2021), the reason is that Li et al. (2021) takes additional time to compute ${\mathcal{B}}_{{\mathrm{f}}_i}=y_i\oplus u_i$, where u_i = F(K_fi||r_i), K_fi = G(K₃, f_i). In addition, the initial verification values in Li et al. (2021) are stored in untrusted server and the verification is performed by the data user, both the server and the user may forge the verification results, while in our scheme, the values are stored in blockchain and the verification is performed by blockchain, cannot be tampered with, hence, our scheme is more fair and secure in verification.

Dynamic update is the important function in SSE, so we evaluate the performance of our scheme in dynamic update by adding a file containing multiple keywords. Figures 9 and 10 show the performance of our scheme, Li et al. (2021) and Guo, Zhang & Jia (2020) in update time, _5 and _10 indicate that the update document contains 5 keywords and 10 keywords, respectively. We observe that the update time increases with the number of files, since the more files, the longer of the bitmap corresponding to a keyword, then the update algorithm performs more operations when calculating $v_{\mathcal{B}}\leftarrow {\mathcal{B}}_{w_j}\oplus H\left(u_{w_j}\left|\right|st\right)$. Moreover, the update time is related to the number of keywords contained in the update file, since the more keywords the file contains, the more indexes to update.