SPEKS: Forward Private SGX-Based Public Key Encryption with Keyword Search

Abstract

Public key encryption with keyword search (PEKS) enables users to search over encrypted data outsourced to an untrusted server. Unfortunately, updates to the outsourced data may incur information leakage by exploiting the previously submitted queries. Prior works addressed this issue by means of forward privacy, but most of them suffer from significant performance degradation. In this paper, we present a novel forward private PEKS scheme leveraging Software Guard Extension (SGX), a trusted execution environment provided by Intel. The proposed scheme presents substantial performance improvements over prior work. Specifically, we reduce the query processing cost from $O\left(n\right)$ to $O\left(1\right)$, where n is the number of encrypted data. According to our performance analysis, the overall computation time is reduced by 80% on average. Lastly, we provide a formal security definition of SGX-based forward private PEKS, as well as a rigorous security proof of the proposed scheme.

1. Introduction

Data outsourcing to cloud service providers is beneficial in terms of data management, but raises data security and privacy concerns. Encrypting data prior to outsourcing may solve the data privacy problems. However, it inevitably complicates, or sometimes hinders important data management operations such as searches over the outsourced data. Public key encryption with keyword search (PEKS) solves this dilemma, in which data senders are allowed to encrypt data using a public key such that the ciphertexts are searchable only by a data receiver whose secret key is associated with the public key [1].

Unfortunately, previous PEKS schemes are vulnerable to query leakage attacks. For example, in file injection attacks [2], an adversarial data sender generates maliciously crafted files of his choice, encrypts them with the public key of a data receiver, and then outsources it to the cloud storage. Then, the adversary observes file access patterns by monitoring which files are returned in response to queries submitted by a specific receiver, thereby leaking the receiver’s queries.

As a countermeasure, forward private PEKS schemes have been proposed, which can guarantee that the past search queries cannot be used for newly inserted files [3]. Unfortunately, the previous schemes are unsuitable for the multi-user environment where multiple data senders are existing for each receiver, which is the widespread setting in cloud-based applications (In this study, a multi-receiver environment is not considered. Thus, henceforth, a multi-user environment implies only a multi-sender environment in the paper). Thus, designing forward private PEKS that securely support multi-user setting in a scalable way is one of the challenging and important goals in the PEKS literature.

Moreover, prior works suffer from high communication overhead that degrades practicality. For example, Zhang et al. [4] achieved forward privacy by means of key revocation, which incurs costly key management tasks to distribute key update messages every time a query is processed. Zeng et al. [5] proposed a scheme to guarantee forward privacy without such key revocations. However, the scheme depends on computationally extensive cryptographic primitives, which incurs unacceptable computation costs in practice. Furthermore, the query size of their scheme depends on the time periods, leading to significant communication overheads.

To design secure and efficient schemes, one may utilize Trusted Execution Environments (TEEs) such as Intel Software Guard Extension (SGX) [6,7,8,9,10]. TEE provides memory isolation such that it loads data or code from (untrusted) main memory to the (trusted) isolated memory area, or enclave. Since TEE can protect data and processes from operating systems or hypervisors using enclaves, it can guarantee confidentiality and integrity of them even when operating systems or hypervisors are compromised. Recently, Amjad et al. [11] introduced an SGX-supported dynamic searchable symmetric encryption scheme that is forward private. However, it is also not applicable to the multi-user settings.

In this paper, we propose SPEKS, a forward private SGX-based public key encryption with keyword search scheme. To the best of our knowledge, it is the first SGX-based PEKS that achieves forward privacy in a multi-user setting. The proposed scheme uses a search counter to achieve forward privacy by unlinking the current data status with the previous queries. Specifically, both the data receiver and the cloud server share the same search counter, which is updated per each data update. Since the current data is encrypted using the latest search counter, the previous queries cannot be associated with subsequently updated data. Thus, forward privacy is guaranteed in the proposed scheme. In addition, SPEKS significantly outperforms prior works [4,5,12] and preserves forward privacy against stronger attack model by utilizing Intel SGX.

The contributions of this work are as follows:

• We propose a forward secure public key encryption with keyword search using Intel SGX, the first SGX-based PEKS scheme that achieves forward privacy in multi-user settings.
• The communication cost is significantly reduced as a single query is sufficient to search over multiple encrypted data, while prior works require numerous queries in proportional to the number of encrypted data.
• We define a security model of SGX-based forward private PEKS, and formally prove the security of our scheme.
• We implement our scheme using SGX, and evaluate the performance of our scheme and the previous schemes. According to the experiment with implementations, our scheme is significantly more efficient then the previous schemes without security degradation.

