Efficient phrase search with reliable verification over encrypted cloud-IoT data

System model

Four entities are included in our system: IoT device, data user, cloud server, and blockchain. The system model is shown in Fig. 1. IoT device as the data owner collects data and stores them in the form of files $\mathcal{F}=\{F_1,F_2,\dots F_M\}$. The IoT device extracts all the keywords $\mathcal{W}=\{w_1,w_2,\dots w_N\}$ in $\mathcal{F}$ and adopts the bitmap to build composite index $\mathcal{I}$. The IoT device encrypts all the files in $\mathcal{F}$ to ciphertexts $\mathcal{C}=\{C_1,C_2,\dots C_M\}$ by symmetric encryption, and calculates the hash value $has{h}_i$ of each ciphertext in $\mathcal{C}$ through $sha256$, which will be added to the checklist L. At last, ( $\mathcal{I}$, $\mathcal{C}$) and ( $\mathcal{I}$, L) are sent to the cloud server and the blockchain, respectively.

The data user obtains the system public parameters $\mathrm{\Omega }$ through the authorization of the IoT device, generates a search trapdoor through these public parameters and the phrases to be queried $\tilde{w}$. The trapdoor will be sent to the server and blockchain for encrypted search and result verification, respectively. The data user receives the search results R and verification result $proof$ from the blockchain, and accepts R if $proof=1$, otherwise rejects R.

The cloud server stores the index $\mathcal{I}$ and ciphertexts $\mathcal{C}$ sent by the IoT device, and performs a search over encrypted data using the trapdoor sent by the data user to generate the search result R and aggregate evidence $\psi$. At last, the cloud server sends $\psi$ to the blockchain for verification, and sends R to the user.

The blockchain verifies aggregate evidence $\psi$ returned by the server and generates $proof$. To achieve reliable verification, the blockchain performs a phrase search in parallel with the cloud server to generate the verification standard value ${\psi }^{\mathrm{\prime }}$. The blockchain compares ${\psi }^{\mathrm{\prime }}$ with the aggregated evidence $\psi$ returned by server, calculates the verification evidence $proof$, and sends it to the user. In particular, during the verification, multi-set hash functions are used to verify the aggregate hash results of the ciphertext, while the ciphertext is off-chain, thereby reducing blockchain storage and computing overhead.

Threat model

In our system, IoT devices and blockchains are completely trusted, IoT devices can collect data honestly, and generate secure indexes and checklists. The blockchain performs fair verification of search results, and the verification result is reliable and unforgeable.

Correspondingly, cloud servers and users are considered untrustworthy. The cloud server may only store part of the index and ciphertext for saving storage resources. At the same time, it may perform searches dishonestly in order to save computation costs. In addition, there may be other software/hardware malfunctions in the system. All the above reasons will make the file and the verification evidence returned by the server incomplete or incorrect. As for data users, it may falsify verification results for financial gain and is therefore not trustworthy.

Algorithm definitions

Our scheme consists of six polynomial algorithms $\prod =\{KeyGen,IndexBuild,TokenGen,Search,Verify,Dec\}$:

1) $K\leftarrow KeyGen(1^{\lambda })$, this algorithm inputs a secure parameter $\lambda$, and outputs the key set $K=(K_1,K_2,K_3,K_4,K_I,K_Z,K_X,pk,sk)$.

2) $(\mathcal{I},T,B)\leftarrow IndexBuild(\mathcal{F},\mathcal{W},K)$, this algorithm takes the set of files $\mathcal{F}$, the set of keywords $\mathcal{W}$, the key set K as input, and outputs the secure index $\mathcal{I}$, the encrypted database T, the checklist B.

3) $T{K}_{i,Q}\leftarrow TokenGen(\tilde{w},K_3,pk)$, this algorithm takes a query phrase $\tilde{w}$, a secret key $K_3$ and a public key $pk$ as input, and outputs the search trapdoor $T{K}_{i,Q}$.

4) $(\psi ,R)\leftarrow Search(\mathcal{I},T,T{K}_{i,Q})$, this algorithm takes the secure index $\mathcal{I}$, the encrypted database T and the search trapdoor $T{K}_{i,Q}$ as input, and outputs the aggregate evidence $\psi$ and search results R.

