Content uploaded by Alex Bakas
Author content
All content in this area was uploaded by Alex Bakas on Jul 16, 2020
Content may be subject to copyright.
Power Range: Forward Private Multi-Client
Symmetric Searchable Encryption with Range
Queries Support
Alexandros Bakas∗, Antonis Michalas∗†
∗Tampere University
{alexandros.bakas, antonios.michalas}@tuni.fi
†RISE Research Institutes of Sweden
Abstract—Symmetric Searchable encryption (SSE) is an en-
cryption technique that allows users to search directly over their
outsourced encrypted data while preserving the privacy of both
the files and the queries. In this paper, we present Power Range
– a dynamic SSE scheme (DSSE) that supports range queries in
the multi-client model. We prove that our construction captures
the very crucial notion of forward privacy in the sense that
additions and deletions of files do not reveal any information
about the content of past queries. Finally, to deal with the
problem of synchronization in the multi-client model, we exploit
the functionality offered by Trusted Execution Environments and
Intel’s SGX.
Index Terms—Cloud Security, Forward Privacy, Multi-Client,
Range Queries ,Symmetric Searchable Encryption
I. INTRODUCTION
Symmetric Searchable Encryption (SSE) is among the most
promising encryption techniques that can pave the way to
truly secure and privacy-preserving cloud-based services. SSE
schemes aim to provide confidentiality and integrity, while re-
taining main benefits of cloud storage – availability, reliability,
and ensuring requirements through cryptographic guarantees
rather than administrative controls. SSE allows a client to
securely outsource private data to a cloud service provider
(CSP) in such a way that she can later perform keyword
searches directly on the stored ciphertexts. To perform a
search, a user sends a query for a specific keyword wto the
CSP. The CSP can then find all stored ciphertexts containing w
without revealing any valuable information about the contents
of the files or the keyword wthat user searched for. Ideally,
an SSE scheme should leak no information at all to the CSP.
To achieve this, techniques such as oblivious RAM (ORAM)
need to be used and according to [1], it is even less efficient
than downloading and decrypting the entire database. Leaked
information is a problem of paramount importance in SSE
since even a small leakage can lead to attacks that violates
user’s privacy [2]. For example, in [3] authors assumed that a
malicious adversary can add new files and showed that after
ten file injections an adversary was able to violate users’
privacy by revealing the contents of a past query. In this
paper, we extend the work presented in [4] by designing
a forward private dynamic SSE scheme in the multi-client
model. Forward privacy is achieved if for all file insertions
that take place after the initial setup of the SSE scheme, the
leakage is limited to the number of distinct keyword of the
file and the size of the file.
Contribution:The contribution of this paper is twofold.
First, we extend the work proposed in [4] in the multi-client
setting. Preserving the notion of forward privacy in the multi-
client setting has turned out to be a very challenging problem.
This is due to the fact that in every search operation, a different
keyword key is used. Thus, we need to make sure that at any
given time, all the users are synchronized and can use the
correct key. To achieve synchronization between multiple users
we leverage the functionalities offered by Intel’s SGX [5].
Then, based on [6] we design two different mechanisms that
can be used to enhance our construction with range queries
support. While our range queries mechanisms have obvious
limitations, to the best of our knowledge, this work is the first
forward private SSE scheme with range queries support in the
multi-client setting.
II. RE LATE D WORK
In [7], authors designed a number of SSE schemes that
support range queries. The best trade-off between security
and efficiency is achieved by the Logarithmic-SRC-i scheme
which achieves O(R+`)search time, where Ris the range
of the query and `is the result of the query. Even though it
is a promising approach, their construction returns O(R+`)
false positives which is an important drawback. They tried
to catch the notion of forward privacy by extending their
construction to support file additions and deletions. To do so,
the data owner must periodically download the indexes, re-
encrypt them and outsource them again. In [8] authors present
HardIDX, a scheme that supports range queries with the use
of SGX. While HardIDX minimizes the leakage by hiding the
search pattern it is static. Hence, even if the scheme achieves
logarithmic search cost, a direct comparison with dynamic
schemes is not possible. In [9], authors presented sophos;
asingle-client forward private SSE scheme. While Sophos
achieves asymptotically optimal search and update costs, O(`)
and O(m)respectively, where mdenotes the number of unique
keywords in a file, it requires O(m)asymmetric cryptographic978-1-7281-8086-1/20/$31.00 ©2020 IEEE
operations on the user’s side. Additionally, the scheme does
not support range queries and only works in a single-client
setup. Another possible solution to the problem of efficient
range queries is the so called order revealing encryption
(ORE). ORE is a single-client encryption technique that allows
direct comparison of two ciphertexts yielding the order of
the plaintext. This notion was first introduced in [10] where
a construction based on multi-linear maps was presented.
However fascinating, such an approach is impractical for
realistic scenarios. An improved version of ORE was presented
in [11] where each search query requires time linear to the total
number of ciphertexts. However, the scheme does not offer
forward privacy and does not support indexing – a necessary
artifact for building a robust SSE scheme.
III. NOTATIO N AN D SECURITY DEFI NI TIONS
Let Xbe a set. We use x← X if xis sampled uniformly
form Xand x$
←− X , if xis chosen uniformly at random. If X
and Yare two sets, then we denote by [X,Y]all the functions
from Xto Yand by [X,Y]all the injective functions from X
to Y.R(·)is used for a truly random function, while R−1(·)
represents the inverse function of R(·). A function negl(·)
is called negligible, if ∀n > 0,∃Nnsuch that ∀x>Nn:
|negl(x)|<1/poly(x). If s(n)is a string of length n, we
denote by s(l)its prefix of length land by s(l), its suffix of
length l, where l < n. A probabilistic polynomial time (PPT)
adversary ADV is a randomized algorithm for which there
exists a polynomial p(·)such that for all input x, the running
time of ADV(x)is bounded by p(|x|). A file collection
is represented as f= (f1, . . . , fz)while the corresponding
collection of ciphertexts is c= (cf1, . . . , cfz). The universe
of keywords is denoted by w= (w1, . . . , wk)and the distinct
keywords in a file fiare wi= (wi1, . . . , wi`). An invertible
pseudorandom function [12] is defined as follows:
Definition 1 (Invertible Pseudorandom Function (IPRF)).An
IPRF with key-space K, domain of definition Xand range
Yconsists of two functions G: (K × X )→ Y and G−1:
(K×Y)→ X ∪ {⊥}. Moreover, let G.Gen(1λ)be an algorithm
that given the security parameter λ, outputs KG∈ K. The
functions Gand G−1satisfy the following properties:
1) G−1(KG, G(k, x)) = x, ∀x∈ X .
2) G−1(KG, y) =⊥if yis not an image of G.
3) Gand G−1can be efficiently computed by deterministic
polynomial algorithms.
4) G(KG,·)∈[X,Y], G−1(KG,·)∈[Y,X]
A function G: (K ×X )→ Y is an IPRF if ∀PPT adversary
A:
|P r[KG←G.Gen(1λ) : AG(KG,·),G−1(k,·)(1λ) = 1]
−P r[K00$
←− [X,Y] : AR(·),R−1(·)(1λ) = 1|=negl(λ)
Definition 2 (DSSE Scheme).A Dynamic Symmetric Search-
able Encryption (DSSE) scheme consists of the following PPT
algorithms:
•K←KeyGen(1λ): The data owner generates a secret
key Kthat consists of a key KGfor an IPRF Gand a key
KSKE for a IND-CPA secure symmetric key cryptosystem
SKE.
•(InCSP,c)(InTA)←InGen(K,f): The data owner runs
this algorithm to generate the CSP index InCSP and a
collection of ciphertexts cthat will be stored to the CSP.
Additionally, the index InTA that is stored both locally and
in a remote location (outsourced to the TA) is generated.
•(In0
CSP,c0)(In0
TA)←AddFile(K, fi,InTA)(InCSP,c): The
data owner is running this algorithm to add a file to
her collection of ciphertexts. After a successful run, all
indexes and the collection of ciphertexts are updated.
•(In0
CSP, Iwi)(In0
TA)←Search(K, h(wi),InTA)(InCSP ,c).
This algorithm is executed by a user who wishes to
search for all files containing a specific keyword w. After
a successful run, the indexes are updated and the CSP
returns to the user a sequence of file identifiers Iw.
•(In0
CSP, I[a,b])(In0
TA)←RangeSearch(K, h(a), h(b),
InTA)(InCSP,c). This algorithm is executed by a user
who wishes to search for all files fcontaining values in
the range [a, b]. After a successful run, the indexes are
updated and the CSP returns to the user a sequence of
file identifiers I[a,b].
•(In0
CSP,c0)(In0
TA)←Delete(K, cid(fi),InTA)(InCSP,c):
The data owner runs this algorithm to delete a file from
the collection. After a successful run, all indexes are
updated accordingly.
Definition 3 (Search Pattern).The Search Pattern is a vector
sp that maintains a mapping between executed queries and
keywords. For example, sp[t] = wjdenotes the query issued
at time t, corresponding to wj.
Definition 4 (Access Pattern).The Access Pattern for a
keyword wiis defined to be the set of all files containing wi
at a given time t. The set is denoted by Fwi,t.
Definition 5 (Forward Privacy).A DSSE scheme satisfies the
property of forward privacy if for all file insertions that take
place after the successful execution of InGen, the leakage is
limited to the file identifier, its size and the number of keywords
in the file.
Definition 6 (Leakage Functions).Let LInGen,LAdd ,LSearch,
LDelete be the leakage functions associated with index creation,
file addition, and the search and delete operations.
•LInGen(f) = (N , n, cid(fi),|fi|),∀fi∈f. This function
leaks the total size Nof all the (wj,cid(fi)) pairs, the
number of files, their id’s and their size.
•LAdd(fi) = (cid(fi),|fi|,#wij): This function leaks the
encryption file id, the file size and the number of unique
keywords contained in it.
•LSearch(wj) = {Fwi,t, sp}: This function leaks the access
and search patterns.
•LDelete(fi)=(cid(fi),#wij∈fi,|fj|): This function
leaks the number of unique keywords contained in fi, the
ciphertext of the filename and the number of files that
contain keywords wij∈wi.
Definition 7. (DSSE Security) Let DSSE = (KeyGen,InGen,
Add,Search,RangeSearch,Delete)be a dynamic symmet-
ric searchable encryption scheme. Let LInGen,LAdd ,LSearch,
LDelete be the leakage functions. We consider the following
experiments where Sis a simulator, Cis the challenger and
ADV is the adversary:
RealADV (λ)
ADV outputs a set of files f. The challenger Cruns
KeyGen to generate a key K, and runs InGen.ADV
then makes a polynomial number of adaptive queries
q={w, f1, f2}such that wis contained in a file f∈f,
f1/∈fand f2∈f. For each q, she receives back either
a search token τs(w)for w, an add token τα, and a
ciphertext for f1or a delete token τdfor f2. Finally,
ADV outputs a bit bindicating her guess on whether
this is the real or the ideal experiment.
IdealADV (λ)
ADV outputs a set of files f.Sgets LInGen(f)to
simulate InGen.ADV then makes a polynomial num-
ber of adaptive queries q={w, f1, f2}such that w
is contained in a file f∈f,f1/∈fand f2∈f.
For each q, Sis given either LSearch(w),LAdd(f1)or
LDelete((f2)).Sthen simulates the tokens and, in the
case of addition, a ciphertext. Finally, ADV outputs a
bit bindicating her guess on whether this is the real
or the ideal experiment.
We say that the DSSE scheme is secure if for all PPT
adversaries ADV, there exists a probabilistic simulator Ssuch
that:
|P r[(Real) = 1] −P r[(Ideal) = 1]|≤ negl(λ)
The DSSE scheme is said to be correct, if the search
protocol returns the correct result for every query, except with
negligible probability. In Section VI we prove the security of
our construction under the semi-honest adversarial model.
IV. ARCHITECTURE
In this section, we introduce the system model by describing
the entities participating in our construction.
Users:We denote with U={u1, . . . , un}the set of
all users that have been already registered in a cloud service
that allows them to store, retrieve, update, delete and share
encrypted files while at the same time being able to search
over encrypted data by using our DSSE scheme. The users in
our system model are mainly classified into two categories:
data owners and simple registered users that they have not yet
upload any data to the CSP. A data owner first needs to locally
parse all the data that wishes to upload to the CSP. During this
process, she generates four different indexes:
1) No.Files[w]which contains a hash of each keyword w
along with the number of files that wcan be found at
2) No.Search[w], which contains the number of times a
keyword whas been searched by a user.
3) Order[w], which contains a hash of each keyword sorted
by the plaintext.
4) Dict a dictionary that maintains a mapping between
keywords and encrypted filenames.
Both No.Files[w]and No.Search[w]are of size O(m), where
mis the total number of keywords while the size of Dict
is O(N) = O(nm), where nis the total number of files.
To achieve the multi-client model, the data owner outsources
No.Files[w]and No.Search[w]to a trusted authority (TA).
These indexes will allow registered users to create consistent
search tokens. Dict is finally sent to the CSP.
Cloud Service Provider (CSP):We consider a cloud
computing environment similar to the one described in [13].
The CSP must support SGX since core entities will be running
in the trusted execution environment offered by SGX. The
CSP storage will consist of the ciphertexts as well as of
the dictionary Dict. Each entry of Dict is encrypted under a
different symmetric key Kw. Thus, given Kwand the number
of files containing a keyword w, the CSP can locate the files
containing w.
Trusted Authority (TA):TA is an index storage that
stores the No.Files and No.Search indexes that have been
generated by the data owner. All registered users can contact
the TA to access the No.Files[w]and No.Search[w]values for
a keyword w. These values are needed to create the search
tokens that will allow users to search directly on the encrypted
database. Similarly to the CSP, the TA is also SGX enabled.
SGX:We provide a brief description of the main SGX
functionalities. More details can be found in [5].
•Isolation: Enclaves are located in a hardware guarded
area of memory and they compromise a total of 128MB
(only 90MB can be used by software). Intel SGX is based
on memory isolation built in the processor along with
strong cryptography. The processor tracks which parts of
memory belong to which enclave and ensures that only
enclaves can access their own memory.
•Sealing: SGX processors come with a Root Seal Key
with which, data is encrypted when stored in untrusted
memory. Sealed data can be recovered even after an
enclave is destroyed and rebooted on the same platform.
•Attestation: One of the core contributions of SGX is the
support for attestation between enclaves of the same (lo-
cal attestation) or different platforms (remote attestation).
In the case of local attestation, an enclave encican verify
another enclave encjas well as the program/software
running in the latter. This is achieved through a report
generated by encjcontaining information about the en-
clave itself and the program running in it. This report
is signed with a secret key skrpt which is the same for
all enclaves of the same platform. In remote attestation,
enclaves of different platforms can attest each other
through a signed quote. This is a report similar to the
one used in local attestation. The difference is that instead
of using skrpt to sign it, a special private key provided
by Intel is used. Thus, verifying these quotes requires
contacting Intel’s Attestation Server.
V. POWER RANGE
A. Formal Construction
Our construction constitutes of six protocols, namely
KeyGen,InGen,AddFile,Search,RangeSearch and Delete.
Let G:{0,1}λ× {0,1}∗→ {0,1}∗be an IPRF. Moreover,
let SKE = (Gen,Enc,Dec)be a CPA-secure symmetric key
encryption scheme and finally, let h:{0,1}∗→ {0,1}λbe a
cryptographic hash function.
Key Generation. This is a probabilistic algorithm run by the
data owner and generates the secret key K= (KG,KSKE),
where KGis a key for G(also shared with the TA) and KSKE
is the key for the symmetric key encryption scheme.
Indexing. After the data owner generates K, runs InGen
(Algorithm 1) to generate the indexes: No.Files,No.Search,
Order and Dict. She stores a copy of each index locally and
outsources No.Files,No.Search and Order to the TA. Finally,
she sends Dict to the CSP. This protocol is treated like a set of
AddFile protocols, thus the data owner is required to internally
run AddFile (Algorithm 2). Note that when Dict is generated
is directly sent to the CSP. This is not the case with No.Search,
No.Files and Order where before outsourcing the indexes to
the TA, the data owner encrypts them using TA’s public key.
Although this process is not characterized by its efficiency, it
only occurs once and it is a necessary trade-off to achieve a
multi-client scheme. Upon reception, TA decrypts the indexes
using its private key and stores them in plaintext.
Algorithm 1 PR.InGen
1: c={}
2: AllMap = {}
3: for all fi∈fdo
4: Run AddFile to generate ciand MapiResults are NOT sent to the
CSP
5: c=c∪ci
6: AllMap = [{AllMap ∪Mapi},cid(fi)]
7: InTA = ((No.Files[w],No.Search[w],Order[w]))
8: Send (AllMap, c) to the CSP
9: Send InTA to the TA
10: CSP stores AllMap in a dictionary Dict
11: InCSP ={Dict},InTA ={No.Files[w],No.Search[w],Order[w]}
File Insertion. The data owner uican add new files to her
collection, even after the execution of Algorithm 1. To do
so, she uses the local copies of No.Files[w],No.Search[w]
and Order[w]and generates an add token τα(fi)for the file
fithat wishes to add. For each distinct keyword wij∈fi,
she increments No.Files[wij]by one and computes the corre-
sponding updated address on Dict. Furthermore, she computes
cfi= (KSKE, fi)and sends the results to the CSP (lines 8-11
of Algorithm 2). As a last step, uisorts the the new keywords
wij, inserts them into Order and sends an acknowledgement
to the TA who increments No.Files[wij]by one and updates its
local Order[wij]index. Note that when a new file is inserted,
the CSP does now know any valid keyword keys. As a result, it
cannot check whether the newly added file contains keywords
from previous search queries.
Search. We now assume that the data owner has successfully
shared her secret key Kwith multiple users who can access and
Algorithm 2 PR.AddFile
1: Map = {}
2: for all wij∈fido
3: No.Files[wij]++
4: Kwij=G(KG, h(wij)||No.Search[wij])
5: addrwij=h(Kwij,No.Files[wij]||0) Address in Dict
6: valwij=Enc(KSKE, id(fi)||No.Files[wij])
7: Map = Map ∪{addrwij,valwij}
8: cfi←SKE.Enc(KSKE, fi)
9: τα(fi)=(cfi,Map)
10: Send τα(fi)to the CSP
11: CSP adds ciinto cand Map into Dict
12: Send the updated value of No.Files[wij]to TA
13: TA updates No.Files[wij]
recover her encrypted data1. Assume that a user ujwho has
access to Kwishes to search for a specific keyword wjin ui’s
ciphertexts. To do so, ujcreates a search token τs(wj)by first
requesting the values No.Files[wj]and No.Search[wj]from the
TA (line 1 of Algorithm 3). Upon reception, ujcomputes the
key Kwjfor the keyword wjby calculating the following:
Kwj=G(KG, h(wj)||No.Search[wj]). Additionally, she incre-
ments No.Search[wj]by one and computes the updated key
K0
wjfor wjand the new addresses addrwjon Dict. Finally, she
stores the new addresses in a list Lthat will be sent to the CSP
as part of the search token (lines 4-10 of Algorithm 3). Upon
reception, the CSP forwards (Kwj,No.Files[wj]) to the TA to
ensure that ujsent the correct values. TA retrieves h(wj)and
No.Search[wj]by inverting G. In particular, TA computes:
G−1(KG,Kwj) = G−1(KG, G(KG, h(wj)||No.Search[wj]) =
h(wj)||No.Search[wj]. Then, TA computes Kwj
0(by incre-
menting No.Search[wj]by one) and addr0
wj. Finally, stores
addr0
wjto a list LT A which is sent to the CSP (lines 12-18
of Algorithm 3). Upon reception, the CSP checks whether
Lu=LT A. If Lu6=LT A , the CSP outputs ⊥and aborts
the protocol. If Lu=LT A, CSP locates the file identifiers by
looking at Dict[] and replaces the corresponding addresses on
Dict with the ones received by uj. The files are then sent back
to the user and the CSP sends an acknowledgement to the TA
in order to increment the value of No.Search[wj]by one. The
same acknowledgement is forwarded to the data owner, so that
she also updates her local indexes.
Range Queries. If a user ujwishes to find all ciphertexts
containing values in the range [a, b]she first hashes the
extreme values of the range (h(a)and h(b)) and sends them to
the TA. TA then retrieves the sorted index Order[w], locates
h(a)and h(b)and sends back to ujevery entry that lies in
between. Finally, for each returned value ujperforms a search
operation just as described in Algorithm 3. If a number already
exists in Order[w], it does not need to be re-inserted. Hence,
duplicate values do not add extra computational burden to
our construction. Nevertheless, this approach suffers from the
following two issues: (1) Only the data owner can insert new
1How key is shared with other users is out of the scope of this paper.
However, interesting approaches that fit squarely the cloud paradigm and
leverage the power of secure hardware can be found in [14]–[17].
Algorithm 3 PR.Search
User:
1: Request the values No.Files[wj]and No.Search[wj]for a keyword wj,
from TA
2: Kwj=G(KG, h(wj)||No.Search[wj])
3: No.Search[wj]++
4: K0
wj=G(KG, h(wj)||No.Search[wj])
5: Lu={}
6: for i= 1 to i=No.Files[wj]do
7: addrwj=h(K0
wj, i||0)
8: Lu=Lu∪{addrwj}
9: Send τs(wj)= (Kwj,No.Files[wj], Lu)to the CSP
CSP:
10: Forward (Kwj,No.Files[wj]) to TA
TA:
11: h(wj)||No.Search[wj] = G−1(KG,Kwj)
12: No.Search[wj] = No.Search[wj]+1
13: K0
wj=G(KG, h(wj)||No.Search[wj])
14: LT A ={}
15: for i= 1 to i=No.Files[wj]do
16: addrwj=h(K0
wj, i||0)
17: LT A =LT A ∪{addrwj}
18: Send LT A to the CSP
CSP:
19: if Lu=LT A then
20: Iwj={}
21: for i= 1 to i=No.Files[wj]do
22: cid(fi)=Dict[(h(Kwj, i||0))] The encryption of the filename
23: Iwj=Iwj∪ {cid(fi)}
24: Delete Dict[(h(Kwj, i||0))] The old addresses are removed
from the Dictionary
25: Add the new addresses as specified by LuThe positions are
different that the old ones
26: else
27: Output ⊥
28: Send Iwjto the user and an acknowledgement to the TA and the Data
Owner
TA & Data Owner:
29: No.Search[wj]++
values to Order[w]since the rest of the users are not aware
of the ordering of the index and (2) If the extreme values of
the range are not already inserted in the index, the algorithm
cannot return any result. In Section V-B we propose a solution
to these problems that can work with natural numbers.
Algorithm 4 PR.RangeSearch
User:
1: Send h(a), h(b)to the TA
TA:
2: Locate h(a), h(b)on Order[w].Let Order[α] = h(a)and
Order[β] = h(b)
3: Lord ={}
4: for i=αto i=βdo
5: Lord =Lord ∪Order[i]
6: Return Lord to uj
User:
7: for all h(wi)∈Lord do
8: Run Pr.Search
File Deletion. A data owner uican delete a file fiby sending
a delete request to the CSP. Upon reception, the CSP returns
the encrypted file to uiwho decrypts it locally, extracts all
keywords and updates her local indexes accordingly (lines 2-
13 of Algorithm 5). Then, contacts the TA by sending an
acknowledgement and an update to its indexes. Finally, ui
computes the new addresses and values for every wij∈fi,
and sends them to the CSP to proceed with the deletion of
every Dict entry associated with fi.
Algorithm 5 PR.Delete
Data owner:
1: FileNumber ={}
2: for all wij∈fido
3: if No.Files[wij]>1then
4: addrwij=h(Kwij,No.files[wij]||0)
5: valwij=Enc(KSKE,id(fi),No.Files[wij])
6: No.Files[wij]− −
7: newaddr =h(Kwij,No.files[wij]||0)
8: newval =Enc(KSKE, id(f)||No.Files[wij])
9: else
10: newaddr = 0λ
11: newval = 0λ
12: Delete No.Files[wij],No.Search[wij]and Order[wij]
13: FileNumber =FileNumber ∪ {h(wij),No.Files[wij]}
14: Send FileNumber to the TA
15: τd(f) = {(addrwij,newaddrwij),(valwij,newvalwij)}#w∈fi
i=1
16: Send τd(fi)to the CSP
TA:
17: for all h(wij)∈FileNumber do
18: if No.Files[wij]>1then
19: No.Files[wij]− −
20: else
21: Delete No.Files[wij],No.Search[wij]and Order[wij]
CSP:
22: for j= 1 to j= #wi∈fido
23: if newaddrwij= 0 then
24: Delete addrwijand valwij
25: else
26: addrwij=newaddrwij
27: valwij=newvalwij
B. Range Queries over N
We now assume that the entries of Order are hashes of
elements x∈N, sorted by plaintext. However, we modify
the index and we now assume that it is an (m×n)Matrix
M, where nis fixed by the data owner, while m’s length
can vary. To fill in the matrix, the data owner first sorts the
numbers locally, hashes them and then picks n. The ordering
in the matrix corresponds to the natural order of N. For
example, M(1,1) = h(0), M (1,2) = h(1), . . . ,M (1, n) =
h(n−1), M (2,1) = h(n). . . . To prevent TA from knowing
which hash corresponds to what number, the data owner picks
a random number sand shifts each row of the matrix by
s(modm)resulting to a matrix Mshifted. To add a new number
κto the matrix, the user first writes κas κ=λ·n+µ, where
λis the biggest positive number such that λ·n≤κ, and then
calculates λ0= ((λ+1)+s)(modm)and µ0=µ+12. Finally,
κwill then be inserted in Mshifted(λ0, µ0)as h(κ).
Toy Example. The data owner wishes to insert the numbers:
2, 4, 7, 9, 10. She picks n= 3 and s= 2. We denote by 0 an
empty position in the matrix Mwhich is initially empty. The
ordering of Mfollows the natural order of N. Hence, h(2)
2The secret scan be shared between multiple users, along with the secret
key Kwhile µcan be provided by the TA
will be inserted in position (1,3). Since s= 2, each row will
be shifted by 2mod4 = 2. As a result, the new position of
h(2) on Mshifted will be (3,3). Thus, we have:
M=
0 0 h(2)
0h(4) 0
0h(7) 0
h(9) h(10) 0
Mshifted =
0h(7) 0
h(9) h(10) 0
0 0 h(2)
0h(4) 0
Mshifted is outsourced to the TA. If a user wishes to add
the number 6 to the matrix, all she needs to do is write 6 as
6=2·3+0, apply the shift as λ0= (2 + 1) + 2 = 5 ≡1
mod 4, calculate µ0= 0 + 1 = 1 , and send {(1,1), h(6)}to
the TA who will insert h(6) at the first position of the matrix.
Now, assume that a legitimate user wishes to perform a
range query for the range [a, b]. To do so, first calculates
the corresponding positions on M(let M(i, j) = h(a)and
M(i0, j0) = h(b)) and sends them to the TA. TA will start on
position (i, j)and will return to the user every element that
lies on the right and beneath (i, j)until it reaches (i0, j 0). The
user will then run the search algorithm, for each value that
was returned by the TA.
Limitations. Even though this approach allows multiple users
to add new numbers in the matrix, currently it only works
with natural numbers. However restrictive, there exist realistic
scenarios where such a functionality could be used. For
example, if we consider an encrypted database consisting of
health records, our construction would allow a doctor to issue
a query such us: “Find all patients who are at least 25 years
old and suffer from disease D”. As a future work we plan to
look into how to enable range queries over R.
VI. SECURITY ANA LYSIS
Theorem 1. Let SKE be a CPA-secure symmetric key encryp-
tion scheme, Gan invertible pseudorandom function and ha
hash function. Then our construction is secure according to
Definition 7.
Proof. We construct a simulator Sthat simulates the real
algorithms in such a way that no PPT adversary ADV will
be able to distinguish between the real algorithms and the
simulated ones. Naturally, Kis not given to the adversary,
since possession of Kimplies that ADV can distinguish
between the real and the simulated algorithms. Sis given the
leakage functions LInGen,LAdd ,Lsearch,LDelete and simulates
the protocol.
Index generation Simulation: Sis given LInGen and proceeds
as follows: First it simulates N(ai, vi)pairs such that |ai|=λ
and |vi|=|cid(fi)|and stores them on a dictionary DS.
Moreover, Screates two more dictionaries, KeyStore and
Oracle.KeyStore is used to store the latest key associated with
each keyword, while Oracle is used to reply to search queries.
Finally, instead of the actual files, Sencrypts sequences of
zeros. The simulated dictionary has exactly the same size as
the real one. Moreover, the CPA security of the symmetric
encryption scheme, ensures that ADV cannot distinguish
between the encryption of actual files and that of a string of
zeros.
Add token Simulation: Sis given the leakage function
LAdd and simulates #wi{ai, vi}pairs that are added in
DSalong with the encrypted id of the file to be added.
Each {ai, vi}pair is added in a list Ladd that enables Sto
keep its dictionary up to date with files provided by ADV
after the execution of InGen. The token provided by the
simulator is τα(fi) = (cid(fi),0|fi|,Ladd)which has the same
format and size as the real add token. The CPA security of
the symmetric encryption scheme, ensures that ADV cannot
distinguish between the encryptions of fiand 0|fi|. We showed
that the add token can be simulated by only knowing LAdd,
and hence, our scheme preserves forward privacy.
Search Token Simulation: Sis now given the search outcome
and search pattern and simulates the search tokens. The token
is simulated as shown below:
Search Token Simulation
d=|Fwj|Number of files containing wj
If KeyStore[wj] = Null
yo KeyStore[wj]← {0,1}λ
For i= 1 to i=d
yo If Oracle[Kwj][0][i]is Null ADV’s first search on wj
yoyo If fiis added after InGen
yoyoyo Pick a (cid(fi),{ai, vi})pair
yoyo Else
yoyoyo Pick an unused {ai, vi}at random
yoyo Oracle[Kwj][0][i] = ai
yoyo Oracle[Kwj][1][i] = vi||cid(fi)Resize viso that
|vi||cid(fi)|=|valwj||No.Files[wj]|
yo Else
yoyo ai=Oracle[Kw][0][i]
yoyo vi=Oracle[Kw][1][i](|Oracle[Kwj][1][i]|−|cid(fi)|)Prefix of the
string
yo Remove aifrom the dictionary viis kept
UpdatedV al ={}
K0
w← {0,1}λ
KeyStore[wj] = K0
wj
For i= 1 to i=d
yo Generate new aiand match it with vithat was kept from before
yo Add (cid(fi),{ai, vi})to the dictionary
yo UpdatedV al =U pdatedV al ∪ {cid(fi), ai}
yo Oracle[K0
wj][0][i] = ai
yo Oracle[K0
wj][1][i] = vi||cid(fi)
τs(w)=(Kwj, d, U pdatedV al)
KeyStore[w]is used to keep track of the last key Kwused
for each keyword w.Oracle[Kw][j][i]is used to reply to ADV’s
queries. For example, Oracle[Kw][0][i]represents the address
of a Dict entry assigned to the i−th file in the file collection F.
Similarly, Oracle[Kw][1][i]represents the masked value needed
to recover cid(f). The simulated search token has exactly the
same size and format as the real one, and as a result no PPT
adversary can distinguish between them. It is important to
mention here that the simulation of the search tokens also
covers range queries, since in our construction the problem of
issuing a range query is reduced to that of issuing multiple
search queries.
Delete Token Simulation: Sis now given LDelete (f)and
simulates the delete token as follows: It first generates `
{a0
i, v0
i}pairs and matches them with unused {ai, vi}pairs,
where `in the number of keywords that exist in multiple files.
These matches will then be stored in a list Ldand each {ai, vi}
on Dict will be replaced with the corresponding {a0
i, v0
i}. As
a next step, Sgenerates wi−`{a0
i, v0
i}pairs and inserts them
Comparison
Scheme MC FP KS RQ Search Time
Logarithmic-SRC-i 7 333O(R+)
HardIDX 7 7 3 3 O(logn)
ORE 7773O(n)
Sophos 7 3 3 7 O()
Ours 3333O(/p)
TABLE I
n:DATASE T SIZ E,:R ESU LT SIZ E,R:RANGE,p:PROCESSORS SIZE, MC:
MULTI-CLIE NT, FP : FO RWWARD PR IVACY, KS: KEY WOR D SEARCH, RQ:
RAN GE QUE RI ES
in Ldas {a0
i,0λ},{v0
i,0λ}. Finally τd(f) = Ld.
The simulated delete token is indistinguishable from the real
one since they have the same format and size. We constructed
a simulator Sthat simulates all the real protocols in a way
that no PPT adversary ADV can distinguish between the real
and the ideal experiments. 2
SGX Security.According to [18] leakage can be avoided if
the programs running in the enclaves do not have memory
access patterns or control flow branches that depend on the
values of sensitive data. The only operation occuring on the
indexes stored on the TA, is the application of a pseudorandom
function and that of a hash function. To this end, we could
use leakage resilient primitives [19].
VII. THEORETICAL EVALUATI ON
Power Range achieves optimal search and update costs
O(`)and O(m)respectively, where `is the number of the
resulted files and mis the number of unique keywords in
a file. Reducing the search time from O(f), where fis the
total number of files, to O(`), is achieved through the index
No.Files[w]by defining the for loop in line 22 of Algorithm 3.
Additionally, our construction is parallelizable. The problem
of finding all files that contain a keyword w, is reduced into
locating `independent hashes on Dict. Hence, by distributing
the load to pprocessors, the total search time is reduced to
O(`/p). Similarly, the update cost is O(m/p). Finally, it is
worth mentioning that the size of each index stored in the
TA is O(m), where mis the total number of keywords. If
we consider a case with 1 million keywords, with the size of
an integer being at 4bytes and the average size of a keyword
at 10bytes [4], then the total size required for the three indexes
will be 1×106×(10 + 4 + 10 + 4 + 10 + 4) = 1 ×106×42 =
42×106B= 42MB. Thus, storing a large number of keywords
is not affected by the limitations of SGX. In table I we
compare Power Range to the works presented in Section II.
VIII. CONCLUSION
In this paper we presented Power Range – a dynamic SSE
scheme that satisfies the property of forward privacy while at
the same time works under the multi-client model. Addition-
ally, we modified the initial scheme in order to support range
queries over N(i.e. allow users to find all stored encrypted
integers in a given interval [a, b]). As a future work, we plan
to provide extensive experimental results for our construction
and test its overall practicality. Finally, we plan to extend
the provided functionality by supporting complex queries and
range queries over R.
ACK NOW LE DG EM EN TS
This work was funded by the ASCLEPIOS: Advanced
Secure Cloud Encrypted Platform for Internationally Orches-
trated Solutions in Healthcare Project No. 826093 EU research
project.
REFERENCES
[1] M. Naveed, “The fallacy of composition of oblivious ram and searchable
encryption,” IACR Cryptology ePrint Archive, vol. 2015, p. 668, 2015.
[2] D. Cash, P. Grubbs, J. Perry, and T. Ristenpart, “Leakage-abuse attacks
against searchable encryption,” in ACM CCS’15, 2015.
[3] Y. Zhang, J. Katz, and C. Papamanthou, “All your queries are belong
to us: The power of file-injection attacks on searchable encryption,” in
Proceedings of the 25th USENIX Conference on Security Symposium,
SEC’16, (Berkeley, CA, USA), pp. 707–720, USENIX Association.
[4] M. Etemad, A. K¨
upc¸¨
u, C. Papamanthou, and D. Evans, “Effi-
cient dynamic searchable encryption with forward privacy,” CoRR,
vol. abs/1710.00208, 2017.
[5] V. Costan and S. Devadas, “Intel sgx explained.” Cryptology ePrint
Archive, Report 2016/086, 2016. https://eprint.iacr.org/2016/086.
[6] A. Bakas and A. Michalas, “Multi-client symmetric searchable encryp-
tion with forward privacy.” Cryptology ePrint Archive, Report 2019/813,
2019. https://eprint.iacr.org/2019/813.
[7] I. Demertzis, S. Papadopoulos, O. Papapetrou, A. Deligiannakis, and
M. Garofalakis, “Practical private range search revisited,” in Proceedings
of the 2016 International Conference on Management of Data, SIGMOD
’16, (New York, NY, USA), pp. 185–198, ACM, 2016.
[8] F. Brasser, F. Hahn, F. Kerschbaum, A.-R. Sadeghi, B. Fuhry, and
R. Bahmani, “Hardidx: Practical and secure index with sgx,” 2017.
[9] R. Bost, “Sophos - forward secure searchable encryption.” Cryptology
ePrint Archive, Report 2016/728, 2016. https://eprint.iacr.org/2016/728.
[10] D. Boneh, K. Lewi, M. Raykova, A. Sahai, M. Zhandry, and J. Zim-
merman, “Semantically secure order-revealing encryption: Multi-input
functional encryption without obfuscation,” in Advances in Cryptology
- EUROCRYPT 2015 (E. Oswald and M. Fischlin, eds.), Springer.
[11] K. Lewi and D. J. Wu, “Order-revealing encryption: New constructions,
applications, and lower bounds,” in Proceedings of the 2016 ACM
SIGSAC Conference on Computer and Communications Security, CCS
’16, (New York, NY, USA), pp. 1167–1178, ACM, 2016.
[12] D. Boneh, S. Kim, and D. J. Wu, “Constrained keys for invertible
pseudorandom functions.” Cryptology ePrint Archive, Report 2017/477,
2017. https://eprint.iacr.org/2017/477.
[13] N. Paladi, C. Gehrmann, and A. Michalas, “Providing user security
guarantees in public infrastructure clouds,” IEEE Transactions on Cloud
Computing, vol. 5, pp. 405–419, July 2017.
[14] A. Michalas, “The lord of the shares: Combining attribute-based encryp-
tion and searchable encryption for flexible data sharing,” in Proceedings
of the 34th ACM/SIGAPP Symposium on Applied Computing, SAC ’19,
(New York, NY, USA), pp. 146–155, ACM, 2019.
[15] A. Bakas and A. Michalas, “Modern family: A revocable hybrid encryp-
tion scheme based on attribute-based encryption, symmetric searchable
encryption and sgx,” in International Conference on Security and
Privacy in Communication Systems, pp. 472–486, Springer, 2019.
[16] A. Michalas, A. Bakas, H.-V. Dang, and A. Zaltiko, “Microscope: En-
abling access control in searchable encryption with the use of attribute-
based encryption and sgx,” in Nordic Conference on Secure IT Systems,
pp. 254–270, Springer, 2019.
[17] A. Michalas, A. Bakas, H.-V. Dang, and A. Zalitko, “Access control
in searchable encryption with the use of attribute-based encryption and
sgx,” in Proceedings of the 2019 ACM SIGSAC Conference on Cloud
Computing Security Workshop, pp. 183–183, 2019.
[18] B. Fisch, D. Vinayagamurthy, D. Boneh, and S. Gorbunov, “Iron:
Functional encryption using intel sgx,” in Proceedings of the 2017 ACM
SIGSAC Conference on Computer and Communications Security, CCS
’17, (New York, NY, USA), pp. 765–782, ACM, 2017.
[19] Y. Dodis and K. Pietrzak, “Leakage-resilient pseudorandom functions
and side-channel attacks on feistel networks,” in Annual Cryptology
Conference, Springer, 2010.