2. Background

Intel Software Guard Extension (SGX) is used for designing our construction for forward secure searchable encryption. SGX is an extension of the x86 instruction set architecture (ISA) introduced since the 6th generation Intel Skylake Processor. SGX provides Memory Isolation, Enclave Page Cache, and Software Attestation, which are major functionalities that we rely on to construct our scheme. In this section, we briefly introduce the SGX structures and basic PEKS algorithms upon which our scheme is built.

2.1. Intel Software Guard Extensions (SGX)

Memory Isolation. SGX platform can be divided into untrusted parts and trusted parts. Enclaves are trusted parts, or private regions of the physical memory whose contents are protected. The memory space for enclave is isolated from any process outside the enclave itself, including processes running at higher privilege levels. Thus, any access by other processes such as privileged operating systems, firmware, hypervisor and code in system management mode (SMM) to the enclave memory is disallowed.

The enclave memory is mapped into virtual memory of the untrusted part, and the untrusted part is executed on the ordinary process within the virtual address space. The mapping of the enclave memory is crucial, because this enables the enclave to access the host process’s entire virtual memory. However, the host process is only allowed to call enclave through certain interface. In addition, the executed code and data inside the enclave are encrypted when they reside in the untrusted part of the memory. When loaded into the enclave, on the other hand, the enclave is decrypted on the fly within the CPU. Thus, the processor protects the code from being examined by other processes, which treated as potentially hostile.

Enclave Page Cache (EPC): Enclave page cache (EPC) is memory area where the enclave code and data are placed. Using the Memory Encryption Engine (MEE), the EPC is encrypted and external reads on that memory bus can only monitor encrypted data. For EPC, a fixed amount of the main memory, limited to 128 MB, of the system is allocated to store enclave and related metadata. Since the dedicated memory is shared between enclave itself and related metadata, the enclave cache, on average, is able to use 96 MB [13]. Because of the memory limitation, enclaves sometimes need to swap pages when dealing with large data of which size exceeds the dedicated memory. During the boot phase, the SGX memory is reserved statically throughout the runtime of the system. If there are multiple enclaves, the memory is supposed to be dynamically managed by the OS and allocated to each enclave. When the page swapping occurs, the key generated at the boot-time is used for both encryption and decryption of the page. In the page swapping operations, confidentiality and integrity of the swapped-out pages can be guaranteed.

Software Attestation [14]: SGX supports software attestation feature that verifies the validity of locally or remotely created enclaves. The enclave measurement, which is the initial code loaded when the enclave is created, is used to verify the correctness of the enclave. Provided by the SGX attestation functionality, it can be assured that the measurements are authentic and associated with the benign enclave. For local attestation, EREPORT and EGETKEY instructions are used to generate the signed report and verify it at the target enclave. For remote attestation, the signature is provided by the Quoting Enclave (QE), a component of SGX. Before generating the signature, QE only accepts measurements from the hardware itself, which ensures that only legitimate enclave is measured.

2.2. Public Key Encryption with Keyword Search (PEKS)

Boneh et al. [1] first introduced the notion of public key encryption with keyword search (PEKS). Compared to symmetric searchable encryption, PEKS has better performance in data sharing. Abdalla et al. [15] gives a generic framework of PEKS and shows how to obtain public key based searchable encryption from anonymous identity-based encryption. In the PEKS scheme, a data receiver provides a gateway with a trapdoor function for keywords. Then, a data sender uses the data receiver’s public key for encrypting a keyword and sends the ciphertext to the server or the gateway. The latter applies search or test function to the search token and the ciphertext. When the keywords within the search token and the ciphertext match, the search or the test function returns 1; otherwise, 0. The scheme is proven to be secure in the standard model, but under the condition where the number of malicious clients is smaller than a specified value.

3. SPEKS Overview and Definitions

In this section, we describe a high level design of our SPEKS scheme, and show the search processes over encrypted data by users. Then, we define algorithms for SPEKS scheme and security model.

3.1. Overview

The high level design of our scheme is shown in Figure 1. In the proposed scheme, there are three system entities: data receiver (DR), data sender (DS), SGX-enabled cloud server (CS).

During the setup phase, a DR initially generates his private key $S{K}_u$, public key $P{K}_u$, and symmetric key $K_u$. Using the SGX attestation protocol for enclave authentication, the DR establishes a secure channel with the enclave within the CS (shown in step ① in Figure 1). After establishing the secure connection, the DR provisions $S{K}_u$ and $K_u$ into the enclave (step ①). The enclave stores two provisioned keys for future processes. When enclave is unloaded or rebooted, the provisioned keys can be securely stored in the local memory.