5) $proof\leftarrow Verify(\mathcal{I},\psi ,B,T{K}_{i,Q})$, this algorithm takes the secure index $\mathcal{I}$, aggregate evidence $\psi$, the checklist B, the search trapdoor $T{K}_{i,Q}$ as input, and outputs the verification evidence $proof$.

6) $F\leftarrow Dec(K_2,C)$, this algorithm takes the symmetric key $K_2$ and the encrypted file C as input, and outputs the plaintext F.

Leakage function

The goal of searchable encryption is to leak as little information as possible about the keywords and files during ciphertext retrieval. Similar to Wu et al. (2023), the leak function is defined as $\mathcal{L}=\{{\mathcal{L}}_{IndexBuild},{\mathcal{L}}_{\mathrm{S}\mathrm{e}\mathrm{a}\mathrm{r}\mathrm{c}\mathrm{h}},{\mathcal{L}}_{\mathrm{V}\mathrm{e}\mathrm{r}\mathrm{i}\mathrm{f}\mathrm{y}}\}$. According to the common definition, query history $Hist=\{(D{B}_i,q_i){\}}_{i=0}^n$, which stores a series of query requests and corresponding database snapshots. The search pattern $sp(w)=\{i|\mathrm{f}\mathrm{o}\mathrm{r}\mathrm{e}\mathrm{a}\mathrm{c}\mathrm{h}{q}_i\mathrm{t}\mathrm{h}\mathrm{a}\mathrm{t}\mathrm{c}\mathrm{o}\mathrm{n}\mathrm{t}\mathrm{a}\mathrm{i}\mathrm{n}\mathrm{s}w\mathrm{i}\mathrm{n}\mathbf{H}\mathbf{i}\mathbf{s}\mathbf{t}\}$, which records each query request. The proof history $ph(w)=\{(i,proo{f}_i)|foreach(i,in{d}_i,w)inHist\}$. Then, we can define the leakage function ${\mathcal{L}}_{IndexBuild}=(ph(w))$, ${\mathcal{L}}_{\mathrm{S}\mathrm{e}\mathrm{a}\mathrm{r}\mathrm{c}\mathrm{h}}=(sp(w),ph(w))$ and ${\mathcal{L}}_{\mathrm{V}\mathrm{e}\mathrm{r}\mathrm{i}\mathrm{f}\mathrm{y}}=(ph(w))$.

Security definitions

Definition 1 (Verifiability). In an efficient and verifiable phrase search scheme, if the probability that the forged result generated by any probabilistic polynomial time (PPT) adversary passes the Verify algorithm is infinitesimal, the scheme satisfies verifiability.

Definition 2 (CKA2-security). For the verifiable phase search scheme $\prod$ ={ $KeyGen,IndexBuild,$ $TokenGen,Search,Verify,Dec$}, there is a leakage function $\mathcal{L}=\{{\mathcal{L}}_{IndexBuild},{\mathcal{L}}_{\mathrm{S}\mathrm{e}\mathrm{a}\mathrm{r}\mathrm{c}\mathrm{h}},{\mathcal{L}}_{\mathrm{V}\mathrm{e}\mathrm{r}\mathrm{i}\mathrm{f}\mathrm{y}}\}$, an adversary $\mathcal{A}$ and an idealized simulator $\mathcal{S}$, as well as two games $\mathrm{R}\mathrm{e}\mathrm{a}{\mathrm{l}}_{\mathcal{A}}(\lambda )$ and $\mathrm{I}\mathrm{d}\mathrm{e}\mathrm{a}{\mathrm{l}}_{\mathcal{A},\mathcal{S}}(\lambda )$, satisfying:

$\mathrm{R}\mathrm{e}\mathrm{a}{\mathrm{l}}_{\mathcal{A}}(\lambda )$: The challenger generates system key $K=\{K_1,K_2,K_3\}$ and index ( $\mathcal{I}$, T, B) by executing algorithm $KeyGen(1^{\lambda })$ and algorithm $IndexBuild(\mathcal{F},\mathcal{W},K)$,( $\mathcal{I}$, T, B) are transmitted to the adversary $\mathcal{A}$. $\mathcal{A}$ proceeds to formulate a sequence of adaptive queries $Q=\{q_1,q_2,\dots ,q_t\}$, with the challenger generating search tokens for each query, and receives the results of executing algorithms $Search$ and $Verify$. Finally, $\mathcal{A}$ produces a bit $b$ as the output of this experiment.

$\mathrm{I}\mathrm{d}\mathrm{e}\mathrm{a}{\mathrm{l}}_{\mathcal{A},\mathcal{S}}(\lambda )$: The simulator $\mathcal{S}$ takes (F, W) generated by the adversary $\mathcal{A}$ as input and outputs index ( $\mathcal{I}$, T, B) by executing algorithm ${\mathcal{L}}_{\mathrm{I}\mathrm{n}\mathrm{d}\mathrm{e}\mathrm{x}\mathrm{B}\mathrm{u}\mathrm{i}\mathrm{l}\mathrm{d}}$. Then, for a series of adaptive queries $Q=\{q_1,q_2,\dots ,q_t\}$ generated by the adversary $\mathcal{A}$, $\mathcal{S}$ generates search results by executing algorithms ${\mathcal{L}}_{\mathrm{S}\mathrm{e}\mathrm{a}\mathrm{r}\mathrm{c}\mathrm{h}}$ and ${\mathcal{L}}_{\mathrm{V}\mathrm{e}\mathrm{r}\mathrm{i}\mathrm{f}\mathrm{y}}$, $\mathcal{A}$ receives those results and produces a bit $b$ as the output of this experiment.

If there is a simulator $\mathcal{S}$ such that for any PPT adversary $\mathcal{A}$:

$$|Pr[\mathrm{R}\mathrm{e}\mathrm{a}{\mathrm{l}}_{\mathcal{A}}(\lambda )=1]-Pr[\mathrm{I}\mathrm{d}\mathrm{e}\mathrm{a}{\mathrm{l}}_{\mathcal{A},\mathcal{S}}(\lambda )]=\le negl(\lambda ),$$then $\prod$ is $\mathcal{L}$–secure against adaptive chosen-keyword attack (CKA2), where $negl$ is an negligible function and $\lambda$ is the security parameter.

Preliminaries

Bitmaps employ binary strings to represent information sets, commonly utilized for storing file identifiers in encrypted searches, thus efficiently reducing storage requirements. In our model, each keyword $w_i$ corresponds to a bitmap, and the bitmap is a string composed of a series of 0 or 1, each 0 or 1 denotes a file. If the $i-th$ document contains $w_i$, the value of the string at position $i$ is set to 1, otherwise 0. For instance, with four files ( $F_1$, $F_2$, $F_3$, $F_4$) and two keywords ( $w_1$, $w_2$) in the system, depicted in Fig. 2, $w_1$ is found in $F_1$ and $F_3$, while $w_2$ exists in $F_2$ and $F_3$. The bitmaps for $w_1$ and $w_2$ are 1010 and 0110, respectively. To search for files containing both $w_1$ and $w_2$, an “AND” operation on these two bitmaps is performed, yielding $1010\wedge 0110=0010$, indicating that $F_3$ contains both $w_1$ and $w_2$.

Homomorphic encryption represents an encryption technique capable of transforming a ciphertext into another without altering the decryption key. In this study, we employ the prevalent Paillier additive homomorphic encryption to compute the distance between keywords within phrases. In essence, its functionality can be outlined as follows:

1) Key Generation: Let $p$ and $q$ denote two large primes such that $gcd(pq,(p-1)\times (q-1))=1$. Define $n=pq$ and $\lambda =lcm(p-1,q-1)$. Choose a random integer $g$ from ${\mathrm{Z}}_{n^2}^{\ast }$ satisfying $gcd(L(g^{\lambda }\mathrm{m}\mathrm{o}\mathrm{d}{n}^2),n)=1$, where $L(x)=(x-1)/n$ and ${\mathrm{Z}}_{n^2}^{\ast }=\{1,2,\dots ,n^2-1\}$. Then, the public key $(n,g)$ and the private key $\lambda$ are obtained.

