1 Introduction

Outsourcing documents to third-party storage providers allows the providers to learn the content of the documents. In order to protect data privacy, a user may encrypt the documents before submission, but straightforward encryption eliminates the capability of searching them. Searchable symmetric encryption (SSE) was proposed as a practical mechanism to address this issue. An SSE scheme encrypts documents in such a way that the output contains encrypted data and their associated metadata. Through querying the metadata the scheme returns references to the matching encrypted data, which can then be retrieved and decrypted locally. Existing (dynamic) SSE schemes mainly concentrate on settings for single-user single server [4, 6, 7, 13, 15, 19, 20, 22, 25, 28, 30, 32], multi-user single server [5, 10, 11, 18, 24], and two servers [3, 16, 29] where one of the servers serves as a query proxy. As far as we know, to date there is no proposal involving multiple (≥ 2) providers where every provider stores only a portion of the documents and the associated metadata. Such a construction is of interest since many storage providers are readily available, i.e. Dropbox, Google Drive, Amazon S3 and Microsoft OneDrive. Given these choices, a user can choose to distribute searchable encrypted documents/blocks to many of them instead of one, so that no single provider will have the full set of encrypted documents. Each provider only holds a subset of blocks of an encrypted document. This cannot be achieved in a single provider setup. It also allows new constructions with potentially better hiding properties. For ease of description, we refer to storage providers as servers in the subsequent sections.

Our contributions

We extend the notion of SSE to SSE over multiple servers, and instantiate multiserver schemes with first a generic construction, then subsequently another construction using similar structures of recent schemes [5, 7]. We also describe how existing schemes can be extended to multiserver scheme straightforwardly under the generic construction, using [5]’s scheme as an example, demonstrating the flexibility of our definition. In fact, this also shows the scalability of most of the existing schemes. Our second construction divides documents into blocks, with the blocks SSE-encrypted and randomly assigned to different servers in such a way that, with high probability, no single server alone holds all encrypted blocks of a document. Hence, only partial information of a document stored in a server is revealed if the server successfully cryptanalysed the encrypted blocks, provided servers do not collude. It provides better leakage profile than existing schemes, in that document sizes and total number of documents are hidden even after retrieval, while maintaining sublinear search time for each server. Instead of creating an index that links keywords directly to document identifiers as in most existing schemes, we create index tables that link keywords to block-server identifier pairs where a block referenced by an identifier in server i may be stored in a different server j. Because of the decoupling between the block identifiers and the exact locations of stored blocks, a server cannot categorise with certainty a group of encrypted identifiers that map to a set of actual blocks during retrieval. In fact, most schemes directly reveal the matching identifier-document pairs during retrieval, which allow for straightforward categorisation of tokens that match the queried documents. We prove security in the setting of colluding and non-colluding servers under the real-ideal simulation paradigm proposed in [10] and its generalisation in [4, 7].

2 Related works

Song et al. [30] introduced SSE schemes. Their schemes encrypt words, in which during retrieval the words are first unmasked based on a query stream before decryption. Search time is linear since all words must be scanned. Indexing techniques were also described without concrete constructions. Goh [13] then proposed secure index suitable for SSE, but query privacy is not necessarily required. Using the simulation model, Chang and Mitzenmacher [6] proposed a linear SSE scheme secure for index and queries. Curtmola et al. [10] however showed that Chang and Mitzenmacher’s definition is non-adaptive and can be satisfied with an insecure SSE. An improved definition encompassing non-adaptive and adaptive keyword attack was thus proposed, together with a scheme achieving sublinear search time using inverted index. Many subsequent proposals adopted Curtmola et al.’s definition and index structure. These include Chase and Kamara [7]’s schemes that support SSE over arbitrary data structures, and dynamic and parallel schemes proposed in [19] and [20]. We also adopt their security definitions and use similar data structures.

Following these schemes, which focus on single-keyword search, Cash et al. [4] introduced sublinear SSE schemes that support multi-keyword search for large datasets. This was extended to multi-user in [18] and parallelizable dynamic schemes in [5]. Naveed et al. [28] then proposed a blind storage scheme based on hash tables with linear probing that can be used for SSE. It does not leak the size of a document until it is queried. In their scheme, the server does not perform index operations. This is done by the user instead so that readily available commodity storage server can be used without any modification. Stefanov et al. [32] proposed a dynamic scheme with less leakage by combining the practicality of SSE with the hiding properties of ORAM.

More recently, two-server schemes termed as distributed SSE were proposed [3, 16, 29]. A proxy server is introduced in addition to the storage server. The idea is for the proxy to assist in queries so that the schemes do not leak search patterns, with the assumption of non-colluding servers. In contrast, our constructions use two or more servers with a somewhat different focus. Our aim is to distribute documents/blocks to many servers, in order to prevent any one server from possessing a complete set of documents or blocks of a document. Due to such distributions our schemes minimise leakages on search patterns though not fully-hiding as with the two-server schemes. Furthermore we consider colluding servers. Another related scheme is the scheme proposed in [24], in which distributed indexes are constructed so that they can be easily distributed to many devices under a cloud storage system for efficient search and retrieval.

Moataz and Shikfa [25] proposed a boolean scheme with probabilistic tokens to address the issue of leakage due to deterministic tokens of existing schemes. However the scheme search time is linear. Verifiable SSE schemes that protect against unauthorised modification were also proposed [8, 22, 23, 26]. Islam et al. [17] provided empirical analysis on access pattern leakages and proposed possible mitigation techniques. A related notion is Private Information Retrieval (PIR) [9]. It proposes private retrieval over servers with each server having an exact copy of the database. PIR schemes are mostly related to public databases instead of encrypted databases. We also examine multiple servers but focus on practicality where each server stores only partial information of the encrypted database. A simple, static construct in this setting was proposed in [27]. However it does not provide general framework that caters for existing single server schemes, and it leaks the number of documents matching a keyword after a query.

Fully hidden schemes can be achieved using primitives such as fully homomorphic encryption [12] and ORAM [14, 31], but both have yet to achieve the efficiency of SSE [32]. There are also public-key based schemes, which were introduced by Boneh et al. [1]. For a comprehensive survey, we refer interested readers to [2].

3 Definitions

We adopt the notation and security model from [4, 7, 10]. Our proposals involve a user and a set of distinct servers S = {S 1, … , S s }, s ∈ ℕ. Let λ ∈ ℕ be the security parameter and || as concatenation. The user owns a set of documents, D = {D 1, D 2, … , D n }, and each document D f is either a complete document or a document divided into h equal-length blocks, D f = (d f,1||1, d f,2||2, … , d f, h ||h) for 1 ≤ fn, max(h) = l and d f, i ∈ {0, 1}ϕ(λ) where ϕ is a polynomial function in λ. Also, we use i d x ∈ {0, 1}λ to denote an identifier that uniquely identifies x. D is stored in a database with index DB \((id_{D_{f}}, W_{f})^{n}_{f=1}\), where W f = \(\{w_{f,1}, w_{f,2}, \ldots , w_{f,t_{f}} \}\) denotes the set of keywords matching document D f and w f, j ∈ {0, 1}. The list of documents matching a keyword w is denoted as DB (w) while the total number of identifiers matching all keywords is N wW |DB(w)|, where W \(= \bigcup ^{n}_{f=1}W_{f}\). We further denote {1, 2, … , n} as [n], xA to mean x is an output of an algorithm A and \(x \xleftarrow {\smash {R}} X\) to mean random selection of a value x from a set X. We use negl (x) to denote a negligible function. We assume a semi-honest adversary \(\mathcal {A}\). For colluding servers, in the worst case we assume \(\mathcal {A}\) takes full control of all servers, where servers communicate among themselves to learn information from the scheme.

\(\mathcal {E}\) and F. A randomised symmetric encryption scheme \(\mathcal {E} =\) (Gen, Enc, Dec) consists of three PPT algorithms. Gen takes λ and outputs a secret key K; Enc takes K and a message d ∈ {0, 1} and outputs a ciphertext c; For all K from Gen and d ∈ {0, 1} we have Dec (K,Enc(K, d)) = d with probability 1. We say \(\mathcal {E}\) is IND-CPA if for all PPT adversary \(\mathcal {A}\),