For the $PEKS$ algorithm, a DS gets search counter of the DR, encrypts data that includes predefined keyword with the search counter, and uploads the encrypted data to the server (see step ② and ③). Then, the DR generates a search query, encrypts it with symmetric key $S{K}_u$, and transfers it to enclave within the CS using the $Trapdoor$ algorithm (step ④). The enclave has provisioned keys required for decryption and the search query from the DR. For the $Search$ algorithm, the data record is loaded to the enclave (step ⑤). If the data record size is greater than the EPC, the record are separated into smaller pieces and partial records are loaded multiple times to the enclave. The enclave decrypts the search query using the symmetric key and searches the matching record (step ⑥). Finally, if there is a matched result, then the enclave returns the result to the DR (step ⑦).

3.2. Algorithms and Security Definitions

SPEKS consists of four polynomial-time algorithms: $SPEKS=(Setup(1^{\lambda },\lambda ),$$PEKS(P{K}_u,w,u,F),$$Trapdoor(K_u,w,sc\left[u\right]),$$Search(S{K}_u,\mathcal{R},t_w))$.

Definition 1. 

(SPEKS). A secure SPEKS is a tuple of four polynomial-time algorithms (Setup, PEKS, Trapdoor, Search) as follows:

• $(P{K}_u,S{K}_u,K)\leftarrow Setup(1^{\lambda },\lambda )$: It takes the security parameter $1^{\lambda }$ as input for generating a key pair for private key $S{K}_u$ and public key $P{K}_u$, and takes λ as input for generating symmetric key $K_u$.
• $t_w\leftarrow Trapdoor(K_u,w,sc\left[u\right])$: It takes the symmetric key $K_u$, keyword w, and search counter $sc\left[u\right]$ as input. It then outputs encrypted search token $t_w$.
• $\mathcal{R}\leftarrow PEKS(P{K}_u,w,u,F)$: It takes the public key $P{K}_u$, keyword w, user index u, and a set of data F as input. It then outputs a record $\mathcal{R}$.
• $(F/\perp )\leftarrow Search(S{K}_u,\mathcal{R},t_w)$: It takes the private key $S{K}_u$, record $\mathcal{R}$, and search token $t_w$ as input. It then outputs F if there is a match; otherwise, ⊥.

Definition 2. 

(Correctness) Let $\mathcal{D}$ denote a $SPEKS$-scheme consisting of the four algorithms described in Definition 1. For any correctly generated public key pair $\left(PK,SK\right)$ and symmetric K of the data receiver, and for any keyword w, $Search(S{K}_u,\mathcal{R},t_w)=1$ holds with probability 1, where ciphertext $\mathcal{R}\leftarrow PEKS(P{K}_u,w,u,F)$ and $t_w\leftarrow Trapdoor(K_u,w,sc\left[u\right])$.

We define our security model based on the three steps framework introduced in [16]. For the first step, we need to formulate a leakage which means an upper bound of the information that an adversary may gather from the protocol. Second step is defining the ${\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}$. ${\mathbf{Real}}_{\mathcal{A}}\left(\lambda \right)$ is the actual protocol and ${\mathbf{Ideal}}_{\mathcal{A}},\mathcal{S}\left(\lambda \right)$ is the simulated protocol for the real game by utilizing $\mathcal{S}$ using only the formulated leakage. Information learned in the previously executed protocols can be used by an adaptive adversary for its subsequent queries. Third step is proving that a scheme is CKA2-secure by showing that $\mathcal{A}$ can distinguish the outputs of the games with probability close to 0. When the probability is negligibly close to 0, $\mathcal{A}$ does not learn anything more than just the leakage stated in the first step.

Similar to the scheme introduced by Fuhry et al. [13], our scheme has an additional transaction between the cloud server and the trusted hardware, SGX. This additional transaction can be monitored by the adversary; therefore, we extended the original security model to hardware-security model. ${\mathcal{L}}_{hw}$ denotes the leakage on the CKA2-HW-security.

Definition 3. 