2) Encryption: Given a message $m$, it can be encrypted into its ciphertext $c$ as follows:

(1) $$c=E(m,r)=g^m{r}^n\mathrm{m}\mathrm{o}\mathrm{d}{n}^2$$where $r$ is randomly selected from $r\in {\mathrm{Z}}_n$.

3) Decryption: For the ciphertext $c$, it can be decrypted into its plaintext $m$ as follows:

(2) $$m=D(c,\lambda )=\frac{L(c^{\lambda }\mathrm{m}\mathrm{o}\mathrm{d}{n}^2)}{L(g^{\lambda }\mathrm{m}\mathrm{o}\mathrm{d}{n}^2)}\mathrm{m}\mathrm{o}\mathrm{d}n$$

This algorithm exhibits additive homomorphism. Given two messages $a$ and $b$ along with their corresponding ciphertexts $E(a)$ and $E(b)$, we can obtain the ciphertext of $(a+b)$ via $E(a)\cdot E(b)$, i.e., $E(a+b)=E(a)\cdot E(b)$. This property can be leveraged to compute the distance between keywords in a phrase, aiding in determining their positional relationship.

Multiset Hash Function (Li et al., 2023): Multiset hash is a cryptographic tool that maps multiple sets of any finite size to a fixed hash length. Furthermore, multiset hash is also updateable: when the elements in the set change, the hash value only updates the current value without recalculating all.

Our scheme uses the most efficient multi-set hash function: MSet-XOR-Hash, containing three polynomial algorithms ( $\mathcal{H}$, $+\mathcal{H}$, $\equiv \mathcal{H}$). Given a multiset M, the MSet-XOR-Hash can be expressed as follows:

$$\{\begin{array}{cc}\mathcal{H}(r,M)\hfill & =H_k(0,r)\oplus \underset{m\in M}{\oplus }{H}_k(1,m);\hfill \\ \mathcal{H}(r,M\cup \{x\})& {\equiv }_{\mathcal{H}}\mathcal{H}(r,M){+}_{\mathcal{H}}\mathcal{H}(r,\{x\})\hfill \\ & {\equiv }_{\mathcal{H}}\mathcal{H}(r,M)\oplus H_k(1,x);\hfill \\ \mathcal{H}(r,M\backslash \{x\})& {\equiv }_{\mathcal{H}}\mathcal{H}(r,M){-}_{\mathcal{H}}\mathcal{H}(r,\{x\})\hfill \\ & {\equiv }_{\mathcal{H}}\mathcal{H}(r,M)\oplus H_k(1,x)\hfill \end{array}$$

Composite index containing files and locations

In phrase search, a phrase is composed of multiple keywords according to a certain positional relationship, which is also the difference between phrase search and multi-keyword search. To perform a phrase search, the cloud server not only needs to search for all keywords contained in the phrase, but also needs to determine whether the order between keywords is correct.

To identify the position relationship between keywords in phrases, we designed a composite index containing files and locations, the structure of the composite index is shown in Fig. 3.

The composite index adopts inverted index structure to ensure high efficiency of search, but, it’s different from the general inverted index in that each keyword not only corresponds to the ID of a series of files, but also appends all the locations where the keyword appears in the file. For example, in Fig. 3, suppose there are three keywords (“ $heart$”, “ $attack$”, “ $medic$”) and five corresponding files ( $F_1$, $F_2$, $F_3$, $F_4$, $F_5$), for simplicity, encryptions are not shown. The positions of keyword “ $heart$” in files $F_1$, $F_2$, $F_3$ are (1, 8, 3), (1, 2, 4) and (2, 3, 5) respectively, the positions of keyword “ $attack$” in files $F_1$, $F_2$, $F_4$ are (2, 5, 7), (3, 7, 9) and (1, 2, 5). When the cloud server searches the phrase “ $heart$ $attack$”, it finds that the location of keyword “ $heart$” in $F_1$ is (1, 8, 3) through the composite index, then it finds the location of keyword “ $attack$” in $F_1$ is (2, 5, 7). Using the encrypted distance discrimination algorithm, the cloud server computes the position of “ $attack$” in file $F_1$ is 1 larger than that of “ $heart$” by $E(2)=E(1)\cdot E(1)$. Similarly, the cloud server computes that “ $attack$” is after “ $heart$” in $F_2$ through $E(3)=E(2)\cdot E(1)$. After searching the location of all keywords in the composite index, the server calculates that $F_1$ and $F_2$ contain the phrase “heart attack”.

Encrypted distance discrimination algorithm-EDDA

The sequence of keywords in a phrase can be expressed by a sentinel and the distance between each remaining keyword and the sentinel. For example, in a phrase containing three keywords ( $w_1$, $w_2$, $w_3$), the position of $w_1$, $w_2$, $w_3$ are 1, 2, 3, we choose $w_1$ as the sentinel. The distance between $w_2$ and $w_1$ is 1, and the distance between $w_3$ and $w_1$ is 2. Suppose that positions of ( $w_1$, $w_2$, $w_3$) are ( $po{s}_1$, $po{s}_2$, $po{s}_3$), if we can calculate $po{s}_2=po{s}_1+1$ and $po{s}_3=po{s}_1+2$, we can recognize that ( $w_1$, $w_2$, $w_3$) is a phrase.

In our scheme, the positions of keywords stored in the composite index are encrypted, and the server should be able to recognize phrases without the decryption key. Therefore, we utilize the paillier homomorphic encryption to construct the distance discrimination algorithm to determine the location relationship between keywords,the details are as follows:

$E(d)$ is the distance after paillier homomorphic encryption, and $S{L}_{w_j}^i$ denotes the encrypted location of the keyword $w_j$ in file $i{d}_i$, the definition of $S{L}_{w_j}^i$ is as follows:

(3) $$S{L}_{w_j}^i=\pi (i{d}_i)+E(po{s}_{w_j}^i)$$

E represents paillier homomorphic encryption function and $\pi$ represents hash function, $po{s}_{w_j}^i$ is the original location of the keyword $w_j$ in file $i{d}_i$. In addition, keyword $w_j$ may appears in multiple locations in the same file, in this case, $E(po{s}_{w_j}^i)$ represents a series of positions.

In distance discrimination algorithm, $S{L}_{w_1}^i{|}_{|\pi |}\oplus S{L}_{w_2}^i{|}_{|\pi |}$ is used to determine whether $w_1$ and $w_2$ belong to the same file, if so, $va{l}_i==0$. $E(po{s}_{w_1}^i)\leftarrow S{L}_{w_j}^i{|}_{-(|S{L}_{w_j}^i|-|\pi |)}$ is used to calculate encrypted location of keyword $w_j$, and $E(po{s}_{w_2}^i)==E(po{s}_{w_1}^i)+E(d)$ is used to determine whether the keyword $w_2$ is located in the $d$ position after $w_1$. When the user executes the phrase search request, he can designate the first word (i.e., $w_1$) in the phrase as the sentry, then calculate the distance $d$ between the remaining words and the sentry one by one, encrypt $d$, and finally generate a search token and send it to the server for search.

Details of our construction

Like most searchable encryption schemes, we adopt an inverted index structure to construct the secure index. In the inverted index, we use a bitmap to store the identifier of the file. Let $H:\{0,1{\}}^{\ast }\to \{0,1{\}}^m,F:\{0,1{\}}^{\ast }\to \{0,1{\}}^n$ be secure pseudo-random functions (PRFs).

$KeyGen(1^{\lambda })$. The IoT device uses the secret parameters $\lambda$ to generate the key set $K=\{K_1,K_2,K_3,K_4,K_I,K_Z,K_X,pk,sk\}$, where $K_1,K_2,K_3,K_4,K_I,K_Z,K_X\stackrel{\mathrm{\$}}{⟵}\{0,1{\}}^{\lambda }$, $(pk,sk)\leftarrow Paillier.KeyGen(1^{\lambda })$. $K_1$ is used to encrypt the identifier of files, $K_2$ is the secret key of symmetric encryption, $K_3$ is the key for PRF F, $(pk,sk)$ is the public key and the private key of paillier encryption.

$IndexBuild(\mathcal{F},\mathcal{W},K)$. Given a set of files $\mathcal{F}$, a set of keywords $\mathcal{W}$, and the key set K, the IoT device generates the secure index $\mathcal{I}$, the encrypted database T, the checklist B, the details are shown in Algorithm 2.

For each file ${\mathrm{F}}_{\mathrm{i}}\in \mathcal{F}$, IoT device encrypts it to the ciphertext $C_i$ with symmetric encryption $Enc(K_2,{\mathrm{F}}_{\mathrm{i}})$. The ciphertext $C_i$ is stored in encrypted database T, and the hash value $has{h}_i$ of $C_i$ is stored in checklist B for verification.

IoT device generates a bitmap ${\mathcal{B}}_{w_j}$ for each keyword $w_j$, ${\mathcal{B}}_{w_j}$ is encrypted by $v_{\mathcal{B}}\leftarrow {\mathcal{B}}_{w_j}\oplus H_2(u_{w_j}||s{t}_j)$ and $v_{\mathcal{B}}$ is stored in the secure index $\mathcal{I}$. Especially, in order to protect the privacy of files, IoT device uses ${\ell }_i\leftarrow H_2(i{d}_i||K_1)$ to encrypt the $id$ of files, and then uses ${\ell }_i$ to generate ${\mathcal{B}}_{w_j}$. Since the $id$ stored on the server is encrypted, the server cannot obtain the real $id$ from ${\mathcal{B}}_{w_j}$, which ensures the privacy of the search pattern.

To identify phrases, the IoT device extracts positions $(po{s}_1,po{s}_2,\dots ,po{s}_m)$ of keyword $w_j$ in file ${\mathrm{F}}_{\mathrm{i}}$, and encrypts them using $Paillier.Enc(po{s}_m)$:

$$S{L}_{w_j}^i=\pi (i{d}_i)+E(po{s}_1)+E(po{s}_2)+\dots +E(po{s}_m)$$

$TokenGen(\tilde{w},K_3,pk)$. Authorized users get shared parameters $\mathrm{\Omega }=\{K_3,pk\}$ from the IoT device. For the phrase $\tilde{w}=\{w_1,w_2,...,w_t\}$ to be queried, the trapdoor $T{K}_{i,Q}$ is generated as Algorithm 3.

Assume that the keywords $\{w_1,w_2,\dots ,w_t\}$ in phrase are arranged in order. The data user calculates the distance $d$ between the keyword $w_t$ and the first keyword $w_1$ and encrypts it with $Paillier.Enc(d)$. At last, $t_{w_j}$ and $E_d$ are added to the trapdoor $T{K}_{i,Q}$ and sent to the cloud server and the blockchain.

$Search(\mathcal{I},T,T{K}_{i,Q})$. As shown in Algorithm 4, the cloud server performs an encrypted search with the secure index $\mathcal{I}$, the encrypted database T and the trapdoor $T{K}_{i,Q}$.

After receiving the query request, the server parses the trapdoor $\{t_{w_1},t_{w_2},\dots ,t_{w_t},E_1,E_2,..E_{t-1}\}\leftarrow T{K}_{i,Q}$. The server gets the bitmap ${\mathcal{B}}_{w_i}$ of $w_i$ from the secure index $\mathcal{I}$ through $v_{\mathcal{B}}\leftarrow \mathcal{I}[t_{w_i}],{\mathcal{B}}_{w_i}\leftarrow v_{\mathcal{B}}\oplus H(t_{w_i})$. To get the file that contains all the keywords in the phrase $\tilde{w}$, the server performs the operation “AND” on the bitmap of all keywords as follows:

$$\mathcal{B}={\mathcal{B}}_1\wedge {\mathcal{B}}_2\wedge \dots \wedge {\mathcal{B}}_t.$$

The file corresponding to the element with a value of “1” in $\mathcal{B}$ contains all the keywords in the phrase. The server gets the set of identifiers of these files as $I{D}_{\mathcal{B}}=\{{\ell }_1,{\ell }_2,\dots ,{\ell }_p\}$ according to $\mathcal{B}$.

Next, the server determines whether the sequence of the keywords in the file ${\ell }_i$ is consistent with the order of the keywords in the phrase, as described in line 7–line 20 in Algorithm 3. The server chooses a binary string $flag$ of length $(t-1)$, and set all values to “0”. The server gets all positions $E(po{s}_1^i),E(po{s}_2^i),E(po{s}_n^i)$ of the keyword $w_j$ in the file ${\ell }_i$. For the position $E(po{s}_1^{k^{\mathrm{\prime }}})$ of the keyword $w_j(j>1)$ in file ${\ell }_i$, the server utilizes the distance discrimination algorithm EDDA to determine the distance between keyword $w_j(j>1)$ and the first keyword $w_1$ in the phrase. Like

(4) $$E(po{s}_1^{k^{\mathrm{\prime }}})=E(po{s}_1^k)\times E(d-1)$$where E represents the $Paillier.Enc$. If Formula (4) holds, the distance between keywords $w_1$ and $w_j$ is $(d-1)$, which is the same as that in the phrase, the server sets the position $(i-1)$ of $flag$ to “1”. If all positions of $flag$ are “1”, then the file ${\ell }_i$ contains the phrase $\tilde{w}$, and it is added to the search result R. Finally, the aggregation proof $\psi$ is sent to the blockchain for reliable verification, and the ciphertext collection of search results R is sent to the user.

$Verify(\mathcal{I},B,T{K}_{i,Q},\psi )$. The blockchain utilizes $T{K}_{i,Q}$ for phrase searches to verify the aggregated evidence $\psi$ returned by the cloud server, as shown in Algorithm 5. To ensure the reliable verification of search results, the verification algorithm $Verify$ not only verifies the integrity of the files, but also verifies whether the server has returned all files that meet the search requirements.

The blockchain performs the same operations as the server (line 1–line 6), retrieving the composite index stored on itself with the trapdoor $T{K}_{i,Q}$, and calculates the search result ${\psi }^{\mathrm{\prime }}$. Due to the immutability of data on the blockchain, the composite index stored and search results calculated by the blockchain are reliable. Blockchain achieves reliable verification of phrase search results by comparing ${\psi }^{\mathrm{\prime }}$ with the search result $\psi$ returned by the server.

For the file ${\ell }_i$, the blockchain obtains the corresponding hash value $has{h}_i$ by searching the checklist B and compresses it into the benchmark value ${\psi }^{\mathrm{\prime }}$. By comparing the aggregate evidence $\psi$ sent by the server with ${\psi }^{\mathrm{\prime }}$, the blockchain sets the value of $proof$ as follows:

$$proof=\{\begin{array}{cc}1,\hfill & \mathrm{i}\mathrm{f}\psi ={\psi }^{\mathrm{\prime }},\hfill \\ 0,\hfill & \mathrm{o}\mathrm{t}\mathrm{h}\mathrm{e}\mathrm{r}\mathrm{w}\mathrm{i}\mathrm{s}\mathrm{e}.\hfill \end{array}$$

By comparing $\psi ={\psi }^{\mathrm{\prime }}$, the blockchain can determine: 1) whether the server has returned all files that meet the search requirements; 2) the content of the files has been modified.

Then the verification evidence $proof$ are sent to the data user. The data user judges the received $proof$, and accepts the search result R if $proof=1$, otherwise rejects R. For the accepted search result R, the data user uses the symmetric key to decrypt the file in it, to get the plaintext of the file, and the phrase search process is completed.

Discussion

Ensuring the reliability of verification is an important target of our scheme. In the existing phrase search scheme, the secure index is stored on the server, and the verification evidence is generated by the server. Untrusted servers may only store partial indexes and ciphertexts, resulting in untrustworthy search results and verification evidence. Whereas in our scheme, blockchain uses search trapdoor to calculate verification evidence, the data stored on the blockchain is unforgeable, so the search results on the blockchain are reliable. At the same time, the verification of the results returned by the server is also performed by the blockchain, which prevents dishonest data users from falsifying the verification results and ensures the reliability of the verification results.