Exploiting Hidden Information Leakages in Backward Privacy for Dynamic Searchable Symmetric Encryption

Abstract

Dynamic searchable symmetric encryption (DSSE) enables searches over encrypted data as well as data dynamics such as flexible data addition and deletion operations. A major security concern in DSSE is how to preserve forward and backward privacy, which are typically achieved by removing the linkability between the newly added data and previous queries, and between the deleted data and future queries, respectively. After information leakage types were formally defined for different levels of backward privacy (i.e., Type-I, II, III), many backward private DSSE schemes have been constructed under the definitions. However, we observed that the backward privacy can be violated by leveraging additional secondary leakage, which is typically leaked in specific constructions of schemes in spite of their theoretical guarantees. In this paper, in order to understand the security gap between the theoretical definitions and practical constructions, we conduct an in-depth analysis of the root cause for the secondary leakage, and demonstrate how it can be abused to violate Type-II backward privacy (e.g., the exposure of the deletion history) of DSSE constructions in practice. We then propose a novel Type-II backward private DSSE scheme based on Intel SGX, which is resilient to the secondary leakage abuse attack. According to the comparative analysis of our scheme with the state-of-the-art SGX-based DSSE schemes, Bunker-B (EuroSec’19) and SGX-SE1 (ACNS’20), our scheme shows higher efficiency in terms of the search latency with a negligible utility loss under the same security level (cf. Bunker-B) while showing similar efficiency with a higher security level (cf. SGX-SE1). Finally, we formally prove that our scheme guarantees Type-II backward privacy.

1. Introduction

Dynamic searchable symmetric encryption (DSSE) is a kind of searchable symmetric encryption (SSE) specifically designed to support data dynamics such as addition and deletion operations in an encrypted database (EDB) [1,2]. Although DSSE schemes benefit from the flexible operations without decryption, they are likely to leak sensitive information. For example, an adversary can observe added or deleted documents that are accessed by users by exploiting the access pattern leakage [3], or identify the underlying keyword of queries by exploiting the search pattern leakage [3].

To formally address this information leakage problem, Bost et al. [4,5] introduced the notions of forward and three different types (i.e., Type-I, II, III) of backward privacy in DSSE, mainly focusing on addressing security concerns regarding the linkability between queries (e.g., update and search) and updated data. Although leaking less information implies higher security, it inevitably incurs higher computational overhead. For example, Type-I backward privacy has been only achieved by adopting cryptographically heavy operations such as oblivious RAM (ORAM) [6].

Recently, a trusted execution environment (TEE) such as Intel SGX [7] has been considered for DSSE to mitigate efficiency problems caused in favor of the forward/backward privacy preservation [8,9,10,11]. Amjad et al. [8] proposed several forward and various types of backward private DSSE schemes using Intel SGX. Their first scheme, called Fort, achieves the highest security guarantee (i.e., Type-I), but suffers from high communication overhead due to the usage of ORAM [6]. To balance security and efficiency, they proposed another scheme, called Bunker-B (Type-II), aiming to reduce communication costs. However, it still suffers from scalability degradation.

To resolve this problem, Vo et al. proposed SGX-SE1, providing Type-II backward privacy [11], and Maiden providing Type-I backward privacy [12], both leveraging the server-side SGX enclave as a proxy to reduce the communication cost and enhance the scalability of the scheme. Unfortunately, despite its efficiency improvement, we observed that SGX-SE1 does not fully guarantee Type-II backward privacy as expected. SGX-SE1 has additional information leakage related to deletion history, which is information leakage only allowed in Type-III backward privacy, by exploiting secondary leakage, which is naturally allowed in the protocol construction. Thus, in this paper, we seek to answer the following questions: What is the root cause or conditions for the leakage, and how can it be exploited to break the backward privacy of DSSE schemes?

In search of the answer, we first conduct an in-depth analysis of the information leakages in existing Type-II backward private DSSE schemes [8,11,13,14] in terms of both theoretical definitions and scheme constructions. Consequently, we found that there exist information leakages in several schemes [11,14], which can be utilized to extract a deletion history of the encrypted data, leading to violation of Type-II backward privacy. Then, we examine the condition allowing the vulnerability, and demonstrate how it can affect the Type-II backward privacy in practice by exploiting the secondary information leakage on Vo et al.’s [11] and Sun et al.’s [14] DSSE schemes.

Next, we propose a novel forward and Type-II backward private DSSE scheme based on SGX. To this end, we design an obfuscation technique to hide the access and the search patterns in order to prevent the information leakages related to update operations. To minimize extra communication and computation costs caused by the obfuscation technique, we selectively cache the top k-frequently accessed documents inside the SGX enclave for fast data retrieval and obfuscation.

According to our comparative analysis results with the state-of-the-art SGX-based DSSE schemes, Bunker-B [8] and SGX-SE1 [11], the search time of the proposed scheme is approximately 27× faster than that of Bunker-B, while providing the same security level. Compared with SGX-SE1, the proposed scheme achieves a higher level of security while minimizing performance degradation.

Contributions: Our contributions are summarized as follows:

• We conduct a comprehensive analysis of the existing Type-II backward private schemes, and discover information leakage that falls outside the purview of the existing backward privacy notions. We then demonstrate how those leakages are exploited to extract the deletion history in Type-II schemes.
• We demonstrate how our findings on information leakages exacerbate the security of known Type-II backward private schemes by exploiting the Vo et al. DSSE scheme [11] and Sun et al. DSSE scheme [14].
• We design a novel forward and Type-II backward private DSSE scheme based on SGX, which hides the information leakage of deletion history with high efficiency.
• We conduct a comparative analysis of our scheme with the state-of-the-art SGX-based DSSE schemes, Bunker-B [8] and SGX-SE1 [11], in both synthetic and real-world Enron [15] datasets. According to the analysis, our scheme shows higher efficiency in search latency with negligible utility loss under the same security level (cf. Bunker-B) while showing similar efficiency with a higher security level (cf. SGX-SE1).

2. Preliminaries

In this section, we introduce the basic background of Intel SGX, the preliminaries, and the cryptographic background of forward/backward privacy in DSSE. $\lambda$ denotes the security parameter, and $negl\left(\lambda \right)$ denotes a negligible function in the security parameter. A database DB denotes a list of file identifier and keyword set pairs.

2.1. Intel SGX

A trusted execution environment (TEE) allows an arbitrary code to be executed in an isolated environment, providing integrity and confidentiality protection on the executed codes, stored data, and runtime states, such as sensitive I/O, CPU registers, and memory. Intel SGX, one of the main prevailing and representative TEEs, is a set of extended Intel’s x86 instructions providing isolated execution environments, called enclaves [7]. The enclave is the trusted component located in a dedicated memory portion of the physical RAM, called the enclave page cache (EPC). During system boot-up, a total of 128 MB is typically reserved for the Intel SGX, out of which 96 MB is allocated to the EPC; this EPC is shared among all the running enclaves on the system. The untrusted part is executed as an ordinary process, and can trigger the enclave under a securely defined process. When the data are loaded inside the enclave, the SGX-enabled processors protect their integrity and confidentiality by isolating them from the outside untrusted environment, including the operating systems and hypervisor. The enclave can access the entire virtual memory of its untrusted host process, but the untrusted host or any other enclave cannot directly access any code or data in the enclave.

When an enclave is required to communicate with other instances, an attestation mechanism is executed for authentication before exchanging the data. There are two forms of attestation: local attestation and remote attestation. Local attestation is used for authenticating two enclaves running on the same physical machine, and is conducted using the EREPORT and EGETKEY instructions, which generate signed reports for verification. Remote attestation is used when an enclave attests its identity (usually represented by its initial code and data) to another enclave running on a remote physical machine. The remote enclave uses a quote generated by the quoting enclave (QE), and verifies the signature by sending it to the Intel attestation server. Through the attestation service, a secure channel is established between them.

2.2. Definition of DSSE

A DSSE scheme consists of three algorithms: Setup, Update, and Search. Let $\lambda$ denote the security parameter, and it is implicit input for all algorithms. $\mathrm{DB}=\left\{(in{d}_i,w_i)\right\}$ refers to the database, where $ind$ denotes file identifier and w denotes the keyword. $\mathrm{EDB}$ denotes an encrypted database, and $\sigma$ denotes the state of the client. $\mathrm{op}$ denotes the type of update operation (addition or deletion). Each algorithm is defined as follows:

• (EDB, $\sigma$) ←Setup($1^{\lambda }$, DB): Setup takes as input the security parameter $\lambda$ and the initial database DB.
• (${\sigma }^{\prime }$, ${\mathrm{EDB}}^{\prime }$) ←Update($\sigma$, op, ind; EDB): Update is a client-server protocol, where the client takes as input the state $\sigma$, a file identifier ind, and type of operation op $=\{add,del\}$; and the server takes as input the encrypted database EDB. The client outputs updated state ${\sigma }^{\prime }$, and the server outputs an updated encrypted database ${\mathrm{EDB}}^{\prime }$ as a result.
• (${\sigma }^{\prime }$, DB(w); ${\mathrm{EDB}}^{\prime }$) ←Search($\sigma ,w$; EDB): Search is also a client-server protocol, where the client takes as input the state $\sigma$ and search keyword w; the server takes as input the encrypted database EDB. Then, the client outputs ${\sigma }^{\prime }$ and DB(w) of the file identifiers matching keyword w; the server outputs the updated encrypted database ${\mathrm{EDB}}^{\prime }$.

The adversary is only allowed to learn the information explicitly captured by the leakage function $\mathcal{L}=({\mathcal{L}}^{Setup},{\mathcal{L}}^{Srch},{\mathcal{L}}^{Updt})$.

2.3. Forward and Backward Privacy of DSSE

2.3.1. Forward Privacy

Forward privacy [16] ensures newly updated data entries cannot be related to the previous search queries. The forward-private DSSE scheme hides the linkability between an update operation and the past search queries [2]. Thus, if a client performs any update operations (i.e., document/keyword add or delete) on a keyword w, the adversary, including the data server, cannot learn any information whether searches on keyword w have been made beforehand, mitigating the file injection attack [17] in DSSE schemes.

2.3.2. Backward Privacy

When searching on keyword w is made, backward privacy [2,5] guarantees that the deleted document identifiers containing w are not revealed.

Now, we introduce a leakage function defined in backward privacy. The record information revealed in a list of queries issued so far is represented as the above leakage function $\mathcal{L}$. The list of queries is denoted as Q, where

$$Q=\left\{\right(u,\mathrm{op},\mathrm{in}\left)or\right(u,w\left)\right\}.$$

There are two types of query: search query and update query. $(u,w)$ is a search query, where u refers to the timestamp and w refers to the search keyword. Note that the timestamp u starts from 0 and increases with the incoming queries. (u, op, in) is an update query, where op ∈{add, del} and in refers to the input $(w,\mathrm{ind})$.

The search pattern [3], $sp\left(w\right)$, is one of the common leakage function, composed of timestamps of all search queries on keyword w, which allows an adversary to identify identical search queries. The formal definition of $sp\left(w\right)$ is defined as follows:

$$sp\left(w\right)=\left\{u\right|(u,w)\in Q\}.$$

$TimeDB\left(w\right)$, for a keyword w, leaks the list of all documents matching a search keyword w and the timestamp of their insertion, except for documents that are deleted. The formal definition is as follows:

$$\begin{array}{c}TimeDB\left(w\right)=\left\{\right(u,\mathrm{ind}\left)\right|(u,add,(w,\mathrm{ind}\left)\right)\in Q,\\ \mathrm{and}\forall u^{\prime },(u^{\prime },del,(w,\mathrm{ind}))\notin Q\},\end{array}$$

Note that $u^{\prime }$ is the timestamp that comes after the u. $Updates\left(w\right)$ refers to the list of timestamps of all updates on keyword w. Formally, $Updates\left(w\right)$ is defined as:

$$\begin{array}{c}Updates\left(w\right)=\left\{u\right|(u,add,(w,\mathrm{ind}\left)\mathrm{or}\right(u,del,\\ (w,\mathrm{ind}))\in Q\}.\end{array}$$

Lastly, the leakage function $DelHist\left(w\right)$ is defined as follows:

$$\begin{array}{c}DelHist\left(w\right)=\{(u^{add},u^{del})|\exists \mathrm{ind}s.t.(u^{del},del,(w,\\ \mathrm{ind}\left)\right)\in Q,\mathrm{and}(u^{add},add,(w,\mathrm{ind}))\in Q\}.\end{array}$$

Bost et al. [5] introduced the formal definitions for three different types of backward privacy ordered from the most to least secure notions, which are defined as follows:

• Type-I: It leaks the document identifiers matching the keyword w, timestamps of their insertion $\left(TimeDB\right(w\left)\right)$, and total number of updates on w.
• Type-II: It leaks the document identifiers matching the keyword w, $TimeDB\left(w\right)$, and the list of timestamps of the entire updates on keyword w$\left(Updates\right(w\left)\right)$.
• Type-III: It leaks the document identifiers matching the keyword w, $TimeDB\left(w\right)$, $Updates\left(w\right)$, and deletion history $\left(DelHist\right(w\left)\right)$ that reveals which deletion update canceled which insertion update.

3. Leakage Abuse Attack

In this section, we introduce how leakage information we found can be exploited by an adversary to obtain the deletion history of the state-of-the-art Type-II backward privacy schemes.

Table 1. Classification of existing Type-II DSSE schemes.

Scheme	BP-Type	Prone to Attack	SGX
Fides	Type-II	X	-
Mitra	Type-II	X	-
Bunker-B	Type-II	X	O
SGX-SE1	Type-II	O	O
SGX-SE2	Type-II	O	O
Aura	Type-II	O	-

shows state-of-the-art Type-II backward private schemes that are prone to our attack. In order to demonstrate its feasibility, we show how our attack can be conducted on SGX-SE1 [11] and Aura [14] as representative SGX-based and non-SGX-based Type-II backward privacy schemes, respectively. Finally, we discuss the root cause of the vulnerability of the scheme constructions.

3.1. Threat Model

Similar to the previous DSSE schemes [8,11], we consider a semi-honest adversary at the server side, such that the adversary can observe the interaction of the enclave with the other resources located outside the enclave, and has the privilege of gaining full access over software stack outside the enclave, as well as the operating system and hypervisor. Additionally, the adversary can learn information about the access patterns by observing memory addresses and encrypted data in the encrypted database. Finally, the adversary can log the timestamps of every memory manipulation during the entire protocol, aiming to extract the deletion history.

3.1.1. Trust Assumptions on Intel SGX

We assume that the SGX enclave behaves normally without hardware bugs or backdoors. The preset code and data inside the enclave are securely protected, and cryptographic primitives provided by SGX are trusted [7]. Furthermore, the communications and data transfer between different clients or servers are protected by the secure channels established by the SGX attestation service. The enclave can be invoked whenever clients need. We do not consider the side-channel and denial-of-service (DoS) attacks against the SGX as in many other SGX-based applications [13,18,19,20,21].

3.2. Extraction of Deletion History

As described in Section 2.3.2, Type-II backward privacy only leaks document identifiers matching the searched keyword w, $TimeDB\left(w\right)$, and $Updates\left(w\right)$. If a scheme leaks $DelHist\left(w\right)$ along with the other Type-II leakages, the adversary is allowed to know which deletion update cancels which add update that previously occurred, downgrading it into Type-III backward privacy. Thus, if a part of deletion history is revealed to an adversary, the privacy level of the scheme may be weakened than the original Type-II backward privacy level.

According to our investigation of the existing Type-II backward private schemes, we observed that they may leak $DelHist\left(w\right)$ when an adversary can exploit the access and search pattern leakages together with information leakages allowed in Type-II backward privacy (especially when they are constructed with static data structures or static values for identifying documents matching a specific keyword w). In order to obtain it, specifically, the adversary should be able to (1) distinguish whether the update operation is addition or deletion, and (2) distinguish whether two separate queries are on the same keyword w (search pattern leakage). When an addition operation is executed, the adversary is able to observe the added document identifier $id$ from the update query (but not the keyword w). Thus, the adversary learns $(u,add,(w,id\left)\right)$, where u refers to the timestamp of the operation. According to the definition of Type-II backward privacy, $DelHist\left(w\right)$ should be hidden from the view of the server.

Next, during the search protocol for a specific keyword, the server is able to observe the query tokens and memory access of the EDB (i.e., the access pattern). Note that each query token refers to a single document. If the query token or the search index is encrypted, the adversary may observe the following search query consisting of the encrypted i query tokens $Q=\{q{t}_1^w,q{t}_2^w,\dots ,q{t}_i^w\}$, where $q{t}_j^w$ refers to the j-th query token for keyword w for $1\le j\le i$. The adversary then observes and learns the search result $Res=\{i{d}_1,i{d}_2,\dots ,i{d}_i\}$, directly indicating the access pattern of the EDB for the documents in $Res$.

When a client sends a search query $Q^{\prime }$ consisting of k query tokens later, the adversary would observe $Q^{\prime }=\{q{t}_1^{w^{\prime }},q{t}_2^{w^{\prime }},...,q{t}_k^{w^{\prime }}\}$, and learn $Re{s}^{\prime }=\{i{d}_1^{\prime },i{d}_2^{\prime },\dots$,$i{d}_k^{\prime }\}$, for the search result of $Q^{\prime }$. If the value of query token $qt$ is encrypted in a deterministic manner and is bound to a specific keyword, then the adversary can identify whether two different search queries are linked to the same keyword w by simply comparing the values of the query tokens (When the query token is generated in a non-deterministic manner, such as re-encryption, as in Bunker-B [8], for example, our extraction of deletion history might not work due to the indistinguishability in the adversary’s view).

When observing $i>k$, the adversary may learn the deletion updates are performed between two searches of Q and $Q^{\prime }$ on the same keyword w. Further, by comparing the search results $Res$ and $Re{s}^{\prime }$, the adversary can learn which document $id$ was deleted. Consequently, the probability that the adversary can determine which delete updates are related to w is $P_{Del\left(w\right)}=\frac{i-k}{N_{del}}$, where $N_{del}$ is the number of possible deletion operations performed in the period. According to the definition of Type-II backward privacy, any information on $DelHist\left(w\right)$ should not be leaked. However, by exploiting the query token, search result, and access pattern of the EDB, the adversary can learn which delete update cancels which add update, leaking $DelHist\left(w\right)$ information with a probability of $P_{Del\left(w\right)}$. In addition, as mentioned in Section 2.2, if there exists an index such that the timestamp of its insertion and deletion is revealed to the adversary, the scheme leaks $DelHist\left(w\right)$. Thus, if a deletion history can be successfully extracted, the claimed Type-II backward privacy is violated. It is important to note that even though queries are encrypted using a randomized encryption algorithm, the extraction of deletion history can still be applied as long as the search pattern and the other information required for the extraction are leaked. In Section 3.4, we demonstrate the efficacy of the extraction by showing that $P_{Del\left(w\right)}$ can be non-negligible in the real-world scenario.

3.3. Attacks on Prior Works

We show how the deletion history can be extracted in Vo et al.’s SGX-SE1 [11] and Sun et al.’s Aura [14]. For better understanding, we briefly explain the overview of each scheme’s construction first. Then, we demonstrate how the deletion history can be extracted from each protocol.

3.3.1. Vo et al. Scheme

Vo et al. [11] proposed SGX-based forward and Type-II backward private dynamic searchable encryption schemes, named SGX-SE1 and SGX-SE2. In this paper, we focus only on SGX-SE1 because it is the baseline scheme upon which SGX-SE2 is built.

When a client uploads a new document in SGX-SE1, the document is sent to the SGX enclave in the server through the addition operation in the update protocol. The enclave then parses all the keywords within the document, and uses the latest state $ST\left[w\right]$, which infers the number of documents containing w. Specifically, for each keyword w, $ST\left[w\right]$ increases by 1 whenever a document containing w is added. The encrypted index u is a deterministic value generated by $H(k_w,c)$, where H refers to a hash function that hashes $k_w$, which is a key value bound to w, and the count value c of $ST\left[w\right]$. A map of the encrypted index $M_I\left[u\right]$ stores the encrypted document identifier.

When deleting a document, the client transfers the corresponding document identifier $id$ to the enclave. On receipt of it, the enclave stores the $id$ within a deleted document list d, and the actual deletion of it from the EDB is conducted during the search protocol.

In the search protocol, when the enclave receives a keyword w from the client, it first fetches the document identifiers from the deleted document list d. Next, the enclave loads the corresponding documents and checks whether the keyword w exists within each document. The enclave retrieves $ST\left[w\right]$ of the deleted documents, which were used when they were added, and excludes these values from $\{0,\dots ,ST[w\left]\right\}$. The remaining values in the set are then used to generate query token u for the non-deleted documents. The list of query tokens u is transferred to the server. Finally, the server computes the $id$ by decrypting $M_I\left[u\right]$, and returns the corresponding encrypted documents to the client.

Extraction Scenario. 

Table 2. Example of SGX-SE1 protocol flow.

Algorithm	Leakage Information (Attacker’s View)	Leakage Type
$Setup\left(1^{\lambda }\right)$	-	-
$Update(add,$	$(add,i{d}_1)$	Update
$(do{c}_1,i{d}_1))$		Pattern
…	…	…
$Search\left(w\right)$	$Q_w\to \{(u_1,k_{i{d}_1}),$	Search
	$(u_2,k_{i{d}_3}),(u_3,k_{i{d}_4})\}$	Pattern
	$Res\to \{i{d}_1,i{d}_3,i{d}_4\}$	Access
		Pattern
$Update(del,i{d}_{12})$	-	-
$Update(del,i{d}_3)$	-	-
$Update(del,i{d}_9)$	-	-
$Search\left(w\right)$	$Q_w\to \{(u_1,k_{i{d}_1}),$	Search
	$(u_3,k_{i{d}_4})\}$	Pattern
	$Res\to \{i{d}_1,i{d}_4\}$	Access
		Pattern

$Q_w$: search query for keyword w, $Res$: search result, $id$: document identifiers, u: encrypted index, $k_{id}$: key value for $id$.

shows the example flow of SGX-SE1 protocol [11], along with the leakage information and its type. When searching on keyword w in SGX-SE1, the enclave sends a search query $Q_w$ containing a list of $(u,k_{id})$ pairs to the server, where $k_{id}$ refers to the key value bound to the document identifier. The adversary can observe and trace from $Q_w$ the deterministic values of u’s, which are bound to the specific keyword. Therefore, by comparing the values of u from the past search, the adversary learns if two different queries are on the same keyword, leading to the search pattern leakage. Because the document identifiers and encrypted documents are retrieved in the untrusted area, the adversary can observe the access pattern of the matching result as well as the accessed document identifiers. The adversary compares the matching results of the two queries and learns that deletion update on $i{d}_3$ occurred in the period between the two searches (as shown in Table 2). Among the three delete updates that occurred between the two searches, one of them must correspond to the deletion of $i{d}_3$, thus the probability of making a correct guess is $\frac{1}{3}$. Since the adversary has the knowledge of the timestamps of all updates and when each document is added with their identifier values, the aforementioned leakage information allows the adversary to learn $DelHist\left(w\right)$.

3.3.2. Sun et al. Scheme

Sun et al. [14] proposed a non-SGX-based Type-II backward private scheme called Aura. Aura requires the client to revoke the encryption key after each search. The search result does not need to be re-encrypted because the previous search result is cached.

When the client adds a keyword and document identifier ind to the database, the client retrieves the most recently used encryption key $msk$, and computes a ciphertext with ind and a tag $t=F_{K_t}(w,\mathrm{ind})$, where F is a pseudo-random function and $K_t$ is secret key for t. Then, the computed ciphertext is inserted into the database ${\mathrm{EDB}}_{add}$. For deletion, the client inserts tag t corresponding to the deleting entry $(w,\mathrm{ind})$ into the deletion list D.

For searching on keyword w, the client retrieves the number of searches on keyword w, denoted as i, the current secret key $sk$, and the deletion list D. Then, the client computes the revoked secret key $s{k}_R$ and query token $tkn$, sends them to the server, and refreshes $msk$. The server retrieves encrypted indices matching w and decrypts the non-deleted indices with $s{k}_R$. The non-deleted indices are added to a list NewInd; the deleted tags are added to a list DelInd. Then, the server retrieves indices stored in ${\mathrm{EDB}}_{cache}\left[tkn\right]$ and excludes entries that are in DelInd, where ${\mathrm{EDB}}_{cache}$ stores the previous search result. Finally, NewInd together with non-deleted indices stored in cache ${\mathrm{EDB}}_{cache}\left[tkn\right]$ are returned to the client.

Extraction Scenario. As explained above, during the search protocol, the server accesses ${\mathrm{EDB}}_{cache}\left[tkn\right]$ for retrieving cached search results. By comparing the accessed ${\mathrm{EDB}}_{cache}\left[tkn\right]$, the adversary can learn which previous search query is on the same keyword w. The timestamps of addition update queries on w (i.e., $TimeDB\left(w\right)$) that occurred between two search queries on w are revealed to the adversary. Note that remaining update queries between two search queries can be possibly deletion updates on w. During the execution of the second search query, the adversary can obtain additional information on how many deletion updates on w occurred by observing the number of entries excluded from ${\mathrm{EDB}}_{cache}$. Since the entries stored in ${\mathrm{EDB}}_{cache}$ are in the form of $(\mathrm{ind},t)$, the deleted indices are also revealed while excluding deleted entries from the cache.

Because the insertion timestamps of each $(w,\mathrm{ind})$ are revealed, the adversary, similar to the case of Vo et al.’s scheme [11], is able to extract $DelHist\left(w\right)$ using the timestamps of possible deletion updates on w and deleted ind. However, the attack against Aura has a lower success rate than that of SGX-SE. The reason is that Aura does not follow the traditional definition of Type-II backward privacy and follows a somewhat different definition for Type-II backward privacy.

3.3.3. Discussion

As shown in the above attack scenarios, in addition to the information leakages defined in Type-II backward privacy, there exists extra information that an adversary may learn from the protocols and exploit for extracting a deletion history. A root cause for allowing the additional leakage is the static data structures and static values used for updating and searching a keyword. During the search protocol, for instance, SGX-SE1 [11] and Aura [14] access the same locations of data structures when searching on the same keyword. Thus, the adversary is able to specify whether a certain document is added or deleted when compared with the same information learned from the previous search query on the same keyword. Bunker-B [8], on the other hand, accesses different locations of data structure for every search query on the same keyword, due to the re-encryption of the entries after every search. However, the re-encryption of entries incurs high computational overhead, degrading the practicality of the scheme. It is thus a challenging problem to minimize extra information leakages while achieving high efficiency.

3.4. Feasibility of Deletion History Extraction

We evaluate the feasibility of deletion history extraction by conducting a simulation on its probability in diverse distribution models of data upload, delete, and keyword search in the cloud storage. In the simulation, we randomly generate queries and analyze the probability of deletion history extraction.

According to the distribution models for file transfer [22] and search query [23], we assume that the document upload follows a Poisson distribution with rate $\tilde{\lambda }$, the data lifespan follows an exponential distribution with a mean duration $\frac{1}{\mu }$, and the search request on the same keyword follows an exponential distribution with a mean duration $\frac{1}{{\mu }^{\prime }}$. Also, the keyword frequency of the documents follows a Zipf distribution.

Based on the aforementioned distribution models, we evaluate the feasibility of deletion history extraction by measuring its probability under various simulation settings. Figure 1 shows the evaluation results in each case. In the figure, the horizontal axis represents the time in hours, and the vertical axis represents the probability of successful extraction $P_{Del\left(w\right)}$, which is the probability of identifying which document is deleted. When simulating for 100 h with $\tilde{\lambda }=3$, $\frac{1}{\mu }=40$, and $\frac{1}{{\mu }^{\prime }}=1$, we have observed a total of 11 time instances that enable our extraction with non-negligible probabilities. As shown in Figure 1a, for example, there exists a time instance when the extraction succeeds with 100% (between 56 and 57 h), leading to the violation of Type-II backward privacy. As another example, one can observe that $P_{Del\left(w\right)}$ reaches $0.5$ two times between 20 and 70 h, meaning that the deleted document can be identified with probability $\frac{1}{2}$, violating Type-II backward privacy in a probabilistic (but still pragmatically meaningful) way in those periods. Figure 1b shows the evaluation results when search requests are performed on average four times more frequently than in Figure 1a. As a result, we could observe that there are two time instances showing $P_{Del\left(w\right)}=1$ (between 33 and 34; 61 and 62 h) and five time instances showing $P_{Del\left(w\right)}=0.5$.

In Figure 1a,b, on average, 53 update queries (consisting of 41 addition and 10 deletion queries) were generated for the target keyword. When considering all of the update queries in the above simulations, the adversary could extract 1.6% and 3.2% of actual deletion history for the target keyword, respectively. For deletion queries for the target keyword, the adversary could extract 10% and 20% of deletion queries. When considering the attack success rate above $P_{Del\left(w\right)}=0.5$, the probability of possible deletion history extraction non-negligibly increases.

The aforementioned simulations indicate that the extraction probability increases as the number of search requests on the same keyword increases (compare Figure 1a,b) When calculating $P_{Del\left(w\right)}$, the total number of deletions that occurred between two searches on the same keyword, $N_{del}$, affects the probability. It is clear that if the search requests are sent more frequently, $N_{del}$ would be smaller with high probability, leading to an increase in $P_{Del\left(w\right)}$.

4. Our Construction

In this section, we propose a novel forward and Type-II backward private DSSE scheme based on SGX.

4.1. System Overview

Figure 2 shows the overview of the proposed scheme. There are three entities in the system: the client, the server, and the SGX enclave within the server. The client is the data owner, which is assumed to be trusted. We assume that all the entities above act normally and do not consider incorrect queries or wrong operations. As described in Section 3.1.1, although the enclave is located within the untrusted server, the server cannot observe the code or data inside the enclave. Also, we assume that the enclave is fully trusted and resilient to side-channel attacks.

In the proposed scheme, the client establishes a secure channel with the authenticated enclave using the SGX remote attestation service. The client provisions a secret key K in the enclave through the secure channel (step ➀). During this procedure, the client does not deploy any encrypted database (EDB) to the server as in the other DSSE schemes [5,8].

The update procedure in the proposed scheme consists of two different operations: addition and deletion. When adding a document to the cloud storage, the client assigns a unique identifier $id$ to the document, and encrypts the document with a key K (Step ➁). Then, the encrypted document and its $id$ are sent to the enclave through a secure channel (Step ➂). With the received $id$ and encrypted document, the enclave extracts all the keywords within the document, and performs cryptographic operations to generate an update token with the encrypted index and state. The update token and encrypted document are then transferred to the server (Step ➃). The map of the encrypted index $M_I$ is separately managed in the untrusted area. When deleting a document, the client simply sends the document identifier $id$ to the enclave (Step ➄ & Step ➅). (The actual deletion process of the document will be further explained in Section 4.3).

When retrieving documents from the outsourced EDB, the client sends the search keyword w to the enclave through the secure channel (Step ➆ & Step ➇). The enclave then computes the query tokens, and sends the final search query to the server except the tokens for the deleted documents (Step ➈). The server then searches over the encrypted index, and returns back the document identifier list to the enclave (Step ➉). With the identifier list, the enclave searches over the cached document list; and returns the identifiers not matching any of the cached documents to the server to retrieve the encrypted documents (Step ⑪). Finally, the enclave sends the matching documents to the client through the secure channel (Step ⑫).

4.2. Design Goal

As analyzed in Section 3, Vo et al. [11] and Sun et al. [14] schemes are vulnerable to extraction of deletion history, related to leakage profile of Type-III, although their initial security aimed at Type-II backward privacy. Our principal objective is to design a ’solid’ Type-II backward private scheme, which only leaks information that is allowed in Type-II backward privacy.

4.3. Scheme Construction

To facilitate searches, our scheme lets the enclave store the following information: (1) the map $ST$ storing the pairs of a keyword and its latest state, (2) the deleted document list d, (3) the map D storing the pairs of a keyword and a deleted document’s $id$ in d associated with the keyword, (4) the map $SC$ storing the pairs of a document $id$ and the number of searches over the document, and (5) the map $FD$ storing the pairs of a document $id$ and its encrypted data in the EDB. Each notation is defined in

Table 3. Notations of data structures.

Notation	Definition
K	Secret key
$ST$	Latest state of keywords
d	List of deleted documents
D	A map for keyword and deleted documents
$SC$	Number of times each document searched
$FD$	k-frequent documents
R	Repository (EDB)
$M_I$	Encrypted index
$M_c$	Encrypted state

.

The proposed scheme consists of three algorithms: $Setup$ (Algorithm 1), $Update$ (Algorithm 2), and $Search$ (Algorithm 3). In the algorithms, $H_1$, $H_2$, and $H_3$ denote the cryptographic hash functions, and Enc$(a,b)$ is the encryption of b under a key a.

Algorithm 1 $Setup\left(1^{\lambda }\right)$

Client: 1: $k_{\Sigma },k_f^{\lambda } {\leftarrow }_{\$} {\{0,1\}}^{\lambda }$ 2: Launch Remote Attestation              ▹ Establish secure channel 3: Send $K=(k_{\Sigma },k_f)$ to Enclave     Enclave: 4: Initialize maps $ST$, D, $SC$, $FD$; tuples $T_1$, $T_2$; a list d 5: Receive $K=(k_{\Sigma },k_f)$     Server: 6: Initialize maps $M_I$ and $M_c$ 7: Initialize Repository R

In the $Setup$ algorithm, the client communicates with the enclave and provisions a secret key K containing a key pair $(k_{\Sigma },k_f)$ through the secure channel established by the attestation service provided by Intel [7]. The enclave uses $k_{\Sigma }$ to generate update and query tokens and a symmetric key $k_f$ to encrypt/decrypt a document. The enclave initializes the maps $ST$ and D and the list d. The server initializes the maps $M_I$ and $M_c$, where $M_I$ and $M_c$ refer to the encrypted index and the encrypted state, respectively. Also, the repository R stores the encrypted document with its document identifier $id$.

Algorithm 2 $Update($op, $\mathrm{in})$

Client: 1: if op $=add$ then 2:     $f\leftarrow$ Enc($k_f$, doc) 3:     send (op$,id,f$) to Enclave 4: else                            ▹ when op $=del$ 5:     send (op$,id$) to Enclave 6: end if     Enclave: 7: if op = $add$ then 8:     send $(id,f)$ to Server 9:     $\left\{(w,id)\right\}\leftarrow Parse\mathrm{Dec}\left((k_f,f)\right)$ 10:     foreach $(w,id)$ do 11:         $k_w\parallel k_c\leftarrow F(k_{\Sigma },w)$ 12:         $c\leftarrow ST\left[w\right]$ 13:         if $c=\perp$ then $c=-1$ 14:         end if 15:         $c\leftarrow c+1$ 16:         $k_{id}\leftarrow H_1(k_w,c)$ 17:         $(u,v)\leftarrow (H_2(k_w,c),\mathrm{Enc}(k_{id},id))$ 18:         add $(u,v)$ to $T_1$ 19:         $(u^{\prime },v^{\prime })\leftarrow (H_3(k_w,id),\mathrm{Enc}(k_c,c))$ 20:         add $(u^{\prime },v^{\prime })$ to $T_2$ 21:     end for 22:     send $(T_1,T_2)$ to Server 23: else                           ▹ when op $=del$ 24:     add $id$ to d 25: end if     Server:                          ▹ when op $=add$ 26: $R\left[id\right]\leftarrow f$ 27: receive $(T_1,T_2)$ from Enclave 28: foreach $(u,v)$ in $T_1$ do 29:     $M_I\left[u\right]=v$ 30: end for 31: foreach $(u^{\prime },v^{\prime })$ in $T_2$ do 32:     $M_c\left[u^{\prime }\right]=v^{\prime }$ 33: end for

The $Update$ algorithm takes as an input (op,$\mathrm{in})$, where op can be either $add$ or $del$, and $in$ would be (doc, $id$) if op = $add$, or $id$ if op = $del$. When an add update is invoked (i.e., op = $add$) in the algorithm, the client generates an encrypted document f by encrypting the doc under a key $k_f$. The enclave receives (op$,f,id)$ from the client. The received ($id,f$) is stored in repository R, located in the server area. Then, the enclave parses the received doc to retrieve a list of $\left\{\right(w,id\left)\right\}$. For each keyword w, the enclave uses $k_{\Sigma }$ to generate $k_w$ and $k_c$, and retrieves the latest state c. Then, $k_{id}$ is generated from c by executing the hash function as $k_{id}=H_1(k_w,c)$; and two encrypted entries $(u,v)$ and $(u^{\prime },v^{\prime })$ are generated using $k_w$, $k_c$, and $k_{id}$ as follows:

$$(u,v)=(H_2(k_w,c),\mathrm{Enc}(k_{id},id)),$$

where the values of $(u,v)$ contain the mapping information between c and $id$ that is retrieved based on u and $k_{id}$.

$$(u^{\prime },v^{\prime })=(H_3(k_w,id),\mathrm{Enc}(k_c,c)),$$

where $(u^{\prime },v^{\prime })$ holds the encrypted state of the document with identifier $id$, and allows the client to check the states of deleted documents by sending $u^{\prime }$ in the $Search$ algorithm. The enclave adds each $(u,v)$ and $(u^{\prime },v^{\prime })$ to tuples $T_1$ and $T_2$, respectively, and sends $(T_1,T_2)$ to the server for updating $M_I$ and $M_c$. When a deletion update is invoked (i.e., op $=del$), the client simply sends $id$ to the enclave. On receipt of it, the enclave updates the list d by adding the received d to the list, and does not require further computations or communications with the server.

Algorithm 3 $Search\left(w\right)$

Client: 1: Send w to Enclave     Enclave: 2: $s{t}_{w_c}\leftarrow \{\varnothing \}$, $Q_w\leftarrow \{\varnothing \}$ 3: $k_w\parallel k_c\leftarrow F(k_{\Sigma },w)$ 4: foreach $i{d}_i$ in d do 5:     $f_i\leftarrow R\left[i{d}_i\right]$ 6:     $do{c}_i\leftarrow \mathrm{Dec}(k_f,f_i)$ 7:     if w in $do{c}_i$ then 8:         $D\left[w\right]\leftarrow i{d}_i\cup D\left[w\right]$ 9:     end if 10: end for 11: foreach $id$ in $D\left[w\right]$ do 12:     $u^{\prime }\leftarrow H_3(k_w,id)$ 13:     $v^{\prime }\leftarrow M_c\left[u^{\prime }\right]$ 14:     $c\leftarrow \mathrm{Dec}(k_c,v^{\prime })$ 15:     $s{t}_{w_c}^{del}\leftarrow \left\{c\right\}\cup s{t}_{w_c}^{del}$ 16: end for 17: $s{t}_{w_c}\leftarrow \{0,...,ST\left[w\right]\}\setminus s{t}_{w_c}^{del}$ 18: foreach c in $s{t}_{w_c}$ do 19:     $u\leftarrow H_2(k_w,c)$ 20:     $k_{id}\leftarrow H_1(k_w,c)$ 21:     with prob. p, $Q_w\leftarrow \left\{(u,k_{id})\right\}\cup Q_w$ 22: end for 23: send $Q_w$ to Server 24: receive $Q_{docId}$ from Server 25: foreach $i{d}_i$ in $Q_{docId}$ do 26:     if $sc=\perp$then$sc=1$ 27:     else 28:         $sc\leftarrow SC\left[i{d}_i\right]$ 29:         $SC\left[i{d}_i\right]\leftarrow sc+1$ 30:     end if 31:     if $id$ in $FD$ then 32:         $do{c}_i\leftarrow FD\left[i{d}_i\right]$ 33:     else 34:         $do{c}_i\leftarrow R\left[i{d}_i\right]$ 35:     end if 36:     add $do{c}_i$ to $Res$ 37: end for 38: Send $Res$ to Client 39: Update $FD$      Server: 40: receive $Q_w$ from Enclave 41: foreach $(u_i,k_{i{d}_i})$ in $Q_w$ do 42:     $i{d}_i\leftarrow \mathrm{Dec}(k_{i{d}_i},M_I\left[u_i\right])$ 43:     $Q_{docId}\leftarrow \left\{i{d}_i\right\}\cup Q_{docId}$ 44: end for 45: send $Q_{docId}$ to Enclave

In the $Search$ algorithm, when the client sends a query containing a keyword w to the enclave through a secure channel, the enclave begins with checking deleted documents in the list d. Specifically, all of the documents in d are loaded into the enclave. The enclave then decrypts them using $k_f$, and checks if the queried keyword w is included in any of them. If w exists in some documents, their document identifiers are updated to $D\left[w\right]$. After that, each $id$ in $D\left[w\right]$ allows retrieval of the state list $s{t}_{w_c}^{del}\supset \left\{c_{id}\right\}$, where $c_{id}$ refers to the state used when the document $id$ is added for keyword w. By excluding the states in $s{t}_{w_c}^{del}$ from the set of $\{0,\dots ,ST[w\left]\right\}$, the enclave obtains a state list $s{t}_{w_c}$ for the non-deleted documents. The enclave computes $|s{t}_{w_c}|$ number of encrypted index pairs $(u,k_{id})$s to form search query $Q_w$. Note that each pair $(u,k_{id})$ is added to $Q_w$ with probability p (typically, p will be close to 1), aiming to retrieve matching documents with false negatives of a small probability $(1-p)$. Therefore, it holds

$$Q_w\left[i\right]\sim \mathbf{Bern}\left(p\right),wherei\le \left|s{t}_{w_c}\right|.$$

(1)

The enclave sends $Q_w$ to the server. The server decrypts $M_I\left[u_i\right]$ with $k_{i{d}_i}$, stores obtained document identifiers in $Q_{docId}$, and sends $Q_{docId}$ to the enclave. After that, the enclave increments the search counter $SC\left[i{d}_i\right]$ of each matching document $i{d}_i$. When retrieving them, the enclave adds the corresponding encrypted documents to the search result $Res$ without accessing the untrusted area if they are stored in the frequently matched document map $FD$ to minimize the possibility of access pattern leakage to the server, or they are retrieved from the repository R located in the untrusted area, otherwise. Finally, the enclave sends $Res$ to the client and updates $FD$ based on the updated $SC$.

5. Security Analysis

In this section, we analyze the security of the proposed scheme, and prove that it guarantees forward and Type-II backward privacy.

$Setup$ leaks nothing to the server by leveraging a secure channel established by remote attestation. However, because the adversary can observe the interactions between its memory and the enclave during the search and update procedures, we consider the communications between them as information leakage in the proposed scheme. For addition, $Update$ leaks timestamp and memory access patterns when inserting new entries to the data structures $M_I,M_c,$ and R. For deletion, $Update$ does not reveal any information to the server because there is no interaction between the enclave and the server. In $Search$, the access patterns on $M_I$, $M_c$, and R are revealed to the server.

Definition 1 

(Obfuscated Search Pattern). The obfuscated search pattern ${\tilde{\Phi }}_{\overrightarrow{w}}$ is the vector characterized by Equation (2)

$${\tilde{\Phi }}_{\overrightarrow{w}}=(u_1,\dots ,u_{\left|i\right|}),\mathrm{where}i\le \left|s{t}_w\right|,$$

(2)

where u refers to the encrypted index or query token generated during the search.

Definition 2 

(Obfuscated Access Pattern). The obfuscated access pattern ${\tilde{\Pi }}_{\overrightarrow{w}}$ is the vector

$${\tilde{\Pi }}_{\overrightarrow{w}}=(i{d}_1,i{d}_2,\dots ,i{d}_{|i-|fd\left|\right|}),$$

(3)

where $\left|fd\right|$ refers to the number of documents retrieved from cached map $FD$.

We formulate the leakage function, and define ${\mathbf{Real}}_{\mathcal{A}}\left(\lambda \right)$ and ${\mathbf{Ideal}}_{\mathcal{A},\mathcal{S}}\left(\lambda \right)$ games for an adaptive adversary $\mathcal{A}$ and a polynomial time simulator $\mathcal{S}$. $\mathcal{D}$ denotes the proposed scheme, and the leakage function of $\mathcal{D}$ is

$$\mathcal{L}=({\mathcal{L}}^{Stp},{\mathcal{L}}^{Updt},{\mathcal{L}}^{Srch},{\mathcal{L}}^{hw}).$$

Note that the first three leakage functions define the information exposed in $Setup$, $Update$, and $Search$, respectively. ${\mathcal{L}}^{hw}$ refers to the inherent leakage of the enclave exposed during the interaction between the enclave and the server.

$Setup$ leaks nothing to the server, but the data structures of $M_I$, $M_c$, and R are revealed to the server during the initialization. $Update$ leaks information to the server only when op $=add$. The access pattern of encrypted entries is observed by the server when they are inserted to $M_I$, $M_c$, and R. When $op=del$, $\mathcal{D}$ leaks nothing to the server because there is no interaction between the enclave and the server. Therefore,

$${\mathcal{L}}^{Updt}(\mathrm{op},\mathrm{in})=(T_1,T_2,R\left[i{d}_i\right]).$$

$T_1$ is a tuple of $\left\{\right(u,v\left)\right\}$ that is inserted to $M_I$ (i.e., encrypted index), and $T_2$ is a tuple of $\left\{(u^{\prime },v^{\prime })\right\}$ that is inserted to $M_c$ (i.e., encrypted map of keyword states). $R\left[i{d}_i\right]$ refers to the encrypted document inserted with document identifier $i{d}_i$.

$Search$ leaks obfuscated search pattern ${\tilde{\Phi }}_{\overrightarrow{w}}$ when the enclave sends query tokens to the server, obfuscated access pattern ${\tilde{\Pi }}_{\overrightarrow{w}}$ when it retrieves the encrypted documents from the server, and the patterns on the deleted documents’ list $d_w$. ${\mathcal{L}}^{Srch}$ is defined as

$${\mathcal{L}}^{Srch}=({\tilde{\Phi }}_w,{\tilde{\Pi }}_w,d_w).$$

${\mathcal{L}}^{hw}$ includes hardware leakages observed during $Update$ and $Search$, such as memory access patterns, locations, timestamps, and manipulated memory areas for $M_I$, $M_c$, and R. ${\mathcal{L}}^{hw}$ is defined as

$${\mathcal{L}}^{hw}=({(M_I,M_c,R)}^{Updt},{(M_I,M_c,R)}^{Srch}).$$

${\mathbf{Real}}_{\mathcal{A}}\left(\lambda \right)$: As presented in Algorithm 1, the challenger performs $Setup\left(1^{\lambda }\right)$ to initialize data structures used by the client, the server, and the enclave. $\mathcal{A}$ selects a database $DB={\left\{do{c}_i\right\}}_{i\in \mathbb{N}}$ and performs a polynomial number of updates, where $\mathbb{N}$ is a natural number of documents. When the challenger runs $Update($op$,in)$, ${(M_I,M_c,R)}^{Updt}$ is returned to $\mathcal{A}$. After that, $\mathcal{A}$ selects a keyword w and performs $Search$. As a result of $Search\left(w\right)$, the challenger returns the transcript of each operation and outputs ${(M_I,M_c,R)}^{Srch}$ to $\mathcal{A}$. Finally, $\mathcal{A}$ outputs a bit b.

${\mathbf{Ideal}}_{\mathcal{A},\mathcal{S}}\left(\lambda \right)$: $\mathcal{A}$ selects a $DB={\left\{do{c}_i\right\}}_{i\in }$. $\mathcal{S}$ generates a tuple of $(M_I,M_c,R)$ by using ${\mathcal{L}}^{Updt}$ and ${(M_I,M_c,R)}^{Updt}$. Then, $\mathcal{S}$ sends the generated tuple to $\mathcal{A}$. $\mathcal{A}$ adaptively selects the keyword w to search. The transcript obtained by $\mathcal{S}\left({\mathcal{L}}^{Srch}\left(w\right)\right)$ is returned by the challenger. Finally, $\mathcal{A}$ returns a bit b.

For all probabilistic polynomial time algorithms $\mathcal{A}$, if there exists a PPT simulator such that

$$|Pr\left[{\mathsf{Real}}_{\mathcal{A}}\left(\lambda \right)=1\right]-Pr\left[{\mathsf{Ideal}}_{\mathcal{A},\mathcal{S}}\left(\lambda \right)=1\right]|\le negl\left(\lambda \right),$$

then $\mathcal{D}$ is $\mathcal{L}$-secure against adaptive chosen-keyword attacks.

Definition 3 

($\mathcal{L}$-security). Scheme $\mathcal{D}$ consists of three protocols: $Setup$, $Update$, and $Search$. ${\mathbf{Real}}_{\mathcal{A}}\left(\lambda \right)$ and ${\mathbf{Ideal}}_{\mathcal{A},\mathcal{S}}\left(\lambda \right)$ are probabilistic experiments, where $\mathcal{A}$ is a stateful adversary and $\mathcal{S}$ is a stateful simulator that gets the leakage function $\mathcal{L}$. $\mathcal{D}$ is $\mathcal{L}$-secure if $\mathcal{A}$ can distinguish ${\mathbf{Real}}_{\mathcal{A}}\left(\lambda \right)$ and ${\mathbf{Ideal}}_{\mathcal{A},\mathcal{S}}\left(\lambda \right)$ with negligible probability.

The scheme $\mathcal{D}$ is secure if it achieves both forward and Type-II backward privacy. Since the client issues a query on keyword w to the enclave through the secure channel, $\mathcal{A}$ has to generate a query token by itself in the game presented in Definition 3. Forward privacy is guaranteed because state $ST\left[w\right]$ increases when a new document containing w is inserted. The increase in state value constrains $\mathcal{A}$ to generate a query token to retrieve newly added documents. Regarding backward privacy, $\mathcal{A}$ can learn the timestamps indicating when the deleted states of w were added in $M_c$, when the enclave requests the server to access $M_c$ during $Search$, but $\mathcal{A}$ cannot know when they were actually requested for deletion. Scheme $\mathcal{D}$ caches deletion requests in the enclave and only accesses them during $Search$. Due to the obfuscation technique in the scheme, during the search on w, the enclave generates the query tokens and includes them with probability p. In other words, a false negative occurs with probability $1-p$, which probabilistically omits the query tokens in the result. Therefore, $\mathcal{A}$ is unable to identify whether the tokens are omitted due to deletion operations or false negatives. In addition, the enclave stores the most frequently retrieved document. Thus, if the matching document exists within the map $FD$, the enclave does not request the server to access R for those documents. As a result, $\mathcal{A}$ does not know which delete updates are conducted for specific document identifiers.

Theorem 1. 

Scheme $\mathcal{D}$ is $\mathcal{L}$-secure according to Definition 3.

Proof. 

We now prove Theorem 1 by illustrating a PPT simulator $\mathcal{S}$ for which $\mathcal{A}$, a PPT adversary, can distinguish ${\mathbf{Real}}_{\mathcal{A}}\left(\lambda \right)$ and ${\mathbf{Ideal}}_{\mathcal{A},\mathcal{S}}\left(\lambda \right)$ with negligible probability.

• $Setup$: $\mathcal{S}$ performs a random key generation $\tilde{K}=({\tilde{k}}_{\sigma },{\tilde{k}}_f)$ to simulate the key components provisioned inside the enclave.
• $Simulate$: $\mathcal{S}$ executes $Update$ on a random keyword w and obtains a query token q. Then, $\mathcal{S}$ performs an addition update for w based on $\tilde{K}$ and ${\mathcal{L}}^{hw}(M_I,M_c,R)$, and passes them to the enclave to receive the new update of $(M_I,M_c,R)$.
  However, $\mathcal{A}$ cannot classify which update tokens match q because the enclave keeps increasing the state $ST\left[w\right]$. Thus, $\mathcal{S}$ is unable to distinguish between the output of ${\mathbf{Real}}_{\mathcal{A}}\left(\lambda \right)$ and the simulated output in $Update$ and $Search$, guaranteeing forward privacy.
• $Simulate$: $\mathcal{S}$ executes $Search$ on a random keyword w. The encrypted documents in the deleted document list d stored in the enclave are only requested during $Search$. Thus, $\mathcal{S}$ is unable to specify the exact timestamp for deletion updates. When generating query token during $Search$, false negative occurs with rate $1-p$, causing probabilistic omission of query token via ${\tilde{\Phi }}_{\overrightarrow{w}}$. In addition, for generated query tokens, if the matching encrypted documents are cached within the enclave, those tokens are omitted from the result sent to $\mathcal{S}$ via ${\tilde{\Pi }}_{\overrightarrow{w}}$.
  When $\mathcal{A}$ compares the matching document identifier lists of the same query, ${\tilde{\Phi }}_{\overrightarrow{w}}$ and ${\tilde{\Pi }}_{\overrightarrow{w}}$ prevents $\mathcal{A}$ from learning information required for reconstructing the deletion history. However, $\mathcal{A}$ is able to learn the timestamps of the inserted entries related to specific $id$ via ${\mathcal{L}}^{hw}$. Hence, the scheme $\mathcal{D}$ guarantees Type-II backward privacy.

□

6. Implementation and Evaluation

In this section, we evaluate our scheme in comparison to those of Amjad et al. (Fort, Bunker-A, and Bunker-B) [8] and Vo et al. (SGX-SE1, SGX-SE2, Maiden) [11,12], which are state-of-the-art SGX-based DSSE schemes. The comparison results related to performance and security are shown in

Table 4. Comparison of SGX-based DSSE schemes.

Schemes	Computation		Communication		Backward Privacy Type
	Search	Update	Search	Update
Fort	$\mathcal{O}\left(n_w+{\Sigma }_w{d}_w\right)$	$\mathcal{O}\left({log}^{2}N\right)$	$\mathcal{O}\left(n_w\right)$	$\mathcal{O}\left(1\right)$	I
Maiden	$\mathcal{O}\left(n_w\right)$	$\mathcal{O}\left(1\right)$	$\mathcal{O}\left(n_w\right)$	$\mathcal{O}\left(1\right)$	I
Bunker-B	$\mathcal{O}\left(a_w\right)$	$\mathcal{O}\left(1\right)$	$\mathcal{O}\left(n_w\right)$	$\mathcal{O}\left(1\right)$	II
SGX-SE1	$\mathcal{O}\left(n_w+d\right)$	$\mathcal{O}\left(1\right)$	$\mathcal{O}\left(n_w\right)$	$\mathcal{O}\left(1\right)$	II
SGX-SE2	$\mathcal{O}\left(n_w+v_d\right)$	$\mathcal{O}\left(1\right)$	$\mathcal{O}\left(n_w\right)$	$\mathcal{O}\left(1\right)$	II
Proposed	$\mathcal{O}\left(n_w+d\right)$	$\mathcal{O}\left(1\right)$	$\mathcal{O}\left(n_w\right)$	$\mathcal{O}\left(1\right)$	II
Bunker-A	$\mathcal{O}\left(a_w\right)$	$\mathcal{O}\left(1\right)$	$\mathcal{O}\left(n_w\right)$	$\mathcal{O}\left(1\right)$	III

N: the total number of keyword/document pairs; W: the total number of keywords; $a_w$, $n_w$, d: the total number of entries (including all updates) performed on w, the number of non-deleted documents containing w, and the number of deleted documents, respectively; $v_d$: the vector of a bloom filter to check the membership of $\#d$ documents.

and

Table 5. Storage comparison.

Schemes	Storage
	Client	Enclave
Fort	$\mathcal{O}\left(WlogD\right)$	-
Maiden	$\mathcal{O}\left(\right(WlogD+$	-
	$a_w+N)$
Bunker-B	$\mathcal{O}\left(WlogD\right)$	-
SGX-SE1	-	$\mathcal{O}\left(WlogD+d\right)$
SGX-SE2	-	$\mathcal{O}\left(WlogD+|\overrightarrow{bf}|\right)$
Proposed	-	$\mathcal{O}\left(WlogD+d+\left|K\right|\right)$
Bunker-A	$\mathcal{O}\left(WlogD\right)$	-

N: the total number of keyword/document pairs; D: the total number of documents; W: the total number of keywords; $a_w$: the total number of entries (including all updates) performed on w; d: the number of deleted documents; $\overrightarrow{bf}$: the configurable bloom filter vector; K: the number of frequently searched documents cached in $FD$.

.

6.1. Implementation Setup

We implemented the prototype of our scheme in C++ using Intel SGX SDK 2.15.1 in a system with SGX-enabled Intel i5-8500 3.0 GHz, 16 GB RAM, and Ubuntu 18.04.5 LTS. Also, we used a synthetic dataset [11] consisting of 100,000 documents with a keyword frequency following the Zipf distribution.

The prototype utilizes cryptographic primitives in the SGX SDK for supporting cryptographic operations. We also used APIs provided by SDK to create, manage, and access the enclave. Note that the enclave is only allocated 96 MB memory [7], thus using memory more than 96 MB requires the paging mechanism [7]. As paging triggers extra overhead to the system, we leveraged batch processing during the search. In the experiment, we set the batch size to 1 × 10⁴ for all schemes. For large datasets, the size of the query token may be large; thus, by dividing the size of the search query to the multiple batches, we minimize the chances of a paging mechanism.

6.2. Performance

We now evaluate the performance of each scheme. In the evaluation, we compare our scheme mainly with SGX-SE1 and Bunker-B, because they are both designed using Intel SGX with the same assumptions and system environment. Bunker-B provides the same security level as the proposed scheme. Even though SGX-SE1 was originally designed to provide Type-II backward privacy with high efficiency, we prove it guarantees Type-II privacy partially. Although SGX-SE2 also provides the same level of backward privacy as SGX-SE1, it is a simple extension from SGX-SE1 adopting a bloom filter. Thus, SGX-SE2 is not considered in the performance evaluation.

6.2.1. Insertion and Deletion Time

We evaluate the time required for insertion and deletion updates. As shown in Table 4, both the computation and communication costs for update (i.e., addition and deletion) are $\mathcal{O}\left(1\right)$ in time complexity. However, when evaluated with real-world implementation using a synthetic dataset, there is a noticeable difference in efficiency. In the experiment, we measured the runtime for adding $1\times {10}^4$, $5\times {10}^4$, and $1\times {10}^5$ documents into the EDB in each scheme. As shown in Figure 3a, Bunker-B takes 881 ms, 4099 ms, and 8443 ms to insert $1\times {10}^4$, $5\times {10}^4$, $1\times {10}^5$ documents, respectively. SGX-SE1 takes 426 ms, 2221 ms, and 4340 ms, and the proposed scheme takes 341 ms, 1667 ms, and 3329 ms for each respective case, demonstrating the proposed scheme outperforms SGX-SE1 slightly. Compared to Bunker-B, both the proposed scheme and SGX-SE1 show significantly higher efficiency as the number of inserted documents increases.

For deletion, we evaluate the runtime by varying the portion of deletion from $1\times {10}^5$ documents: 25%, 50%, and 75%. As shown in Figure 3b, Bunker-B takes 2065 ms, 3907 ms, and 5885 ms to delete 25%, 50%, and 75% of documents, respectively. SGX-SE1 takes 164 ms, 319 ms, and 470 ms, and the proposed scheme takes 169 ms, 346 ms, and 480 ms for each respective case. It shows the proposed scheme and SGX-SE1 have almost the same computational overhead while significantly outperforming Bunker-B. This is mainly because the proposed scheme and SGX-SE1 implement the deletion process by simply inserting the $id$s of the documents to be deleted into a list, but Bunker-B actually deletes the documents from the EDB as in the insertion process.

6.2.2. Search Time

Now, we evaluate the search time or query delay of the proposed scheme. Because the proposed scheme caches frequently searched documents $FD$ within the enclave for obfuscation and faster retrieval, it is important to find the optimal size of $FD$. Figure 4a shows the search time of the proposed scheme with various sizes of $FD$. The search time decreases as the number of documents in $FD$ increases up to 200; but, when more than 250 documents are stored, the search time rather increases. We observed that this is mainly due to the limitation of the enclave memory, which triggers the paging mechanism more frequently to process the search query when it caches more than 250 documents. With the synthetic data with $1\times {10}^5$ documents, we set the optimal size of $FD$ as 200 which shows the average search time of 346 $\mathsf{\mu }$s.

Next, with the optimal size of $\left|FD\right|=200$, we compare the search time of the proposed scheme with those of Bunker-B and SGX-SE1. Figure 4b illustrates the search time when inserting $1\times {10}^5$ documents and deleting 50% of the documents. In the experiment, we select the top 20 frequent keywords to perform the $Search$ algorithm. For the top-20 frequent keywords, Bunker-B takes on average 9434 $\mathsf{\mu }$s to query, SGX-SE1 takes 203 $\mathsf{\mu }$s, and the proposed scheme takes 348 $\mathsf{\mu }$s. Because Bunker-B requires documents to be re-encrypted, it has a larger computational overhead of which computation complexity is $\mathcal{O}$. The proposed scheme requires on average 9086 $\mathsf{\mu }$s less search time (27× faster) than Bunker-B, while guaranteeing a similar level of security, on average 140 $\mathsf{\mu }$s more search time (1.7× slower) than SGX-SE1 due to the extra computations required to obfuscate access patterns on $M_I$ and R while providing higher security.

6.2.3. Storage Overhead

We can consider three storage types: client, server, and enclave. Among them, the server storage is used to store all of the data for data retrieval such as EDB, encrypted indices, and so on. Because it is a commonly required storage overhead in all of the schemes, we exclude the server storage when analyzing the storage overhead, and consider only the client and enclave storage, as shown in Table 5.

Among the three schemes, Bunker-B only requires $\mathcal{O}(WlogD)$ storage overhead on the client, without requiring enclave storage. In contrast, the proposed scheme and SGX-SE1 maintain persistent data structures for tracing the deleted documents and their mapping information with keywords within the enclave without incurring any storage overhead on the client. Specifically, SGX-SE1 requires $\mathcal{O}(WlogD+d)$ storage overhead on the enclave for storing the deleted document list d, and the mapping information D between the keyword and the deleted documents in d. The proposed scheme also requires the same enclave storage overhead as SGX-SE1, but requires additional storage for the frequently retrieved K-documents, $FD$, on the enclave.

6.2.4. Utility Loss

We evaluate the retrieval rate of our scheme with synthetic and real-world datasets.

Synthetic dataset. When generating a search token, we generate it with a probability (true positive rate) p close to 1. Hence, there should be the possibility of false negatives, leading to utility loss. In order to evaluate the utility loss, we insert $1\times {10}^5$ documents, delete 20% of the documents, and query the top 20 most frequent keywords by setting $p=0.9999$. We then repeat the above experiment 20 times and calculate the average rate of document retrieval. Figure 5a illustrates the retrieval rate when querying the ith most frequent keywords. In the experiment, the 14th and 1st most frequent keywords show the lowest and highest rates of 97.46% and 99.54%, respectively. On average, the proposed scheme retrieves 98.98% of the matching documents, showing a 1.02% utility loss.

Real-world dataset. We further evaluate the utility loss of the proposed scheme with a real-world Enron [15] email dataset. For the evaluation, we insert $3.14\times {10}^5$ documents, and delete $10\%$ of them. Identical to the previous evaluation with the synthetic dataset, we query the top 20 most frequent keywords and calculate the average rate of document retrieval after repeating the experiment 20 times. Figure 5b shows the retrieval rate when querying the ith most frequent keywords. In the experiment, the 3rd and 2nd most frequent keywords show the highest and the lowest retrieval rates of $99.49\%$ and $98.11\%$, respectively. On average, the proposed scheme retrieves $98.96\%$ of the matching documents, showing 1.04% utility loss, which is almost the same as the experimental result with the synthetic dataset.

Discussion. The utility loss is an inevitable trade-off for providing higher security without degrading the efficiency of the proposed scheme, as many of the other schemes adopt a differential privacy technique to obfuscate access and search patterns [24,25]. Even if the utility loss rate is very low (which is approximately 1% in the proposed scheme), the possibility of utility loss should affect the number of documents retrievable by the client. A simple solution to mitigate this problem is to add redundancy in the stored data or to send redundant queries for a single search. For example, Chen et al. scheme [24] adopted erasure code to add redundancy to the stored data. On retrieval, the encoded message can be reconstructed into its original one even though some parts of the message are lost. Therefore, the erasure coding method may be applied to our design scheme to eliminate utility loss. However, how to minimize such additional overheads further without incurring any utility loss while guaranteeing Type-II backward privacy is a challenging and open problem in the literature.

7. Related Work

Since the first proposal in 2000 [26], a number of searchable symmetric encryption (SSE) schemes have been proposed for formally defining the security model [3], improving efficiency [1,27], and supporting expressive queries [28,29]. Recently, several works have been introduced on how access pattern and search pattern leakages can be exploited by an adversary to break the security of SSE [17,30]. Cash et al. [30] exploited the search pattern leakages to recover the plaintext of the query or reconstruct the client’s indexed documents. Zhang et al. [17] introduced a file injection attack on SSE schemes that exploits access patterns on file identifiers to identify what specific file identifiers correspond to the maliciously injected file.

Another important research area in SSE is to support dynamic operations in SSE, which enables a client to perform keyword searches as well as update operations on the encrypted documents, known as dynamic symmetric searchable encryption (DSSE) [1,27]. Stefanov et al. [2] and Bost et al. [4,5] first introduced two fundamental security requirements for DSSE, that is, forward and backward privacy. Recently, Sun et al. [14] introduced a non-interactive forward and backward private DSSE method by constructing revocable encryption. Even though it could reduce the information leakage by making the deletions oblivious to the server, it allows additional information leakage such as the number of deleted documents and candidate timestamps of deletion updates, which can be further exploited by an adversary to violate the backward privacy via obtaining the deletion history. In addition, Vo et al. [11] proposed a Type-II backward private scheme by leveraging Intel SGX enclave as a server-side proxy and constructed a more efficient scheme than Amjad et al. Bunker-B [8]. Despite the improvement of its efficiency, the Vo et al. [11] scheme allows more information leakages than Bunker-B, which can be abused to violate its backward privacy. Therefore, accomplishing high efficiency while minimizing exploitable information leakage is still a challenging and open problem in DSSE literature.

8. Conclusions

In this paper, we first conduct a comprehensive analysis of Type-II backward privacy in the aspects of both theoretic definition and practical constructions. We then demonstrate how information leakage that is not covered by the current notions can be utilized to extract the deletion history from Type-II backward private schemes under specific conditions and violate their Type-II privacy in practice. Finally, we propose a novel forward and Type-II backward private DSSE scheme based on Intel SGX, and formally prove the security. The proposed scheme outperforms the previous works in either search latency or security level with negligible utility loss. To the best of our knowledge, this is the first work that investigates the importance of secondary information leakages that are not captured in traditional backward privacy notions and discusses their practical implications on the backward privacy schemes.