(CKA2-HW-security). Let $\mathcal{D}$ denote a $SPEKS$ scheme consisting of the four algorithms described in Definition 1. $\mathcal{A}$ is a stateful passive adversary, and $\mathcal{S}$ is a stateful simulator that gets the leakage functions ${\mathcal{L}}_{PEKS}$ and ${\mathcal{L}}_{hw}$. Two probabilistic experiments ${\mathbf{Real}}_{\mathcal{A}}\left(\lambda \right)$ and ${\mathbf{Ideal}}_{\mathcal{A}},\mathcal{S}\left(\lambda \right)$ are described as a follow.

• ${\mathbf{Real}}_{\mathcal{A}}\left(\lambda \right)$: The data receiver runs $Setup\left(1^{\lambda },\lambda \right)$ and generates a key pair $\left(PK,SK\right)$ and symmetric key K. $\mathcal{A}$ outputs a search counter of user, $sc\left[u\right]$. The data sender calculates $\mathcal{R}\leftarrow PEKS(P{K}_u,w,u,F)$ and passes $\mathcal{R}$ to $\mathcal{A}$. The data receiver returns search token $t_w$ to $\mathcal{A}$ after calculating $t_w\leftarrow Trapdoor(K_u,w,sc\left[u\right])$. $\mathcal{A}$ can use $\mathcal{R}$ and the returned tokens at any time to make a query to the trusted hardware. The trusted hardware answers the query by running $(F/\perp )\leftarrow Search(S{K}_u,\mathcal{R},t_w)$. If the query matches, then the search counter is incremented and $\mathcal{A}$ returns a bit $\mathrm{b}$ as a result of the experiment.
• ${\mathbf{Ideal}}_{\mathcal{A}},\mathcal{S}\left(\lambda \right)$: The adversary $\mathcal{A}$ outputs search counter $sc$ to the data sender. Using ${\mathcal{L}}_{PEKS}$, the data sender creates $\mathcal{R}$ and sends it to $\mathcal{A}$. The simulator $\mathcal{S}$ creates search token $t_w$ and passes it to $\mathcal{A}$. $\mathcal{A}$ can use $\mathcal{R}$ and search token $t_w$ to make queries to $\mathcal{S}$, who simulates the trusted hardware. Next, with the given ${\mathcal{L}}_{hw}$, $\mathcal{S}$ returns the search result. At last, the adversary $\mathcal{A}$ returns an output bit $\mathrm{b}$ of the experiment.

We claim that $\mathcal{D}$ is $\left({\mathcal{L}}_{PEKS},{\mathcal{L}}_{hw}\right)$-secure against adaptive chosen-keyword attacks if for any probabilistic, polynomial-time algorithms $\mathcal{A}$, there exists a probabilistic, polynomial-time $\mathcal{S}$ such that:

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

4. Construction

4.1. Cryptographic Primitive

Let $En{c}_{PKE}$ and $De{c}_{PKE}$ refer to IND-CPA secure public key encryption and decryption algorithm respectively, and $En{c}_{SKE}$ and $De{c}_{SKE}$ refer to IND-CPA secure symmetric key encryption and decryption algorithm respectively. The proposed scheme is constructed based on these symmetric and public key encryption/decryption algorithms.

4.2. Provisioning

For key sharing between the enclave and the data receiver, the data receiver provisions his private key and symmetric key to the enclave. Since the keys should not be revealed to any untrusted entity, secure connection between the data receiver and the enclave should be established using the attestation feature of SGX. During the creation of the enclave, the key pair $\left(s{k}_E\right)$ and $\left(p{k}_E\right)$ are created. The hardware random number generator (rdrand [17]) available in current CPUs can provide the sufficient randomness required for the key generation in practice.

Subsequently, the enclave sends the created $p{k}_E$ to the quoting enclave (QE). The QE creates the signature used for verification of the measurement of the initial memory content of the enclave $M_E$ and the public key ${\sigma }_{QE}(M_E\Vert p{k}_E)$. With the given Intel’s public key, the data receiver verifies the signature of $M_E$, $p{k}_E$, and ${\sigma }_{QE}(M_E\Vert p{k}_E)$. The data receiver is now able to encrypt $S{K}_u$ and $K_u$ with $p{k}_E$ and sends them back to the enclave. As a result, the enclave and the data receiver share the $S{K}_u$ and $K_u$, which they use for secure communication.

4.3. Algorithms

The proposed forward secure searchable encryption scheme with keyword search (SPEKS) consists of the following four algorithms: (Setup, PEKS, Trapdoor, Search).