$$\textbf{Adv}^{ind-cpa}_{\mathcal{E}, \mathcal{A}}(\lambda) = |\text{Pr}[\mathcal{A}^{K \leftarrow \mathtt{Gen}(1^{\lambda}), c \leftarrow \texttt{Enc}(K, d)} = 1] - \text{Pr}[\mathcal{A}^{c \xleftarrow{R} \{0, 1\}^{*}} = 1]| $$

is negligible. A function F : {0, 1}λ × {0, 1} → {0, 1}λ from \(\mathcal {F}\) the set of all functions {0, 1} → {0, 1}λ is pseudo-random if for all PPT adversary \(\mathcal {A}\),

$$\textbf{Adv}^{prf}_{F, \mathcal{A}}(\lambda) = |\text{Pr}[\mathcal{A}^{F(K,.), K \xleftarrow{R} \{0, 1\}^{\lambda}} = 1] - \text{Pr}[\mathcal{A}^{g(.), g \xleftarrow{R} \mathcal{F}} = 1]| $$

is negligible. Detailed treatments of these primitives can be found in [21]. Index tables (or dictionaries) in our discussion denote data structure of the form I[k e y] = v a l u e. Given a key, the value matching the key is returned.

Definition 1

We define a single-server SSE scheme SSE as consisting of the following algorithm and protocols:

  • (K, γ, c) ← Setup (, a u x). It outputs a secret key \(K \xleftarrow {R} \{0, 1\}^{\lambda }\), takes DB and aux, and outputs an encrypted index γ using K, where aux can be an empty set, a document set D and/or a lists of auxiliary information. If aux includes D then Setup encrypts documents in D using \(\mathcal {E}\) and also outputs a set of ciphertexts c. Else c is an empty set.

  • JSearch (K, w, γ). A protocol executed between a user and a server. At the user, the protocol takes as inputs K, a keyword w ∈ {0, 1} and returns a search token. At the server, the protocol takes as inputs the search token and γ, and returns a set of encrypted identifiers, J.

  • σUpdate (K, γ,,). A protocol (for dynamic scheme) executed between a user and a server. At the user, the protocol takes as inputs K, an operation op (e.g. add or delete a document), an input in and outputs results to the server (e.g. encrypted index entry for a newly added document and its ciphertext). At the server, the protocol takes as inputs the results from the user and γ, and outputs a result σ, which contains an updated index γ′ and optionally other information such as a revocation list.

