Searchable Symmetric Encryption with Tunable Leakage Using Multiple Servers

Abstract

Searchable symmetric encryption has been a promising primitive as it enables a cloud user to search over outsourced encrypted data efficiently by only leaking small amount of controllable leakage. However, recent leakage-abuse attacks demonstrate that those stand leakage profiles can be exploited to perform severe attacks – the attacker can recover query or document with high probability. Ideal defending methods by leveraging heavy cryptographic primitives, e.g. Oblivious RAM, Multiparty Computation, are still too inefficient for practice nowadays.

In this paper, we investigate another approach for countering leakage-abuse attacks. Our idea is to design SSE with tunable leakage, which provides a configurable way for trade-off between privacy and efficiency. Another idea is to share the leakage among multiple non-collude servers, thus a single server can only learn partial, rather than the whole leakage. Following the ideas, we proposed two SSE schemes. The first scheme uses two servers and is static, which serves as the first step to emphasize our design methodology. Then we propose a dynamic SSE scheme, by additionally use a third server to hold dynamic updates. We demonstrate that the leakage for the third server is only partial update history, a newly defined leakage notion that leaks limited information rather than the whole update history. Our schemes provide stronger security that hides search/access pattern in a tunable way as well as maintains forward and backward privacy. We also report the performance of our constructions, which shows that both schemes are efficient.

This work is supported by National Natural Science Foundation of China (Grant No. 61572294, 61632020).

Appendices

Appendix A Proof of Theorem 1

Proof

We prove the security of our scheme by ideal/real simulation. We start from $\mathbf{Real} ^\mathrm{\Pi }_{\mathcal {A}}(\lambda )$ and construct a sequence of games that differs slightly from the previous game and show they are indistinguishable. Eventually we reach the last game $\mathbf{Ideal} ^\mathrm{\Pi }_{\mathcal {A}, \mathcal {S}}(\lambda )$. By the transitive property of the indistinguishability, we conclude that $\mathbf{Real} ^\mathrm{\Pi }_{\mathcal {A}}(\lambda )$ is indistinguishable from $\mathbf{Ideal} ^\mathrm{\Pi }_{\mathcal {A}, \mathcal {S}}(\lambda )$ and complete our proof.

Hybrid $G_1$: $G_1$ is the same as $\mathbf{Real} ^\mathrm{\Pi }_{\mathcal {A}}(\lambda )$ except that instead of generating $t_w$ using F, the experiment maintain a mapping Token to store $(h(w)||s_w||b, k_w)$ pairs. In the search protocol, when $k_w$ is needed, the experiment first checks whether there is an entry in Token for $h(w)||s_w||b$, if so returns the entry; otherwise randomly picks a $k_w$ in $\{0, 1\}^{\ell _k}$ and stores the $(h(w)||s_w||b, k_w)$ pair in Token. It’s trivial to see that $G_1$ and $\mathbf{Real} ^\mathrm{\Pi }_{\mathcal {A}}(\lambda )$ are indistinguishable, otherwise we can distinguish a pseudo-random function F and a truly random function.

Hybrid $G_2$: $G_2$ and $G_1$ is the same except that in $G_2$ the experiment will maintain a map E. Instead of producing e by calling $H(k_w, u_w)$, in Setup protocol, the experiment will replace it with the following procedure:

The intuition is to firstly sampling random string during setup, and program H correspondingly to maintain consistency. Now in search protocol, the entry e is generated with the following procedure:

$G_1$ and $G_2$ behaves exactly the same except that in $G_2$, with some probability inconsistency in random oracle query results can be observed. If the adversary queries $\mathbf{H}$ with $k_w||u_w$ before the next search query, it will get a value $e'$ such that with a overwhelming probability $e'\ne e$ because $\mathbf{H} [k_w||u_w]$ has not been updated and a random string $e'$ is chosen by the oracle in this case. If the adversary queries $\mathbf{H}$ with $k_w||u_w$ again after the next search query, e will be updated to the $\mathbf{H}$ and the query result will be e. If the inconsistency is observed (we denote this event as $\mathbf{Bad}$), the adversary knows it is in $G_2$. We have:

The event Bad can only happen if the adversary can query the oracle with $k_w||u_w$. Since $k_w$ is pseudorandom output of PRF F and is unknown to the adversary before search, the probability of the adversary choosing $k_w$ is $2^{-\lambda }$. A PPT adversary can make at most $q=\mathbf{poly} (\lambda )$ guesses, then $\mathrm{Pr}[\mathbf{Bad} ] \le \frac{q}{2^\lambda }$, which is also negligible.