Algorithm 1 gives a formal description of Setup of our SPEKS scheme. In $(P{K}_u,S{K}_u,K)\leftarrow Setup(1^{\lambda },\lambda )$ algorithm, a data receiver (DR) generates $P{K}_u$, $S{K}_u$, and $K_u$. Next, the DR provisions the $S{K}_u$ and $K_u$ to the enclave within the cloud server, $Enclav{e}_{CS}$, through a secure channel. The secure channel can be established by the attestation feature provided by Intel SGX as explained in Section 4.2.

Next, Algorithm 2 provides a formal description of PEKS. In $\mathcal{R}\leftarrow PEKS(P{K}_u,w,u,F)$, where F denotes a set of data, a data sender (DS) first requests search counter $sc\left[u\right]$ from the cloud server (CS). Using the retrieved $sc\left[u\right]$, the DS runs $En{c}_{PKE}$($P{K}_u$,($w,sc\left[u\right]$)) and generates searchable ciphertext $ct$. A record $\mathcal{R}$ consists of three components $\left(d,ind,ct\right)$, where d refers to the data, $ind$ refers to the index, and $ct$ refers to the searchable ciphertext. The generated record $\mathcal{R}$ is sent to the CS.

Algorithm 3 describes the Trapdoor algorithm of our scheme. In the algorithm, the DR creates a search token with the keyword. Specifically, in the execution of $t_w\leftarrow Trapdoor(K_u,w,sc\left[u\right])$, the DR uses the search counter $sc\left[u\right]$ and keyword, and generates the search token. Then, using symmetric key encryption (SKE), the DS encrypts the search token with symmetric key K. The encrypted search token $t_w$ is now transferred to Enclave${}_{CS}$. After transferring the search token, the DR increments his or her own search counter by 1.

Algorithm 4 describes the Search algorithm of our scheme. In Algorithm 4, Enclave ${}_{CS}$ checks whether search token $t_w$ matches $\mathcal{R}$. Enclave${}_{CS}$ runs $De{c}_{SKE}\left(K_u,t_w\right)$ and retrieves keyword $w^{\prime }$ and search counter $s{c}^{\prime }$. Next, using the key $SK$, keyword w and search counter $sc$ are retrieved from the ciphertext $c{t}_i$. The $in{d}_i$ from $\mathcal{R}$ is returned. $sc\left[u\right]$ is then incremented by one, and F with returned $in{d}_i$ is returned to the DR, when matched; else, ⊥ is returned.    

Algorithm 1:$(P{K}_u,S{K}_u,K)\leftarrow Setup(1^{\lambda },\lambda )$

DR:

$(P{K}_u,S{K}_u)\leftarrow Setup\left(\lambda \right)$

Symmetric key $K_u\leftarrow Setup\left(1^{\lambda }\right)$

Provision Private Key $S{K}_u$

and Symmetric $K_u$ to $Enclav{e}_{CS}$

Algorithm 2:$\mathcal{R}\leftarrow PEKS(P{K}_u,w,u,F)$

DS:

Request the search counter of u from the CS

CS:

Return $sc\left[u\right]$ to DS

DS:

for $i=1$ to $\left|F\right|$ do

$c{t}_i$← Enc${}_{PKE}$($P{K}_u$,($w,sc\left[u\right]$))

$\mathcal{R}$←$\mathcal{R}$ ∪ $\left\{\left(d_i,in{d}_i,c{t}_i\right)\right\}$

end for

Transfer $\mathcal{R}$ to CS

CS:

for $i=1$ to $\left|\mathcal{R}\right|$ do

$ED$←$ED$ ∪ $\left\{\left(d_i,in{d}_i,c{t}_i\right)\right\}$

end for

Algorithm 3:$t_w\leftarrow Trapdoor(K_u,w,sc\left[u\right])$

DR:

${\tau }_w\leftarrow \left(w,sc\left[u\right]\right)$

$t_w\leftarrow En{c}_{SKE}(K_u,{\tau }_w)$

Transfer $t_w$ to $Enclav{e}_{CS}$

$sc\left[u\right]\leftarrow sc\left[u\right]+1$

Algorithm 4:$(F/\perp )\leftarrow Search(S{K}_u,\mathcal{R},t_w)$

CS:

Enclave${}_{CS}$:

$\left(w^{\prime },s{c}^{\prime }\right)\leftarrow De{c}_{SKE}\left(K_u,t_w\right)$

for i=1 to sc’ do

$\left(w,sc\right)\leftarrow De{c}_{PKE}\left(S{K}_u,c{t}_i\right)$

if $\left(w=w^{\prime }\right) \mathrm{and} \left(i=sc\right)$ then

return $in{d}_i$

end if

end for

$sc\left[u\right]\leftarrow sc\left[u\right]+1$