The scheme is said to be correct if Search returns the correct encrypted identifiers that match the documents containing the query keyword w. Under the real-ideal paradigm and a leakage profile \(\mathcal {L}_{\mathtt {SSE}} = (\mathcal {L}_{\mathtt {SSE}}^{setup}, \mathcal {L}_{\mathtt {SSE}}^{query})\) (and \(\mathcal {L}_{\mathtt {SSE}}^{update}\) for dynamic scheme), a SSE scheme is \(\mathcal {L}_{\mathtt {SSE}}\)-secure against adaptive chosen keyword attacks if for all PPT adversary \(\mathcal {A}\), there exists a PPT simulator \(\mathcal {S}\) such that \(\textbf {Adv}_{{\texttt {SSE}},\mathcal {A},\mathcal {S}}(\lambda )=|\text {Pr}[\textbf {Real}_{\mathtt {SSE}, \mathcal {A}}(\lambda ) = 1] - \text {Pr}[\textbf {Ideal}_{\mathtt {SSE}, \mathcal {A}, \mathcal {S}}(\lambda ) = 1| \leq \mathtt {negl}(\lambda )\) where the game is as follows:

\(\textbf {Real}_{\mathtt {SSE}, \mathcal {A}}(\lambda )\).:

\(\mathcal {A}\) gives the challenger and aux (e.g. D). The challenger executes Setup, where the resulting γ (and c) are given to \(\mathcal {A}\). \(\mathcal {A}\) then makes a polynomial number of adaptive queries to the Search protocol, and for dynamic scheme, the Update protocol. For each query the challenger returns the query (and update) result to \(\mathcal {A}\). Finally \(\mathcal {A}\) returns a bit b as the output of the experiment.

\(\textbf {Ideal}_{\mathtt {SSE}, \mathcal {A}, \mathcal {S}}(\lambda )\).:

\(\mathcal {A}\) outputs DB and aux (e.g. D). The simulator \(\mathcal {S}\) simulates γ (and c) based on the leakage information from \(\mathcal {L}_{\mathtt {SSE}}^{setup}\) on index, and gives γ (and c) to \(\mathcal {A}\), who then makes a polynomial number of adaptive queries. The simulator \(\mathcal {S}\) returns the query result for every query (and update result) based on \(\mathcal {L}_{\mathtt {SSE}}^{query}\) (and \(\mathcal {L}_{\mathtt {SSE}}^{update}\)) to \(\mathcal {A}\). Finally \(\mathcal {A}\) returns a bit b as the output of the experiment.

We note that security against non-adaptive chosen keyword attacks can be defined in a similar way, except that \(\mathcal {A}\) must prepare all queries beforehand. In summary, the security intuition of a SSE scheme is such that nothing is leaked except for the outputs and the patterns of a sequence of queries [7, 10]. For the outputs, \(\mathcal {L}_{\mathtt {SSE}}^{setup}\) measures leakage of information stored on the server, which includes the list of encrypted items \(\textbf {c} = (\mathcal {E}(\delta _{1}), \ldots , \mathcal {E}(\delta _{m}))\), list of identifiers of the items \((id_{\delta _{1}}, \ldots , id_{\delta _{m}})\), items’ sizes (|δ 1|, … , |δ m |), \(m \in \mathbb {N}\), and the index γ. As for leakage on search, after q queries, \(\mathcal {L}_{\mathtt {SSE}}^{query}\) returns the search results ((w 1), … , (w q )), the search pattern SP (w q ) measuring whether a query is repeated, and the intersection pattern IP (w q ) measuring whether a same item is accessed. \(\mathcal {L}_{\mathtt {SSE}}^{update}\) measures leakage during updates where it gives \(\mathcal {E}(\delta _{u})\), the item size |δ u |, and an updated index table γ′, where δ u is the item added/deleted. Here δ i may represent a document D f or a block of a document d i, f .

4 ms-SSE

We now extend SSE to one that works over multiple servers, ms-SSE. A straightforward approach is to deploy an existing SSE scheme directly to cater for s servers by first grouping the set of documents into s (disjoint) subsets. Each of the encrypted subsets and metadata are sent to the respective servers. In other words, we independently run s rounds of a SSE scheme to outsource the subsets of documents to their selected servers. To search, we create a query and broadcast it to all the servers to retrieve the matching documents. The benefit is that a non-colluding server does not have information on other encrypted documents not stored in it and obviously does not know the total number of documents. In case of statistical analysis or ciphertext cryptanalysis, the server only learns the content of the documents it holds. However this information is revealed if the servers collude. Regardless of whether the servers collude or not, the subset of the encrypted documents is in the possession of the server. Also, for each document, the document size is known.

Alternatively, we can do this in a way that a server does not hold a complete document even in the encrypted form, so that only partial information of a document is revealed, potentially through statistical analysis on the leakages or successful cryptanalysis on the encrypted documents, provided servers do not collude. This approach can be utilised to also hide the document sizes, total number of documents and probabilistically hide pairs of matching tokens and documents. The idea is to work on blocks of a document instead, and randomly distributing the blocks to different servers.

We shall construct schemes based on these two approaches. The scheme using the straightforward approach demonstrates the scalability of existing single server schemes, whereas the scheme using the second approach offers smaller leakage.

Definition 2

A multi-server SSE scheme (ms-SSE) consists of:

  • (K, I, c) ← mSetup (DB, D, S): A probabilistic algorithm that takes DB, a set of documents D and a list of servers S, to output a list of secret keys K, where each key is randomly chosen from {0, 1}λ, a set of encrypted index tables I and a sequence of encrypted data c.

  • J w := mSearch (K, w, I, S): A protocol executed between a user and a set of servers. At the user, where on input K, a query word w and S, the protocol outputs a set of tokens (or keys). At the servers, using these tokens (or keys) and I as inputs, the protocol outputs a set of identifiers J w.

  • σ := mUpdate (K,op,in, I, S): A protocol (for dynamic scheme) executed between a user and a set of servers. At the user, where on input K, a tuple (op, in), and S, the protocol outputs results to the servers (e.g. encrypted index entry for a newly added document and its ciphertext), where op ∈ {Doc+,Doc-}. At the servers, given the inputs from the user and I, the protocol outputs σ. For Doc+, σ = (I′, c u ) and optionally other information, where I′ is a set of updated indexes and c u denotes the set of ciphertexts of the added documents. For Doc-, σ = I′, and also possibly other information.

We say that ms-SSE is correct if for all λ, for all DB, for all D, for all S, for all (K, I, c) ← mSetup (DB, D, S), for all σmUpdate (K, op, in, I, S), mSearch (K, w, I, S) returns the set of identifiers J w such that the set of decrypted documents have their identifiers in DB (w).

Note that unlike the case of SSE, a list of servers S is required as input to mSetup in addition to DB. We also set D in place of aux, where mSetup processes D into structures that allow for distributions to many servers. mUpdate may further include adding a new server Svr+ and removing an existing server Svr-, which require new processes and cannot rely on existing update protocol of SSE. We shall briefly discuss how Svr+ and Svr- can be performed in the later section.

In the ms-SSE, the leakage function is defined per server and written as \(\mathcal {L}_{\texttt {ms-SSE}}=\left (\mathcal {L}_{\texttt {ms-SSE},S_{j}}^{setup}, \mathcal {L}_{\texttt { ms-SSE},S_{j}}^{query}, \mathcal {L}_{\texttt {ms-SSE},S_{j}}^{update}\right )_{S_{j}\in \mathbf {S}}\). Accordingly, the adversary’s power is differentiated by whether the adversary controls one server or controls multiple servers. We call the adversary who controls exactly one server as non-colluding server, and an adversary who controls more than one server as colluding server. This is reflected in the \(\mathcal {L}\)-security Real ms-SSE and Ideal ms-SSE in which the adversary receives query responses for only the servers under its control. Hence the security model for ms-SSE as follows.

Definition 3

For ms-SSE parameterised by security parameter λ and leakage functions \(\mathcal {L}_{\texttt { ms-SSE}}\) = \(\left (\mathcal {L}_{\texttt {ms-SSE},S_{j}}^{setup}, \mathcal {L}_{\texttt { ms-SSE},S_{j}}^{query}\right )_{S_{j}\in \mathbf {S}}\) (and \(\mathcal {L}_{\texttt {ms-SSE},S_{j}}^{update}\) for dynamic scheme), and \(\mathcal {S}\) a simulator, an adversary \(\mathcal {A}\) who controls a set of servers S′ ⊆ S play the following game with the challenger. The challenger randomly choose to play the Real ms-SSE or Ideal ms-SSE game, and sends the list of servers S to \(\mathcal {A}\).

\(\textbf {Real}_{\texttt {ms-SSE}, \mathcal {A}}(\lambda )\).:

In receiving S from the challenger, \(\mathcal {A}\) generates a set of documents D and a database index DB. \(\mathcal {A}\) gives the challenger (DB, D, S′). The challenger executes mSetup resulting in (K, I, c) where K is a set of secret keys, \(\mathbf {I} = \{\gamma _{S_{j}}\}\), \(\textbf {c} = \{\textbf {c}_{S_{j}}\}\) for all S j S. The challenger returns to \(\mathcal {A}\) (I′, c′) where \(\mathbf {I}^{\prime } = \{\gamma _{S_{j}}\}\) and \(\textbf {c}^{\prime } = \{\textbf {c}_{S_{j}}\}\) for all S j S′. Then \(\mathcal {A}\) makes a polynomial number of adaptive queries. For search queries of keyword w, the output of mSearch (K, w, I, S) for every S j S′, \(\mathbf {J}^{w}_{S_{j}}\), is returned to \(\mathcal {A}\). For dynamic ms-SSE, the update queries for document addition or removal is replied with output of mUpdate (K, op, in, I, S) for every S j S′,the updated \((\gamma _{S_{j}}\), c \(_{S_{j}})\). Finally \(\mathcal {A}\) returns a bit b as the output of the experiment.

\(\textbf {Ideal}_{\texttt {ms-SSE}, \mathcal {A}, \mathcal {S}}(\lambda )\).:

In receiving S from the challenger, \(\mathcal {A}\) generates a set of documents D and a database index DB and submits (DB, D, S′) to the challenger. The challenger then sends \(\mathcal {L}_{\texttt { ms-SSE},S_{j}}^{setup}(\texttt {DB}, \mathbf {D}, \mathbf {S}^{\prime })\) for S j S′ to the simulator \(\mathcal {S}\). Then \(\mathcal {S}\) produces (I′, c′) where \(\mathbf {I}^{\prime } = \{\gamma _{S_{j}}\}\) and \(\textbf {c}^{\prime } = \{\textbf {c}_{S_{j}}\}\) for all S j S′ and this is returned to \(\mathcal {A}\). After that, \(\mathcal {A}\) makes polynomial number of adaptive queries for each of which \(\mathcal {S}\) is given \(\mathcal {L}_{\texttt {ms-SSE},S_{j}}^{query}(q_{i})\) or \(\mathcal {L}_{\texttt {ms-SSE},S_{j}}^{update}(q_{i})\) for all S j S′. Outputs of \(\mathcal {S}\) is given to \(\mathcal {A}\) after each query. Finally \(\mathcal {A}\) returns a bit b as the output of the experiment.

We define the advantage of the adversary as

$$\textbf{Adv}_{{\texttt{ms-SSE}},\mathcal{A},\mathcal{S}}(\lambda)=|\text{Pr}[\textbf{Real}_{\texttt{ ms-SSE}, \mathcal{A}}(\lambda) = 1] - \text{Pr}[\textbf{Ideal}_{\texttt{ms-SSE}, \mathcal{A}, \mathcal{S}}(\lambda) = 1|.$$

We say that ms-SSE is \(\mathcal {L}_{\texttt {ms-SSE}}\)-secure against adaptive chosen keyword attacks by colluding servers if for all PPT adversaries \(\mathcal {A}\), there exists a PPT simulator \(\mathcal {S}\) such that

$$\textbf{Adv}_{{\texttt{ms-SSE}},\mathcal{A},\mathcal{S}}(\lambda) \leq \texttt{negl}(\lambda).$$

The above definitions can also be seen as a generalisation of SSE to multiple servers, in which we define ms-SSE for single server by setting S to one server, D to an empty set, or the set of documents and/or any other auxiliary information.

Security-wise we argue that an ms-SSE scheme is at least as secure as an SSE scheme. Consider \(\mathcal {A}\) who controls all servers S j S. Then \(\mathcal {A}\) has access to the whole of (\(\mathbf {I}_{S_{j}},\mathbf {c}_{S_{j}}\))\(_{S_{j}\in \mathbf {S}}\). Suppose that the token keys and encryption keys for all servers are equal. This allows \(\mathcal {A}\) to consolidate (\(\mathbf {I}_{S_{j}}\))\(_{S_{j}\in \mathbf {S}}\) to form one index table I. Similarly, \(\mathcal {A}\) can consolidate all responses to the queries. Consequently, \(\mathcal {A}\) has the same information as an adversary of the corresponding SSE scheme, and hence gain equal advantage. However, if \(\mathcal {A}\) controls only S′ ⊂ S, the consolidated index table and query results are not complete. Additionally, the ms-SSE scheme uses different keys for each server which implies \(\mathcal {A}\) has insignificant probability to correctly consolidate the index table or query results. Therefore, \(\mathcal {A}\) has less information and hence less advantage than a single server SSE adversary.

5 ms-SSE G : a generic construction

In this construction, ms-SSE G , our intuition is to design steps in the Setup algorithm that prepare documents so that one may deploy existing SSE for multiple servers with minimal modification. The general idea is to divide the set of documents into subsets of documents in such a way that an existing single keyword scheme can be used directly for index creations, queries, and updates for each subset of documents. It mirrors the straightforward approach discussed in Section 4. Figure 1 describes the construction.

Fig. 1
figure 1

ms-SSE G – A generic construction

We define mSetup as an algorithm that divides D into s subsets \(\mathbf {D}_{S_{j}}\), and build the keyword index DB \(_{S_{j}}\). Based on the number of servers s, and given the tuple (\(\mathbf {D}_{S_{j}}\), DB \(_{S_{j}}\)), it runs SSE.Setup as if creating an index for each single server S j . Similar concept applies to mSearch and mUpdate. In mSearch, the search token is broadcast to all servers in order to retrieve document identifiers that match the search token. As for mUpdate, a server is randomly selected to update a document, or a document identifier is broadcast to remove the document. ms-SSE G can be setup based on existing schemes, such as using [5, 7, 28]. In brief, we replace the generic functions (e.g. SSE.Setup) with similar functions in the existing schemes. For example, using Cash et al.’s \(\mathrm {\Pi }^{dyn}_{bas}\) [5, Section 4], we can construct a multiserver scheme by mapping SSE.Setup to \(\mathrm {\Pi }^{dyn}_{bas}\)’s setup function and the underlying document encryption process, SSE.Search to the search function and SSE.Update to the update function, also coupled with the encryption process if the operation is to add a document.

Leakage, \(\mathcal {L}_{\texttt {ms-SSE}}\). Leakage is straightforward when servers do not collude.Footnote 1 It consists of the leakage of the underlying SSE scheme since a server only sees what is stored and the outputs generated from the SSE scheme. Nevertheless stored items and outputs are restricted to the subset of documents. In contrast, colluding servers learn the total number of documents by summing the number of encrypted documents stored in each server, since we divide D into s subsets \(\mathbf {D}_{S_{j}}\). They also learn the total index size, in addition to the leakage of each of the server. During search and update query, these servers collectively learn the search and update results of one another and no other information is leaked except which server is holding which documents. If we consider these servers as partitions of the storage of a single server then the leakage is equivalent to that of a SSE scheme. So for colluding servers, \(\mathcal {L}_{\texttt {ms-SSE}} = (n, \{|\gamma _{S_{j}}|, \mathcal {L}_{\texttt {SSE}} \text { for } S_{j} \vert j=1, \ldots , s\})\).

Theorem 1

Let ms-SSE G and \(\mathcal {L}_{\texttt {ms-SSE}}\) be as defined above. Suppose SSE is \(\mathcal {L}_{\texttt {SSE}}\) -secure against adaptive chosen keyword attack. Then, ms-SSE G is \(\mathcal {L}_{\texttt {ms-SSE}}\) -secure against adaptive attack by colluding servers.

Proof

This proof uses the game hopping strategy beginning with the single server \(\mathcal {L}_{\texttt {SSE}}\)-security game, followed by \(\mathcal {L}_{\texttt {ms-SSE}}\) security game for non-colluding server and finally the game for colluding server. Here, P r[G a m e i ] denotes the probability of the adversary winning G a m e i .

G a m e 0::

This game is exactly the \(\mathcal {L}_{\texttt {SSE}}\)-security game on SSE. Since we assume SSE is \(\mathcal {L}_{\texttt {SSE}}\)-secure, for any PPT adversary \(\mathcal {A}\) there exists a simulator \(\mathcal {S}^{\text {single}}\) such that Adv \(_{\texttt { SSE},\mathcal {A},\mathcal {S}^{\text {single}}}(\lambda )\leq \texttt {negl}(\lambda )\). So,

$$Pr\left[\mathsf{Game_{0}}\right] = {\mathbf{Adv}_{\texttt{SSE},\mathcal{A},\mathcal{S}^{\text{single}}}}(\lambda). $$
G a m e 1::

This is the \(\mathcal {L}_{\texttt {ms-SSE}}\) security game where the adversary \(\mathcal {B}_{1}\) controls one of the s servers, S b S. At the beginning of the game, \(\mathcal {B}_{1}\) submits a set of n documents, D. Let server S b be assigned with subset \(\mathbf {D}_{S_{b}}\) containing n b < n documents. Then the challenger sends to the simulator leakages of S b , which is related to index, ciphertext and search results for \(\mathbf {D}_{S_{b}}\) only.

Although the leakage is less than in the single server game, from the simulator’s perspective the leakage is from a set of document, which is the same view as in the single server game. The difference in a multiserver setting is the fact that the keywords set is not disjoint and may be equal for all servers. This affects the index keys and the search token. However, in this scheme, every server executes an independent instance of SSE including generating and using different keys. As a result, the index keys or search tokens of a keyword are different for different servers, and hence the index tables for the servers are disjoint. Outputs for search queries from different servers are independent because they search disjoint set of documents. It follows that, the simulated index table and search results for S b can be constructed fully based on the leakages and does not need any information about outputs of other servers. Hence, the simulator \(\mathcal {S}^{\text {single}}\) can be used in this game to simulate outputs for S b with indistinguishable distribution from outputs of ms-SSE G .

Since \(\mathcal {B}_{1}\) obtain outputs related to \(\mathbf {D}_{S_{b}} \subset \mathbf {D}\) only, he has less information than \(\mathcal {A}\) in \(\mathcal {L}_{\texttt {SSE}}\)-security game. Hence,

$$Pr\left[\mathsf{Game_{1}}\right] < Pr\left[\mathsf{Game_{0}}\right]. $$
G a m e 2::

This is the \(\mathcal {L}_{\texttt {ms-SSE}}\) security game where the adversary \(\mathcal {B}_{2}\) controls a set of servers S′ ⊆ S of its choice. Let S′ = {S 1, … , S t } where ts. Since the instances of SSE for the servers are independent, the simulator \(\mathcal {S}^{\text {multi}}\) is a collection of SSE simulators \(\left \lbrace \mathcal {S}^{\smash {\text {single}}}_{1},\ldots ,\mathcal {S}^{\smash {\text {single}}}_{t} \right \rbrace \) taking as inputs the leakages for the respective servers. Here \(\mathcal {B}_{2}\) obtains outputs related to t subsets of documents, which is more than that obtained by \(\mathcal {B}_{1}\) in G a m e 1. The adversary \(\mathcal {B}_{2}\) would gain the same amount of information from the challenger as \(\mathcal {A}\) in G a m e 0 if it controls all servers, S′ = S. By the independence of SSE instances on every server, we have that

$$Pr\left[\mathsf{Game_{2}}\right]=\sum\limits_{i=1}^{t}{Pr\left[\mathsf{Game_{1}}\right]}\leq Pr\left[\mathsf{Game_{0}}\right]. $$

Hence,

$${\mathbf{Adv}_{\texttt{ ms-SSE},\mathcal{B}_{2},\mathcal{S}^{\text{multi}}}}(\lambda)=Pr\left[\mathsf{Game_{2}}\right] \leq {\mathbf{Adv}_{\texttt{SSE},\mathcal{A},\mathcal{S}^{\text{single}}}}(\lambda) \leq \texttt{negl}(\lambda). $$

Therefore, ms-SSE G is \(\mathcal {L}_{\texttt {ms-SSE}}\)-secure against adaptive attack by colluding servers. □

6 ms-SSE M : a construction with smaller leakage

The previous scheme, ms-SSE G , leaks the size and the total number of documents when servers collude. Even if the servers do not collude, the server learns content of the stored documents in the event of successful statistical analysis or key leaks. In order to address these limitations, we propose a scheme based on similar index structures proposed in [5, 7]. We first give a static scheme and then extend it to a dynamic one. The general idea is to divide documents into blocks, encrypt these blocks, distribute the blocks randomly to the servers. A masked index table \(\gamma _{S_{j}}\) is also created for every server S j , which stores the linkage between the blocks and the servers. Then through the masked index tables a user queries for documents. Figure 2 provides details of the construction.

Fig. 2
figure 2

ms-SSE M – A construction with smaller leakage

In brief, there is a two part process in the setup phase (mSetup). The first is to randomly assign blocks of documents to the list of servers. Given a set of documents, the scheme generates a master key, k. This master key is then used to generate a set of server keys \(K_{S_{j}}\) for all servers listed in the servers’ list S. Next, each document D f in D is divided into a set of blocks, in which the number of blocks of D f is denoted as h f . Once this is done, each block of D f is randomly assigned to a server S j . The assignment is held by a temporary index T, in the form of a tuple of the document identifier \(id_{D_{f}}\), the block identifier \(id_{d_{f,i}}\), and the server identifier, \(id_{S_{j}}\). Such a tuple effectively creates a “pointer” linking a block to the server that will eventually store the ciphertext of this block.

The second process is to encrypt blocks of documents, and to create masked indexes that link the keywords of the documents to the tuple in T in encrypted form, thus producing searchable encrypted indexes. This is realised by first creating a set of empty index tables I and list c that will be used to hold the indexes and ciphertexts. The index \(\gamma _{S_{j}} \in \mathbf {I}\) for server S j has a \(\gamma _{S_{j}}[key] = value\) structure. The steps to generate \(\gamma _{S_{j}}\) are as follows. For a keyword w q , a search token key, K t o k , and an identifier encryption key, K e i d , are created using F with the master key k and w q as input. A list of empty vectors \(\{\mathbf {t}_{S_{1}}, \ldots , \mathbf {t}_{S_{s}}\}\) are also created. \(\mathbf {t}_{S_{j}}\) is used to temporarily hold encrypted index entries of T for server S j until all entries in T have been processed. Entries in \(\mathbf {t}_{S_{j}}\) serve as the value in \(\gamma _{S_{j}}\). Next, search tokens, l q, j , for w q are generated for every server S j through F with K t o k and the identifier of S j as input. The search token serves as the key in \(\gamma _{S_{j}}\). After that, for every document that contain w q , which is identified based on the keyword index DB, each block of the document is encrypted using the server key \(K_{S_{j}}\) of server S j that will eventually store the encrypted block. The selection of server key is done by referring to the entry \(T[id_{D_{f}}, i]\), where i refers to block i. After this the entry \(T[id_{D_{f}}, i]\) is encrypted using K e i d . The encrypted entry \(p_{d_{f,i}}\) is randomly assigned to a server S j , and appended to the vector \(\mathbf {t}_{S_{j}}\). Once all documents containing w q has been processed, the scheme sets \(\gamma _{S_{j}}[l_{q,j}] = \textbf {t}_{S_{j}}\). The above process is repeated for all keywords in W.

Given \(\gamma _{S_{j}}[l_{q,j}] = \textbf {t}_{S_{j}}\), to search (mSearch), a user supplies l q, j , generated using the master key k, w q and the server identifier \(id_{S_{j}}\). Each server S j returns the respective list of encrypted indexes p w, j (\(\mathbf {t}_{S_{j}}\)) if there is a match.

We note that random selections of servers (\(j \xleftarrow {\smash {R}} [s]\)) during block assignments in index table T determine where each of the encrypted blocks is to be stored, while random selections during index creation chooses which index table \(\gamma _{S_{j}}\) the linkages are kept. It means a server i might, in its index, store an entry of a (bD f j) linkage, in which block b is in fact at server j instead of server i. This allows us to decouple the mapping between some of the entries in the index and the actual stored blocks. It prevents a server from learning the group of encrypted identifiers that matches the group of stored blocks during search, where the number of returned identifiers can be more/less than the actual blocks to be retrieved. However, this does allow a server to learn, if any, the number of blocks not stored in it, or the excess of stored blocks based on the differences between the number of encrypted identifiers in \(\gamma _{S_{j}}\) and the number of actual stored blocks. Nevertheless, we may pad the identifiers/blocks to hide this information if necessary.

Leakage, \(\mathcal {L}_{\texttt {ms-SSE}}\)

If servers do not collude, a server S j possesses only the stored blocks, while \(\gamma _{S_{j}}\) reveals the number of keywords, |W|, the number of block identifiers per keyword, |p q, j |, and the total number of block identifiers \(P_{j} = \mathrm {\Sigma }_{q=1}^{\smash {|\scriptsize {\textbf {W}}|}}|\textbf {p}_{q,j}|\) in the server. In addition the server learns the differences (if any) between the number of identifiers and the number of stored blocks, which we denote as Δ. This means \(\mathcal {L}^{setup}_{\texttt {ms-SSE}}\) = (|W|, P j ,|p q, j |,Δ). When a query is submitted, a server S j learns |p q, j | for a query w q , and also the search pattern SP\(_{S_{j}}(w_{q})\) by recording the number of times an identical keyword is queried. The server S j also learns the intersection patterns IP\(_{S_{j}}(w_{q})\) where the same block identifiers are submitted during retrieval of blocks when different keywords are queried. This means \(\mathcal {L}^{query}_{\texttt {ms-SSE}}\) = (|p q, j |, \(\text {SP}_{S_{j}}(w_{q})\), \(\text {IP}_{S_{j}}(w_{q}))\).

In the case where servers collude, the servers learn leakages of one another in addition to the single server leakage of \(\gamma _{S_{j}}\). This means leakages of the total number of block identifiers \(\mathrm {\Sigma }_{j=1}^{s} P_{j}\) based on \(\gamma _{S_{j}}\) for all j. However since keywords are differentiated as \(F(K_{tok},id_{S_{j}})\) for different server S j , the servers will not be able to combine the encrypted block identifiers to link to the same keyword, until a keyword is queried. In summary, leakge for non-colluding server is \(\mathcal {L}^{setup}_{\texttt { ms-SSE}}\) = (|W|,{(P j ,|p q, j |,Δ)|j = 1, … , s}) and the leakage for colluding servers is \(\mathcal {L}^{query}_{\texttt {ms-SSE}}\) = ({(|p q, j |, \(\text {SP}_{S_{j}}(w_{q})\), \(\text {IP}_{S_{j}}(w_{q})) \vert j=1,\ldots , s\})\).

Theorem 2

Let ms-SSE M and \(\mathcal {L}_{\texttt {ms-SSE}}\) = \((\mathcal {L}^{setup}_{\texttt {ms-SSE}},\mathcal {L}^{query}_{\texttt {ms-SSE}})_{S_{j}\in \mathbf {S}}\) be as defined above. Suppose F is a secure pseudorandom function and \(\mathcal {E}\) is an IND-CPA symmetric encryption scheme. Then ms-SSE M is \(\mathcal {L}_{\texttt {ms-SSE}}\) -secure against adaptive attack by colluding server.

Proof

In ms-SSE M independent key sets are used for different servers which means related information has been rendered independent as it is distributed to different servers. This allows for independent simulators for each server to produce the required outputs in the colluding servers attack. Thus, this proof begins by defining a simulator for one of the servers (under non-colluding server attack) and shows that its output is indistinguishable from the output of ms-SSE. Finally, multiple instances of this simulator form the simulator for the colluding server attack.

First, we define a simulator \(\mathcal {S}^{\text {single}}\) for non-colluding server, \(\mathcal {B}\), attack with server controlled by \(\mathcal {B}\) being S b .

For input \(\mathcal {L}^{setup}_{\texttt {ms-SSE}}= (|\textbf {W}|, P_{b}, |\textbf {p}_{q,b}|, \Delta )\) \(\mathcal {S}^{\text {single}}\) produces \((\gamma _{b}^{\prime },\mathbf {c}_{b}^{\prime })\):

  • Generate index \(\gamma _{b}^{\prime }\) by first generating an encryption key \(k_{b}^{\prime }\leftarrow \mathcal {E}.\mathtt {Gen}(1^{\lambda })\). Then for each q ∈ [|W|], generate random strings \(r_{q,0}\xleftarrow {\smash {R}} \{0, 1\}^{\lambda }\), and R \(_{q}=\{r_{q,i}\xleftarrow {\smash {R}} \{0, 1\}^{3(\lambda )} \vert i\in [|\textbf {p}_{q,b}|]\}\). Then set \(\gamma _{j}^{\prime }[r_{q,0}]=\left \lbrace \mathcal {E}.\texttt {Enc}(k^{\prime },r_{i})\,\vert \,r_{i}\in \textbf {R}_{q} \right \rbrace \).

  • Generate ciphertexts by generating an encryption key \(k_{eid}^{\prime }\leftarrow \mathcal {E}.\mathtt {Gen}(1^{\lambda })\) and generating |p q, b | + Δ random binary strings, \(r_{i} \xleftarrow {\smash {R}} \{0, 1\}^{\phi (\lambda )+\log _{2} l}\).

  • Then compute c \(_{b}^{\prime }= \left \lbrace \mathcal {E}.\texttt {Enc}\left (k_{eid}^{\prime },r_{i}\right )\,\vert \, i\in [|\textbf {p}_{q,b}|+\Delta ]\right \rbrace \).

For input \(\mathcal {L}^{query}_{\texttt {ms-SSE}} = (|\textbf {p}_{q,b}|\), \(\text {SP}_{S_{b}}(w_{q})\), \(\text {IP}_{S_{b}}(w_{q}))\) \(\mathcal {S}^{\text {single}}\) produces query results which consists of set of block identifier ciphertexts, \(\mathbf {J}_{b}^{\prime }\), and a set of block ciphertexts, \(C_{b}^{\prime }\) which the user retrieves:

  • Prepare \(\mathbf {J}_{b}^{\prime }\) by first referring to \(\text {SP}_{S_{b}}(w_{q})\) to determine whether the query has been made previously. If so, set \(\mathbf {J}_{b}^{\prime }\) with the same list as before. Otherwise, choose an unused entry in \(\gamma _{b}^{\prime }\) containing a list of |p q, b | items, and set \(\mathbf {J}_{b}^{\prime }\) as the list.

  • Prepare \(C_{b}^{\prime }\) by again referring to \(\text {SP}_{S_{b}}(w_{q})\) to determine whether the query has been made previously. If so, set \(C_{b}^{\prime }\) with the same set as before. Otherwise, prepare a new set. Refer \(\text {IP}_{S_{b}}(w_{q})\) to determine ciphertexts in this query which has been returned as results in previous queries. If there is any, include the same ciphertexts in \(C_{b}^{\prime }\). Lastly, include in \(C_{b}^{\prime }\) unused ciphertexts from c \(_{b}^{\prime }\) until \(|C_{b}^{\prime }|\) equals the number of block identifiers submitted for retrieval.

G a m e 0::

This is the Real \(_{\texttt {ms-SSE},\mathcal {B}}(\lambda )\) game with the adversary \(\mathcal {B}\) controlling one server, S b . So, \(Pr\left [\mathsf {Game_{0}}\right ] = Pr\left [\mathbf {Real}_{\texttt {ms-SSE},\mathcal {B}}(\lambda )=1\right ]\).

G a m e 1::

This game is G a m e 0 with F(k,⋅) and F(K t o k ,⋅) in the mSetup replaced by independent random functions. Let where \(\mathcal {B}_{1}\) be the adversary of the pseudorandom function.Then, we have that

$$Pr\left[\mathsf{Game_{1}}\right]-Pr\left[\mathsf{Game_{0}}\right] \leq 2\mathbf{Adv}^{prf}_{F,\mathcal{B}_{1}}(\lambda). $$
G a m e 2::

This game is G a m e 1 with the encryption algorithm \(\mathcal {E}.\mathtt {Enc}(K_{S_{b}},r_{1})\) and \(\mathcal {E}.\mathtt {Enc}(K_{eid},r_{2})\) in Step 7 where r 1 and r 2 are random strings instead of the document block d f, i i and the identifiers \(id_{D_{f}}\Vert id_{d_{f},i}\Vert id_{S_{b}}\). Let \(\mathcal {B}_{2}\) be the IND-CPA adversary of \(\mathcal {E}\). We have that

$$Pr\left[\mathsf{Game_{2}}\right]-Pr\left[\mathsf{Game_{1}}\right] \leq 2\mathbf{Adv}^{ind-cpa}_{\mathcal{E},\mathcal{B}_{2}}(\lambda). $$
G a m e 3::

This is the Ideal \(_{\texttt { ms-SSE},\mathcal {B},\mathcal {S}^{\text {single}}}(\lambda )\) with the simulator \(\mathcal {S}^{\text {single}}\) as defined earlier. Clearly, this game is equivalent to G a m e 2. Hence,

$$Pr\left[\mathbf{Ideal}_{\texttt{ ms-SSE},\mathcal{B},\mathcal{S}^{\text{single}}}(\lambda)\right]=Pr\left[\mathsf{Game_{3}}\right]=Pr\left[\mathsf{Game_{2}}\right]. $$

From G a m e 0 to G a m e 3 we have that

$$\begin{array}{@{}rcl@{}} \lefteqn{Pr\left[\mathbf{Ideal}_{\texttt{ms-SSE},\mathcal{B},\mathcal{S}^{\text{single}}}(\lambda)=1\right]}\\ &=&Pr\left[\mathsf{Game_{2}}\right]\\ &\leq& \mathbf{Adv}^{ind-cpa}_{\mathcal{E},\mathcal{B}_{2}}(\lambda)+Pr\left[\mathsf{Game_{1}}\right]\\ &\leq& \mathbf{Adv}^{ind-cpa}_{\mathcal{E},\mathcal{B}_{2}}(\lambda)+\mathbf{Adv}^{prf}_{F,\mathcal{B}_{1}}(\lambda)+Pr\left[\mathsf{Game_{0}}\right]\\ &\leq& \mathbf{Adv}^{ind-cpa}_{\mathcal{E},\mathcal{B}_{2}}(\lambda)+\mathbf{Adv}^{prf}_{F,\mathcal{B}_{1}}(\lambda)+Pr\left[\mathbf{Real}_{\texttt{ms-SSE},\mathcal{B}}(\lambda)=1\right]. \end{array} $$

It follows that,

$$\textbf{Adv}_{{\texttt{ms-SSE}},\mathcal{B},\mathcal{S}^{\text{single}}}(\lambda) \leq \mathbf{Adv}^{prf}_{F,\mathcal{B}_{1}}(\lambda)+\mathbf{Adv}^{ind-cpa}_{\mathcal{E},\mathcal{B}_{2}}(\lambda). $$

By our assumptions, the right hand side of the inequality is negl (λ). Therefore, we conclude that ms-SSE is \(\mathcal {L}_{\texttt {ms-SSE}_{M}}\)-secure against adaptive attack by non-colluding server.

Finally, consider an adversary \(\mathcal {A}\) which controls a set of servers, S′ ⊆ S. Let S′ = {S 1, … , S t } where ts. For adversary \(\mathcal {A}\) consider a simulator \(\mathcal {S}^{\text {multi}}\) for the Ideal ms-SSE game which is a collection of t instances of the single server simulator, \(\left \lbrace \mathcal {S}^{\smash {\text {single}}}_{1},\ldots ,\mathcal {S}^{\smash {\text {single}}}_{t} \right \rbrace \). Each simulator acts on the given leakages independently. During the game, inputs \(\mathcal {L}^{setup}_{\texttt {ms-SSE}}\) = (|W|,{(P j ,|p q, j |,Δ)|j = 1, … , s}) and \(\mathcal {L}^{query}_{\texttt {ms-SSE}}\) = ({(|p q, j |, \(\text {SP}_{S_{j}}(w_{q})\), \(\text {IP}_{S_{j}}(w_{q})) \vert j=1,\ldots , s\})\) to \(\mathcal {S}^{\text {multi}}\) are distributed accordingly. In particular, for j = 1, … , t, the leakage (|W|,{(P j ,|p q, j |,Δ) and ({(|p q, j |, \(\text {SP}_{S_{j}}(w_{q})\), \(\text {IP}_{S_{j}}(w_{q}))\) is passed to \(\mathcal {S}^{\text {single}}_{j}\).

Due to the independent server keys in ms-SSE M and, the secure primitives \(\mathcal {E}\) and F, outputs of each storage servers is disjoint. Hence, the collection of independent outputs by \(\mathcal {S}^{\text {multi}}\) matches the distribution of ms-SSE M outputs. Since we define \(\mathcal {S}^{\text {multi}}\) to consists of simulators which work independently on their respective inputs, we have that

$$\textbf{Adv}_{{\texttt{SSE}},\mathcal{A},\mathcal{S}^{\text{multi}}}(\lambda) \leq s\left( \mathbf{Adv}^{prf}_{F,\mathcal{B}_{1}}(\lambda)+\mathbf{Adv}^{ind-cpa}_{\mathcal{E},\mathcal{B}_{2}}(\lambda)\right) $$

with equality achieved when \(\mathcal {A}\) controls all s servers. Since the right hand side of the inequality is negligible by our assumptions, we conclude that ms-SSE M is \(\mathcal {L}_{\texttt {ms-SSE}_{M}}\)-secure against adaptive attack by colluding servers. □

If only a static scheme is required, then instead of encrypting every entry in T separately (required for efficient index updates), we could encrypt the whole list T[i d f ] for D f . This prevents leakage on the number of blocks per keyword and the total number of blocks.

6.1 Extension to a dynamic construction

We propose a dynamic construction ms-SSE \(^{dyn}_{M}\) that supports addition and deletion of documents. We first discuss the modification of mSetup as shown in Fig. 3 to accommodate document removals since the existing index structure does not provide for efficient extraction of blocks. Our approach is to treat document identifiers \(id_{D_{f}}\) as keywords and create entries for them in \(\gamma _{S_{j}}\) through identifier-based keys \(F(k, 1||id_{D_{f}})\) and \(F(k, 2||id_{D_{f}})\). Using the keys, we add an entry to a randomly selected \(\gamma _{S_{j}}\), encrypt the complete list of elements in T for \(id_{D_{f}}\) and then divide the list into blocks of length equal to \(|p_{d_{f,i}}|\). Encryption of the whole list prevents leakage on the number of blocks in a document. By treating the identifiers as keywords, dividing the encrypted list into blocks and permuting the entries in \(\gamma _{S_{j}}\), we ensure a server cannot differentiate between entries of keywords and document identifiers. If the entry has a much smaller number of blocks compared to the average number of blocks for other entries then dummy blocks can be included.

Fig. 3
figure 3

ms-SSE \(^{dyn}_{M}\) – Modification to mSetup in ms-SSE M

For adding a document, Doc+ (Fig. 4), the approach proposed in [5] is adapted. We initialise a list of frequency counters on every keyword of the document \(cnt_{w_{q}}\), which forms part of the input to the token entry in \(\gamma _{S_{j}}\). So instead of producing a token entry \(l_{q,j} \leftarrow F(K_{tok},id_{S_{j}})\) for \(\gamma _{S_{j}}\) (Step 7 of mSetup, Fig. 2), we produce \(l_{q,j} \leftarrow F(K_{tok},id_{S_{j}}|| cnt_{w_{q}})\), where \(cnt_{w_{q}}\) is incremented each time w q is processed for a new document. This is so that addition does not cause leakage before queries as some documents may share identical keywords.

Fig. 4
figure 4

ms-SSE \(^{dyn}_{M}\) – Adding a new document

For removing a document, Doc- (Fig. 5), the idea is to query the servers through document identifier tokens that have been indexed during mSetup and Doc+ as described earlier. Our scheme removes the actual encrypted blocks and the identifier entries in the index. We do not update the keyword/block pair indexes in \(\gamma _{S_{j}}\) but a deletion strategy similar to that of [28] can be adopted, in which when the searched encrypted blocks cannot be found, their entries in \(\gamma _{S_{j}}\) can be deleted. Also, communication bandwidth can be saved if it is possible for the user to store an index table on document identifier and server location so that the user only sends K t o k to the particular server that holds the index for \(id_{D_{x}}\).

Fig. 5
figure 5

ms-SSE \(^{dyn}_{M}\) – Removing a document

For query, mSearch requires minimal modification from the static scheme due to how Doc+ and Doc− protocols are constructed. Figure 6 describes the protocol. The only additional step is for each server to generate tokens based on a sequence of counter values \(F(K_{tok},id_{S_{j}}|| cnt_{w})\) until there are no more matching token. This is required since for Doc+, we use a \(cnt_{w_{q}}\) to differentiate similar keyword entries for different documents to prevent leakage before queries.

Fig. 6
figure 6

ms-SSE \(^{dyn}_{M}\) – Modification to mSearch in ms-SSE M

We further discuss how a server can be introduced or removed. Adding a new server Svr+ can be straightforward. The idea is to generate a new server key, and then update the key list K S and the server list S. Instead of modifying existing indexes and redistributing the encrypted blocks that have been stored, the new server will only be considered when adding new documents.

Removing an existing server S j is more computationally intensive, as all blocks from S j must be re-assigned. This can be done using existing protocol Doc+. The index \(\gamma _{S_{j}}\) must also be processed as it contains block linkages pointing to locations in other servers. Such linkages can be decrypted, re-encrypted and redistributed randomly to the remaining servers. The mechanism is to append the re-generated linkages to the matching token entries of other servers S k . Also, the index \(\gamma _{S_{j}}\) contains entries referencing documents and its blocks’ locations. These can also be redistributed to another server. This completes the process but other servers S k may still contain linkages that point to the blocks stored in S j . In this case, the user archives the identifier of the removed server. During search if there is a linkage pointing to S j , the user discards this linkage.

Leakage

The leakage for mSetup is changed by the inclusion of list of document blocks as an entry in an index \(\gamma _{S_{j}}\). It follows that the number of entries in \(\gamma _{S_{j}}\) no longer indicates the number of keywords, but it is the sum of number of keywords |W j | and the number of documents |D j | whose encrypted blocks reside on the server. Besides, the total number of block identifiers, P j , and the difference between the number of block identifiers and the number of encrypted blocks, Δ, are no longer revealed. For server S j ,

$$\mathcal{L}^{setup}_{\texttt{ms-SSE}}=(|\mathbf{W}_{j}|\,+\,|\mathbf{D}_{j}|, \{|\textbf{p}_{i,j}|\,\vert\, i=1,\ldots,|\mathbf{W}_{j}|\,+\,|\mathbf{D}_{j}|\}). $$

The length of entry from the original index |p q, b | remains in the search query leakage. Due to document addition, the number of index entries retrieved for a search query may be more than one. Since the server computes the additional keyword tokens by incrementing counters, the leakage is a list of index entries and their lengths corresponding to the counters, \((c, l_{c,j}, |\textbf {p}_{c,b}|)_{c=1}^{cnt_{w_{q}}}\).

Another piece of leaked information in search query leakage is due to the delayed index update for document removal. When a document is deleted, the encrypted blocks of the document is identified and deleted immediately. The corresponding encrypted block identifiers in \(\gamma _{S_{j}}\) are deleted only when a keyword of the document is searched. Hence, the keyword belonging to the deleted document is hidden until it is searched. Nevertheless, if multiple documents have been removed before a search of the keyword, updating \(\gamma _{S_{j}}\) reveals that a deleted document that contained the keyword but does not reveal which document. Since the server finds and omits the encrypted block identifiers as sent by the user, the server would know the token of the entry from which they are omitted. As a result, the query leakage now contains the set of pairs \(\{(\tau _{i}, |\textbf {r}_{i}|) \,\vert \, 0\leqslant i \leqslant cnt_{w_{q}}\}\) where r i is the list of encrypted block identifiers omitted from \(\gamma _{S_{j}}[\tau _{i}]\). The set may be empty and may have at most \(cnt_{w_{q}}\) pairs. Search query leakage for server, S j is \(\mathcal {L}^{query}_{\texttt {ms-SSE}} =\)

$$\left( |\textbf{p}_{q,b}|,(c,l_{c,j}, |\textbf{p}_{c,b}|)_{c=1}^{cnt_{w_{q}}}, \text{SP}_{S_{j}}(w_{q}), \text{IP}_{S_{j}}(w_{q}), \{(\tau_{i}, |\textbf{r}_{i}|) \,\vert\, 0\leqslant i \leqslant cnt_{w_{q}}\}\right). $$

For document addition, a server S j possesses partial number of blocks of the added document, \(\textbf {c}_{S_{j}}^{u}\), and learns the number of newly stored blocks \(|\textbf {c}_{S_{j}}^{u}|\). S j also learns new keyword/blocks pairs added to \(\gamma _{S_{j}}\) and that these blocks belong to a document. We denote these pairs as \(L_{j} = (l_{q,j}, |\textbf {t}_{S_{j}}|)^{|\scriptsize {\textbf {W}_{u}}|}_{q=1}\). If a newly added document contains a keyword that was searched before, then S j learns this fact, since S j can use the list of previously submitted query tokens K t o k F(K,1||w q ) together with \(cnt_{w_{q}}\) to try to match the entry in \(\gamma _{S_{j}}\). We denote this pattern due to addition as \(\texttt {A}_{j}=\{ (F(K, 1||w_{q}), cnt_{w_{q}}) \,\vert \, w_{q} \in \textbf {W}_{u}\}\). We remark that the addition protocol can be readily extended to allow for addition of a batch of documents, in which then the information with regard to relation of blocks and document can be hidden in the case when many documents are added in a session. \(\mathcal {L}^{update,\texttt {Doc}^{+}}_{\texttt {ms-SSE}}\) = \(\left (|\textbf {c}_{S_{j}}^{u}|,L_{j}, \texttt {A}_{j}\right )\).

Similarly for document removal, S j learns the blocks and the number of blocks removed, and that the blocks belong to a document. In addition, when there is a match during deletion, S j learns that the entry in \(\gamma _{S_{j}}\) is not a keyword entry. A list R j = (v, l) where v ∈ {0, 1} and \(l := F(K_{tok}, id_{S_{j}})\) can be maintained, where if there is a match then we set v = 1. In summary \(\mathcal {L}^{update,\texttt {Doc}^{-}}_{\texttt {ms-SSE}}\) = \(\left (|\textbf {c}_{S_{j}}^{x}|, \texttt {R}_{j}\right )\).

The colluding servers collectively learn all leakages of all servers. Notice that since the query token that is sent to all servers is the same, colluding servers knows when they are searching for the same keyword, and hence would learn the total number of block identifiers returned to the user. Similarly, for document addition, the adversary learns would know all of the documents block ciphertexts and encrypted identifiers. In short, the leakage gained by adversary who controls all of the servers is equal to the leakage obtained by adversary in a single server SSE.

Theorem 3

Let ms-SSE \(^{dyn}_{M}\) and \(\mathcal {L}_{\texttt {ms-SSE}}=\left (\mathcal {L}^{setup}_{\texttt { ms-SSE}},\mathcal {L}^{query}_{\texttt {ms-SSE}},\mathcal {L}^{update}_{\texttt {ms-SSE}}\right )\) be as defined above. Then, ms-SSE \(^{dyn}_{M}\) is \(\mathcal {L}_{\texttt {ms-SSE}}\) -secure against non-adaptive chosen keyword attacks by colluding servers, assuming F is a secure pseudorandom function and \(\mathcal {E}\) is an IND-CPA symmetric encryption scheme.

Proof Sketch

As before we build a simulator for non-colluding server \(\mathcal {S}^{single}\) and extend it to the case of colluding servers \(\mathcal {S}^{multi}\).

Let Q 0, Q 1, … , Q κ be the queries submitted by the non-colluding adversary with Q 0 being the setup query, and for q > 0, Q q being search query, document addition query or document removal query.

For Q 0, the simulator \(\mathcal {S}^{single}\) generate an index γ′ with random strings according to {|p i, j | | i = 1, … , |W j | + |D j |} in \(\mathcal {L}^{setup}_{\texttt { ms-SSE}}\), similar to the simulator for Theorem 2.

For document addition query Q q , γ′ is modified to match new entries if A j . First, search for the known index keys l q, j from L j in search queries preceding Q q . Let Q i i < q denote the identified query whose leakage includes (c, l q, j ,|p c, b |) for some c and |p i, b |. Find element of A j with matching counter, \(cnt_{w_{q}}=c\) and extract its corresponding search token, \(y_{w_{q}}\). Choose an entry in γ′ with length |p i, b | and move the entry to \(\gamma ^{\prime }[F(y_{w_{q}},id_{S_{j}})]\). The new index entries are added to γ′ and \(\textbf {c}^{\prime }_{j}\) in a similar steps for setup queries.

Document removal query requires \(\mathcal {S}^{single}\) to delete the entry with the revealed index key l in R j from γ′ and \(|\textbf {c}^{x}_{j}|\) ciphertexts. If the document being deleted, D x is added after the initial setup, then the index key is known and hence omit entry at γ′[l]. Otherwise, \(\mathcal {S}^{single}\) chooses an entry with length \(|\textbf {c}^{x}_{j}|\) to omit from γ′ and ensure γ′[l] is empty.

For search query Q q whose leakage shows SP (w q ) = v for some v < q. If there are update queries among Q i for v < i < q, then \(\mathbf {J}^{\prime }_{q}\neq \mathbf {J}^{\prime }_{v}\). Hence, in such cases, \(\mathcal {S}^{single}\) use the other leakage elements to form \(\mathbf {J}^{\prime }_{q}\) correctly. Moreover, the index γ′ must be updated according to preceding document addition and removal queries.

The simulator for colluding servers \(\mathcal {S}^{multi}\) consists of t \(\mathcal {S}^{single}\) where t is the number of servers controlled by the adversary. The shared information among \((\gamma ^{\prime }_{j})_{j=1}^{t}\) which includes the same search token for every queried keyword is maintained because of the revealed index keys for document addition and removal, and for search queries.

The simulators described above are able to produce outputs fulfilling the leakages correctly. This implies that the adversary has insignificant probability in distinguishing the Real game from the Ideal game. □

Doc+ variants with forward privacy

The Doc+ protocol can be modified to achieve forward privacy introduced by [32], in that even if a keyword is searched before, the server will not be able to learn whether a newly added document also contains this keyword. We can use a unique key K q or maintain a counter c n t q to generate \(K^{q}_{tok} \leftarrow F(K^{q}, 1||w_{q})\) or \(K^{c}_{tok} \leftarrow F(K, 1||w_{q}||cnt_{q})\) for every occurrence of w q when adding documents. Nevertheless, both approaches are bandwidth intensive as during search the list of \(K^{q}_{tok}\) or \(K^{c}_{tok}\) must be submitted to all servers, in which the list grows linearly for every document update.

7 Performance

We summarise the performance of ms-SSE M in Table 1 with comparisons to some recent schemes. In the table, Leak measures leakage based on indexes, documents and keywords. Index size and Search time is measured per server. Comm. measures bandwidth for index, query and update submission while Inter. measures the number of rounds required to retrieve the documents/blocks.

Table 1 Comparisons with a few recent SSE schemes

Our schemes leak total number of blocks N l and the number of blocks per keyword |p w |, as compared to [28], which only reveals the total number of blocks and indexes b. We note though, Naveed et al. reveals document size |D f | after queries and requires more rounds of interaction.

Index size in ms-SSE G is equivalent to the underlying SSE scheme since the index is created by the SSE scheme it deploys. In the case of ms-SSE M , the total index size is O(N l), which for a single server is O(N l/s). For ms-SSE \(^{dyn}_{M}\), the index size is O((N + n)l)/s), which is higher due to the addition of document identifier entries in the index.

Search and update cost for ms-SSE G is as before equivalent to the underlying SSE scheme, but for communication, all our schemes are with higher overhead O(s) as it has to send the query token to s servers instead of one server. We note that, however, this is optimal when there is more than one server, unless we require the user to store information for servers to pull the blocks from, but this then increases storage and computational cost on the user. Search time for each server in ms-SSE M and ms-SSE \(^{dyn}_{M}\) is averagely z/s. All in all, our proposals provide better hiding properties in terms of document size and number of documents, with trade-offs on storage and communication.

8 Implementation of ms-SSE M

We implemented the ms-SSE M scheme, simulating multiple servers on a single local machine. The application was written as a single thread application. The workstation is running on an Intel Core i7-4510U (2 GHz) processor with 8 GB of memory and 256 GB of SSD.

The implementation was run using a test file with file size: 1,252,862,080 bytes (i.e., about 1.25 GB). Each chunk of block was the size of 50,000 bytes (50 kB). A total of number of 25,058 blocks was generated.

We measured the time taken for each algorithm. To generate the master key, the time taken was less than 1 millisecond (ms). 5 servers were simulated and the time taken to generate all five server keys was 234 ms. Building the index blocks, which includes block segmentation and encryption, took a total of 121.44 seconds. Searching took 81 ms whereas retrieval of the file, which includes block decryption and merging, took 39.19 seconds.

9 Conclusions

We proposed extensions of SSE to SSE over multiple servers. Given the availability of many providers, our rationale is that a user may choose to outsource encrypted documents to a few of them instead of just one. We defined multi-server SSE and proposed a generic construction that can be used to readily extend existing SSE schemes to work on multiple servers with minimal modification. We further proposed a construction that provides better hiding properties. It divides documents into sets of encrypted blocks and randomly assigns these blocks to different servers. This is done in a way that protects against any server from obtaining the complete set of blocks of a document with high probability, even in the encrypted form assuming servers do not collude, while achieving sublinear search time for each server. On security, we explore leakages under a new setting of non-colluding and colluding servers.