Fig. 5.

Pseudocode of $G_3$

Hybrid $G_3$: $G_3$ and $G_2$ is the same except that in $G_3$ we change the way of generating encrypted value v. Note that in $G_2$, the value v is generated by a IND-CPA secure symmetric key encryption scheme SE, therefore the ciphertext is semantically secure. In $G_3$, the experiment simply choose a random value with the same length as SE’s ciphertext whenever the SE.Enc is called. After above replacement, some code are not necessary, so we do cleanup for readability. The full pseudocode of $G_4$ can be found in Fig. 5.

The asversary cannot distinguish between $G_2$ and $G_3$ because of the semantic security of SE, hence we have:

Hybrid $G_4$: In $G_4$, we perform further simplification for the pseudocode. Firstly, the experiment does not need to generate (e, v) pair for each keyword separately. The reason is that in $G_3$, both e and v are generated by random sampling, so randomly generating $N_b$ pairs of string in $G_4$ is not distinguishable from the prior approach.

Similarly, when receiving search query, if the query will touch storage in $\textsf {EDB}_b$ that is from setup, then the experiment just randomly chooses $u_w$ non-touched entries, and then programs the random oracle; Otherwise, if the search query is for a keyword that has been search previously, then the experiment will program the random oracle, in a way that make the server return those encrypted values that is previously uploaded by client from a shuffle phrase – the experiment can do above decision by simply checking if $s_w$ equals to 0. For other parts, $G_4$ behaves the same as $G_3$

Fig. 6.

Pseudocode of simulator $\mathcal {S}$

$\mathbf{Ideal} ^\mathrm{\Pi }_{\mathcal {A}, Sim}(\lambda )$: In ideal world, the simulator needs to simulate all views of the server just using the allowed leakage profile. The simulation is quite simple. In setup protocol, the simulator can just randomly generate $N_b$ pair of random strings and upload to server $S_b$ to completes the simulation. The tricky part is about the simulation of search protocol. Note that in a our search protocol, the client will firstly query server $S_b$ for result, then re-encrypt the result and upload to the other server $S_{b\oplus 1}$. To complete the simulation, in ideal world there are two simulators for $S_0$ and $S_1$ separately. The first simulator $\textsf {Sim}_b$ will simulator the view for $S_b$ and simulator $\textsf {Sim}_{b\oplus 1}$ will simulate the view of $S_{b \oplus 1}$ (the intuition is each simulator can independently complete simulation without sharing information, which is consistent with the non-collusion assumption).

For the simulation for server $S_b$, simulator $\textsf {Sim}_b$ will randomly generate $k_w$, get the group size $u_w$ from the leakage function, and send them to server $S_b$. After that, the simulator should program the random oracle to make some entries match with the impending search operation. Specifically, the simulator get leakage $\textsf {LastUpHist}(w)$ from the leakage function. If $\textsf {LastUpHist}(w)$ only contains 0, then the simulator knows the keyword is never searched before, then it can just randomly select |PDB(w)| untouched storage entries that are produced from setup protocol (not includes those that are uploaded due to search re-shuffle!); if not, then the simulator knows the keyword has been searched before, and then it can get the re-shuffle time and fetch all required entries. Then $\textsf {Sim}_b$ program random oracle and complete the simulation. The simulation of $\textsf {Sim}_{b \oplus 1}$ is simple, it just generate $|\textsf {PDB}(w)|$ random (e, v) pairs and upload to server $S_{b \oplus 1}$. For other parts, $\mathbf{Ideal} ^\mathrm{\Pi }_{\mathcal {A}, Sim}(\lambda )$ behaves the same as $G_4$.

All summed up, we have:

$$ |\mathrm{Pr}[\mathbf{Real} ^\mathrm{\Pi }_{\mathcal {A}}(\lambda )=1]-\mathrm{Pr}[\mathbf{Ideal} ^\mathrm{\Pi }_{\mathcal {A},{Sim}}(\lambda )=1]| \le \mathbf{negl} (\lambda ) $$

Appendix B Proof of Theorem 2

The proof of Theorem 2 is almost the same with the proof of Theorem 1, the only difference is to handle the partial update in the third server. Note that the $\textsf {partUpHist(w)}$ enables the simulator to learn all update timestamps for a temporary keyword that the client updated previously, then the simulator can use similar technique to program the random oracle like Fig. 6. Therefore, we decide not to rewrite the proof here.