Return F to DR if match; else, ⊥

5. Analysis

5.1. Security Analysis

We will prove the security of our scheme by defining the leakage functions related to access pattern. Then, we will explain how our SPEKS scheme guarantees the forward privacy.

We define two leakage functions: ${\mathcal{L}}_{PEKS}\left(sc\right)$ and ${\mathcal{L}}_{hw}\left(sc,\mathcal{R}\right)$. ${\mathcal{L}}_{PEKS}\left(sc\right)$ function outputs a record $\mathcal{R}$ given the search counter $sc$, which consists of encrypted data, indices, and searchable ciphertexts. Given $sc$ and $\mathcal{R}$, ${\mathcal{L}}_{hw}\left(sc,\mathcal{R}\right)$ function outputs the access pattern $\mathcal{P}\left(sc,\mathcal{R}\right)$.

The access pattern $\mathcal{P}\left(sc,\mathcal{R}\right)$ contains information of search counter $sc$ and records $\mathcal{R}$, which are stored in the untrusted memory region of the server. When the data receiver requests $sc$, the server can see which value is being returned. $\mathcal{R}$ also leaks which record is being sent to enclave or the data receiver. In our analysis, we further utilize values access pattern $\Delta \left(sc,\mathcal{R}\right)$ [13], which, in our analysis, describes the pointers to the result values that specifically points the record with index $ind$.

Theorem 1. 

(Security). The SPEKS construction is $\left({\mathcal{L}}_{PEKS},{\mathcal{L}}_{hw}\right)$-secure.

Proof. 

We consider a polynomial-time simulator $\mathcal{S}$ for which probabilistic, polynomial-time adversary $\mathcal{A}$ can distinguish between ${\mathbf{Real}}_{\mathcal{A}}\left(\lambda \right)$ and ${\mathbf{Ideal}}_{\mathcal{A}},\mathcal{S}\left(\lambda \right)$ with negligible probability.

• Setup: $\mathcal{S}$ creates a new random keys $\left(\widetilde{PK},\widetilde{SK},\tilde{K}\right)=Setup(1^{\lambda },\lambda )$ and stores them.
• Simulating$\mathcal{R}$: $\mathcal{S}$ gets ${\mathcal{L}}_{PEKS}$ and receives search counter $\mathsf{sc}$. Furthermore, $\mathcal{S}$ creates $\left|F\right|$ (the size of data set) encryption of keyword $\mathrm{C}=\left({\mathrm{C}}_1,...,{\mathrm{C}}_{\left|F\right|}\right)$ using $En{c}_{PKE} \left(PK,\left(w,sc\right)\right)$. All encrypted value is given a distinct index value $ind$. $\mathcal{S}$ outputs $\mathcal{R}=\left(in{d}_i,{\mathrm{C}}_i\right)$. Since the value of search counter and the size of the record are included in the leakage, the operations above are possible. The simulation of $\mathcal{R}$ has the same size with the output of ${\mathbf{Real}}_{\mathcal{A}}\left(\lambda \right)$. In addition, the simulation result is indistinguishable from the output of ${\mathbf{Real}}_{\mathcal{A}}\left(\lambda \right)$ due to IND-CPA-security of public key encryption scheme.
• Simulating$t_w$: The simulator $\mathcal{S}$ creates value ${\tau }_w=\left(w,sc\right)$ and encrypts it as $En{c}_{SKE}(K_u,{\tau }_w)$. $\mathcal{S}$ outputs search token $t_w$. Since $En{c}_{SKE}$ is IND-CPA secure, the simulated $t_w$ is indistinguishable from the output of ${\mathbf{Real}}_{\mathcal{A}}\left(\lambda \right)$.
• Simulating secure hardware: At a given time t, $\mathcal{S}$ receives search token and ${\mathcal{L}}_{hw}$. $\mathcal{S}$ uses $\mathcal{P}\left(sc,\mathcal{R},t\right)$ to simulate the access pattern. $\mathcal{S}$ begins with the first record of $\mathcal{P}$ and follows the indices given by $\mathcal{R}$. The leakage $\Delta$ determines the specific point of the record with index $ind$. □

The adversary $\mathcal{A}$ cannot distinguish access of ${\mathbf{Real}}_{\mathcal{A}}\left(\lambda \right)$ from simulated access due to the delivering of deterministic results. The results are consistent for each different requests made for the same keyword. Since $\Delta \left(sc,\mathcal{R}\right)$ is explicit, the number of result pointers matches and the pointers are also consistent. The pointed values are indistinguishable, because those values are encrypted IND-CCA secure.

Forward Privacy. In order to guarantee forward privacy, the past search queries should not be directly associated with the updated files. In our SPEKS scheme, we use a search counter that is supposed to be updated after each search. The search queries are generated only with private key and the search counter. Since the ciphertexts are created with the current newly updated search counters, past queries generated with past search counter values cannot match with newly updated files. Therefore, forward privacy is guaranteed in our proposed scheme.

5.2. Performance Analysis

In this section, we analyze the performance of our scheme and provide a comparative analysis with previous forward secure public key encryption with keyword search (FS-PEKS) schemes such as Zeng at al.’s [5] and Kim et al.’s [12] schemes.

Our experiment is run on a system equipped with Intel(R) Core(TM) i7-9700K CPU at 3.60 GHz, 16G DDR4 RAM. 64-bit Ubuntu 18.04.4 LTS with enabled SGX is used as an operating system. Our scheme is implemented based on Intel’s Software Guard Extension (SGX) Software Development Kit (SDK).

When considering the multi-user environment, it is important to evaluate the initial costs for key setup and key management. In order for general symmetric searchable encryption (SSE) schemes to support a multi-user environment, they need to set up the key multiple times in proportion to the number of users. For instance, if we define u as the number of data senders and $\left|DH\right|$ as the initial cost of Diffie–Hellman key exchange protocol between a data sender and a data receiver, then the initial cost for the key setup is

$$\left(initialkeysetupcost\right)=u·\left|DH\right|.$$

However, the proposed scheme does not require key exchange protocol for each data sender, thus the key setup cost remains constant.

Furthermore, since the data receiver also needs to manage each key corresponding to each data sender, storage overhead for storing the key is also increased in proportion to the number of data senders in the previous schemes. For the key management, SSE schemes require a data receiver to store all of the keys set up for data senders. If $\left|K\right|$ refers to the size of a key, the overall storage overhead is

$$\left(storagecost\right)=u·\left|K\right|.$$

Whereas, our scheme does not require a data receiver to store multiple keys for each sender. Therefore, our scheme has constant storage overhead for key management regardless of the number of data senders, which shows high scalability of our scheme in the multi-sender environment.

Computation overhead: As shown in Figure 2, the proposed scheme has lower computation cost compared to those of Kim et al.’s and Zeng at al.’s schemes. Specifically, for $PEKS$ algorithm, while Kim at al.’s scheme takes 3.958 ms and Zeng at al.’s takes 8.123 ms, our scheme takes just 0.0919 ms, which is significantly less overhead. Next, for generating a search token using $Trapdoor$ algorithm, our scheme takes 0.02 ms, which is constant independently of the search count. However, in Kim et al.’s scheme [12], it takes 4.85 ms for a single search token, and the computational cost increases in proportion to the number of search counters. Zeng at al.’s scheme takes 12.11 ms for running $Trapdoor$, which is orders of magnitude slower than ours. In addition, for the $Search$ algorithm, as shown in

Table 1. Efficiency comparison of public key encryption with keyword search (PEKS) schemes. ($\left|sc\right|$ refers to the value of search counter, $n_d$ refers to the number of data, $\left|id\right|$ refers to size of identifier, $\left|S\right|$ denotes number of searches made, $\left|T\right|$ denotes a set of encoded time period.)

Scheme	Search Time	Query Size	Index Size
Zeng et al. [5]	$O\left(\left|T\right|·n_d\right)$	$O\left(\left|T\right|\right)$	$O\left(n_d\right)$
Kim et al. [12]	$O\left(\left|sc\right|·n_d\right)$	$O\left(\left|sc\right|\right)$	$O\left(n_d+\left|id\right|\right)$
Our scheme	$O\left(\left|sc\right|·n_d\right)$	$O\left(1\right)$	$O\left(n_d\right)$

, it has the same complexity as our scheme in terms of the search time. However, when measuring the actual computation time in practice, the $Search$ algorithm of ours takes, in average, 0.0436 ms, while the computation cost of search process in [5] depends on a set of encoded time period. This causes unnecessary computational overhead for some cases. The search algorithm in Kim et al.’s scheme takes 0.863 ms as shown in Figure 2.

This reduction in computation cost is caused by the characteristic of the trusted execution environment, especially Intel SGX in our scheme. Previous PEKS schemes [5,12] are constructed based on the pairing based cryptographic operations which leads to high computation overhead. For instance, in $Trapdoor$ algorithm, our proposed scheme uses AES-GCM that is included in the SGX SDK for encryption and decryption of search query. Compared to pairing-based operations, AES-GCM is much more efficient cryptographic primitive. In addition, For $Search$ algorithm, previous schemes utilize the pairing-based cryptography for searching over ciphertext. RSA or Elliptic Curve Cryptography cannot be used in such software-only based schemes, because the comparison over ciphertexts for search is not possible. However, the trusted execution environment provided by SGX enables the search process over plaintext while still guaranteeing the data privacy.

Communication overhead: As the previous revocation-based FS-PEKS scheme [4], most of the search counter-based schemes including Kim et al.’s scheme [12] generate multiple search tokens. To be specific, since public and private keys are revoked for each search phase, revocation-based FS-PEKS scheme needs to create multiple search tokens for previous ciphertext, and the size of the token depends on the number of searches made beforehand. Such an overhead becomes devastating as a number of searches are made subsequently. For instance, after 1000 searches, data receiver needs to generate 1000 search tokens. Moreover, the revocation-based approach leads to sending re-encrypted data, incurring an additional communication overhead. Likewise, Kim et al.’s scheme [12] generates a number of search tokens as the search counter increases, shown in Figure 3. Therefore, communication overhead related to the query size depends on the number of search counters. As shown in Table 1, the query size is $O\left(1\right)$ in our scheme because it requires only a constant number of search tokens regardless of the search counter. However, in Kim et al.’s scheme [12], the number of generated search tokens increases as the search counter increases. Zeng at al,’s scheme, on the other hand, does not adopt counter-based mechanism, but still creates multiple search tokens for the search operations. As shown in Table 1, communication overhead related to query size in Zeng et al.’s scheme depends on the encoded time period. However, unlike the other previous schemes, our scheme only generates a single token regardless of the number of search counters, thus the proposed scheme is more scalable in practice.

Overall, the proposed scheme significantly outperforms previous FS-PEKS schemes and achieves better security by exploiting trusted execution environment, specifically Intel SGX in our scheme.

6. Related Work

In this section, we introduce the previous searchable encryption schemes and trusted execution environment (TEE).

6.1. Searchable Encryption

After the first searchable encryption (SE) was proposed by Song et al. [18], SE has been continuously studied to extend its functionality. Generally, the existing SE schemes can be classified into two types: searchable symmetric encryption (SSE) and public key encryption with keyword search (PEKS). By utilizing the symmetric key primitives [18,19,20,21], SSE schemes are generally more efficient than PEKS schemes. However, SSE schemes are not suitable for multiple data sender environments. PEKS schemes, based on the public key primitives [22,23], was first introduced by Boneh et al. [1], and it suits for multiple data sender environment due to the efficient key management. In PEKS schemes, generally, a data sender generates searchable ciphertext with a specific user’s public key. Then, the data receiver creates a search queries and retrieves the data with secret key.

6.2. TEE Based Implementations

Fisch et al. [24] first introduced functional encryption scheme using Intel SGX and formally defined the security model. Since the first adoption of Intel SGX, many studies have been made to construct encryption schemes on Intel SGX platform. Fuhry et al. [13] used Intel SGX to design HardIDX, which is an encrypted database index. The functionality of search operation is implemented inside the enclave, but does not support the update operation. In addition, Zerotrace [25] proposed generic efficient ORAM primitives using Intel SGX, and Oblix [26] was designed for oblivious search. In Oblix, update process is designed to minimize the leakage of access pattern and result size of searches. Harnessing TEE such as Intel SGX as a building block for SE scheme construction is an effective way to increase efficiency and security of the schemes in practice.

7. Conclusions

In this paper, we proposed a public key encryption with keyword search scheme guaranteeing forward privacy using Intel SGX. We formally defined a security model for the proposed TEE-based scheme. Compared with the previous schemes, our scheme shows significantly higher efficiency because the proposed scheme generates a single search token regardless of conditions; while the previous schemes require multiple search tokens. Furthermore, the proposed scheme requires significantly less computation time for creating indices, generating search tokens, and searching processes.

Our scheme considers only a multi-sender environment. Extending our scheme to the multi-receiver environment is another important and challenging issue. In addition, preserving resilience against de-synchronization attack is also an important open problem in most of the cryptographic protocols or algorithms based on shared secret information such as IV (initial vector) or counter information. Since most of the forward secure PEKS schemes are constructed based on counter values, how to make an efficient countermeasure against the de-synchronization attack over the shared counter value is also a challenging topic in the PEKS literature as an important future work.