• No results found

6.5 Tradeoff between Runtime and Predicate Security

7.3.2 Protocol

Now we describe how we organize the search index in order to accelerate search executions while keeping the leakage of the indexed encrypted values minimal. We tackle these contradictory requirements by updating the index every time the server learns new information from the access pattern. This newly gained knowledge is then used to refine the encrypted search index for subsequent searches queried in the future. First, we explain our ideas and design decisions on plaintext data and transfer this approach on encrypted values in the upcoming section.

Organizing an Index for Plaintext Values

As already mentioned, we extend the idea from Chapter 5, that is, the searchable data is organized in a linear search index together with a result cache that can be accessed more efficiently. Particularly, the search index γconsists of the following two components:

The point list denoted asPis a linear list of all indexed points. This list enables the server to answer any range query in linear time.

The tree list denoted asTis a list of search trees, each tree covering one coherent and already searched range. Whenever a new search is executed, existing trees are updated or a new tree is added to the list. This enables the server to answer range queries that are subranges of already queried ranges in logarithmic time.

Since we unveil range tokens and strive to reuse them, we decided for search trees keeping ranges as search keys for their nodes. More particular, Tcontains R-trees [73], where each R-treeΓcovers one coherent range completely. For simplicity we writeΓ ⊆S for a rangeS, meaning that the range covered byΓis a subset ofS, vice versaS ⊆ΓandS = Γ. For each R-tree we define the thresholdt, that is, any node holds up totrange entries; each entry has the form(p, R), whereRis a range andpis a pointer to another node (either an inner node or a leaf) covering this range; hence pointerppoints to a subtree. We denote Γ[p]as the subtree ofΓpointed to byp. In addition, for any two entries(p1, R1)and(p2, R2)contained in the same node it holds thatR1∩R2 =∅, i.e. the ranges in one node are distinct and do not overlap. For every entry(p, R)it holds that the subtree rooted at the node pointed to bypcovers the complete rangeR, i.e.Γ[p] = R. Finally, all leaves contain up totentries, every entry has the form(obj, R), whereRis a range andobjpoints to identifiers that are indexed under values falling within rangeR, denoted asIDR. Queried rangeQ= [q(s), q(e)]and given an R-treeΓcovering a superset ofQ(i.e.Q⊂Γ) the server can traverse this tree forQin logarithmic time. More formally, the server is able to retrieveIQin logarithmic time using Algorithm 7.1.

An example for a search indexγcontainingPis depicted in Figure 7.1a andTwith one treeΓcovering range[4,16]is depicted in Figure 7.1b. Assume the client submits a query for range[17,23]. In the initial

7 Range Queries

Algorithmus 7.1 :SearchForRange

Input :R-TreeΓ, Queried rangeQ

Output : IQ

1: Initialize temporary result listL

2: forallei= (pi, Ri)in root ofΓdo

3: ifRiQthen

4: Add all values indexed byΓ[pi]toL

5: end

6: else ifq(s)∈Riorq(e)∈Rithen

7: ifpipoints to another nodethen

8: Add output ofSearchForRange(Γ[pi], Q)toL

9: end

10: ifpipoints to a listIDRi then

11: Add all values withvQtoL

12: end

13: end

14: end

15: returnlistL

(5, A) (14, E) (7, B) (8, C) (22, F) (8, D) (1, G) . . .

(a)Point ListP

[9,16] [4,8] [9,16] (14, E) [8,8] [4,7] (8, C),(8, D) (5, A),(7, B) (b)Initial R-TreeΓ∈T

Figure 7.1: Example of plain search indexγconsisting ofPandT

logarithmic time. Since this is not the case, the server scans all entries inPlinearly yielding the queried result setID[17,23]. Next, this fresh information is added to the search index for future queries and results

an updated version ofΓcovering[4,23]as depicted in Figure 7.2. [9,23] [4,8]

[17,23] [9,16]

(22, F) (14, E)

[8,8] [4,7]

(8, C),(8, D) (5, A),(7, B)

Figure 7.2: Updated R-TreeΓafter query[17,23]

We refer to the following paragraph in for a comprehensive description of this updating process.

7.3 Implementation

Building an Encrypted Range Index

Note that the following functionality is sufficient for answering such range queries by the execution of Algorithm 7.1:

1. check if rangeQis a subrange of another rangeRrequired for identifying matching R-treeΓinTand 2. check if rangeRand rangeQintersect for tree traversal and

3. check if a valuevfalls withing rangeQfor a linear scan of values in matching leaves and the linear scan of point listP.

All required functionality can be provided by a slightly modified RPE scheme. A token for range Q = [q(s), q(e)]

created byRPE-Tokenis supplemented by encrypted limiting points, that is start point and end point of the range. Particularly SRQ-Token outputs the following tuple RPE-Enc(k, q(s)), RPE-Enc(k, q(e))

,RPE-Token(k, Q)as part of range tokenτQ. Given two tokensτQ =

c(0)Q , c(1)Q , tkQ andτR = c(0)R , c(1)R , tkR

generated with this approach, the server is able to check for the following relation of these ranges, as required for tree traversal on encrypted R-trees.

Subrange: Qis a subrange ofRifRPE-Match(tkR, c (0)

Q ) = 1andRPE-Match(tkR, c (1) Q ) = 1. Intersection: R andQintersect ifRPE-Match(tkQ, c

(i)

R ) = 1or ifRPE-Match(tkR, c (i)

Q) = 1 fori

{0,1}.

Equality: QandRare equal ifRis a subrange ofQandQis a subrange ofR.

Such modified range predicate encryption scheme combined with an interactively and incrementally updated search index can be used to define an SRQ scheme with poly-logarithmic runtime and small leakage. Given a range predicate encryption schemeRPEconsisting of algorithms RPE-Setup,RPE-Enc, RPE-Token,RPE-Match

and a secret-key encryption schemeΠ = (Gen,Enc,Dec)we construct anSRQ scheme as follows:

K←SRQ-Setup 1λ,[0, d]: on input of security parameter1λand value domain[0, d]create the following keys corresponding to the security parameter

k1←RPE-Setup 1λ,[0, d] k2←Gen 1λ

Output master keyK= (k1, k2).

c←SRQ-Enc(K,M): on input of master keyK = (k1, k2) and message collection M containing n messages do the following:

1. Initialize an empty search indexγ = (P,T)that contains an empty point listPand an empty tree listT.

2. For each messagemi = (vi, ID(fi))encryptci←RPE-Enc(k1, vi)and append(ci, ID(fi))

to point listP.

7 Range Queries

τQ ←SRQ-Token(K, Q): on input of master key K = (k1, k2) and rangeQ = [q(s), q(e)] flip a coin b←− {$ 0,1}and useRPE-Encfor encrypting the limiting points:

c(Qb)←RPE-Enc(k1, q(s))

c(1Qb)←RPE-Enc(k1, q(e)).

Furthermore create range token tkQ ← RPE-Token(k1, Q) and encryptQ tocQ ← Enc(k2, Q). OutputτQ=

c(0)Q , c(1)Q , tkQ, cQ

as range token.

IQ, γ0←SRQ-Search(τQ, γ): on input of range tokenτQ=

c(0)Q , c(1)Q , tkQ, cQ

for rangeQand encrypted search indexγinitialize an empty listTbfor trees that are completely covered by the queried range. For each indexed search treeΓiT:

1. Check if there exists one treeΓiTcontainingbothc(0)Q andc (1)

Q . If this is the case, retrieve

IQby calling Algorithm 7.1 and setΓ(0)= Γ(1) = Γi. 2. Otherwise, set treeΓ(0)withc(0)Q ∈Γ

(0)

andΓ(0) =⊥if no such tree exists. Analogously, do the same withc(1)Q and denoteΓ

(1)

as the corresponding result. For each tree that is covered completely byQ, append it to listTb resulting inTb = {Γi | ΓiQ}. Scan all ciphertexts (ci, ID(fi))∈PusingRPE-Match(tkQ, ci)and storeID(fi)if their corresponding value falls withing the queried range.

In order to maintain logarithmic search time for future queries, call an interactive procedureγ0 ← SRQ-UpdateIndex(τQ,IQ,Γ(0),Γ(1),Tb)described comprehensively in the following section. Finally, outputIQas result and the updated search indexγ0.

Recall that the server is able to compare different range tokens without knowing the master key or underlying plaintext values. The server getting a range token τQ for range Q = [q(s), q(e)] executes SRQ-Searchand retrieves all files associated with values falling within rangeQ. In the initial Step 1, the server checks if she has extracted enough information from previous queries to answer the current query in logarithmic time. Alternatively, in Step 2 the server checks if any information about rangeQis already indexed in at least one search tree. All tokens contained in the entries(p1, τR1), . . . , pni, τRni

contained in the root node ofΓiare compared with range tokenτQ. HereΓiQif allR1, . . . , Rniare subranges of

Q. A listbT={ΓiiQ}of all trees covering a subrange ofQis created. Further, partial intersections of indexed search trees and the queried range are checked, definingΓ(0)as the tree intersecting withc(0)Q and

analogouslyΓ(1)as the tree intersecting withc(1)Q . Finally, the server decides how to update the search index

based on the result of these checks, that is, depending on the nature ofbTandΓ(0),Γ(1) different update strategies forSRQ-UpdateIndexmust be applied.

1. One tree covers the complete queried rangeQ, that isΓ(0)= Γ(1), soQ⊂Γ. If this is the case, the server does not need to perform a search over the complete point listPbut searching over the value points indexed byΓ(0)is sufficient. This is done using Algorithm 7.1.

Finally,SRQ-UpdateIndexhas torefineindexed ranges by using information gained from the current range query.

2. No intersection of the current range query and all previously queried ranges, soΓ(0)= Γ(1)=⊥and b

T =∅. If this is the case, the server does not know anything about the current range query. As a result, the server has to scan all points indexed in point listP.

Finally,SRQ-UpdateIndex has tocreatea new search tree that is added to tree listTcovering the queried range.

7.3 Implementation

3. Only one part of the queried range is covered by indexed search trees. EitherΓ(0) =⊥orΓ(1)=⊥. If this is the case, the server cannot know if there are values in point listPfalling withinQbut are not covered byΓ(0)resp.Γ(1). As a result, the server has to scan all points indexed in point listP. Finally,SRQ-UpdateIndexhas toextendthe one tree covering the queried range partly, i.e. eitherΓ(0) orΓ(1)that is not⊥.

4. The values fall within different trees, that isc(0)∈Γ(0)andc(1) ∈Γ(1)whereΓ(0)6= Γ(1). If this is the case, the server cannot be sure that there is no “index gap” between the two trees, i.e. there could be values inPfalling neither withinΓ(0)norΓ(1)but that fall within queried rangeQ. As a result, the server has to scan all points indexed in point listP.

Finally,SRQ-UpdateIndex has tomergethese trees Γ(0) andΓ(1) closing the gap revealed by the current range query.

In the following subsection we elaborate on these different updating cases and describe the updating procedure in a formal protocol.

Updating the Encrypted Index

From a high-level perspective, a new range token contains novel information given to the server, namely the result setIDQ and the relation ofQto all previous queries. This newly gained information is implicitly leaked by the access pattern, that is, givenIDQIDU the server can deduce thatQU. Remember that all efficient searchable encryption schemes with few exceptions leak this information. Our construction utilizes this leakage to update the encrypted search index for accelerating future queries. Update operations require the creation of fresh range tokens used to extend the encrypted search trees. Since this creation is only possible given the master key, these update procedures are interactive protocols between server and data owner; in the following discussion we highlight operations on the client side with the prefix“@Client: Some Operation”. All these tree modifications append new entries to an existing tree which might result in a number of entries in one node that is larger thant. Thus, a rebalancing step is required such that every node’s size is lower than thresholdtafterwards. Protocol 7.2 formalizes this interactive rebalancing step for encrypted R-trees. Further details on howSRQ-UpdateIndexworks internally are discussed in the following paragraphs.

Refining a tree. An existing encrypted search treeΓcan be refined given range tokenτQif this search tree and the range token intersect, i.e.Q∩Γ6=∅. The server sends range tokenτQand the encrypted R-treeΓ intersecting with that range token to the data owner asking for help. Recall that the client has access to the master key, hence she is able to decrypt the range tokens together with the tree’s intersecting leaves. Using these intersecting leaves, she creates (up to) four non intersecting but more refined ranges and sends back their tokens generated bySRQ-Token. The server replaces the old range tokens with the novel, more refined tokens and the indexed file lists are segmented according to these novel tokens. A formal description of this protocol is given in Protocol 7.3. Since this replacement increases the number of entries in one node, the server finally runs Protocol 7.2.

Creating a tree. A fresh encrypted R-tree is created if no information on the novel queried range is cached in any search tree indexed inT. In such case, the server creates a new treeΓwith one node only containing the novel range tokenτQand indexed itemsIDQretrieved from the linear point listP. This treeΓis added to tree listT.

7 Range Queries

Protocol 7.2 :RebalanceTree

Input :TreeΓwith leaflsuch thatlen(l)> t.

Output :Rebalanced treeΓ.

1: Setcur_node=l

2: whilelen(cur_node)> tdo

3: Send all entriesei= (pi, τRi)∈cur_nodeto client

/* Split this node in two nodes of the same size */

4: @Client: Sort all entries{ei= (pi, τRi)}according to their rangeRi

5: @Client: Create two tokensτU, τV usingSRQ-Tokenfor rangesU =Sd

n

2e−1 i=0 Ri, V =Sn

i=dn

2eRiand set nodesNU ={ei|RiU},NV ={ei|RiV}

6: @Client: Send permutations ofNV, NU with corresponding tokensτV, τUto server

7: ifcur_nodeis not rootthen

8: Replacecur_node∈ΓwithNV, NU indexed with tokensτV, τU incur_node.parent

9: Setcur_nodetocur_node.parent

10: end

11: else

12: Replacecur_nodewithLV, LU

13: Create new root only containing tokensτV, τU pointing toLV, LU

14: end

15: end

Protocol 7.3 :Refining an encrypted R-tree.

Input :TreeΓ; range tokenτQ.

Output :Refined TreeΓ.

1: forq∈ {q(s), q(e)}do

2: Searchleafcontaining tokenτRwithqRinΓ

3: SendτRandτQto the client

4: @Client: ForR= [r(s), r(e)]andqsetQ1= [r(s), q]andQ2= [q+ 1, r(e)] 5: @Client: Send backτQ1, τQ2generated withSRQ-Token

6: DivideIDRthat is pointed to byleafinto two listsIDQ1, IDQ2

7: Inleafreplace(IDR, τR)with two new entries(IDQ1, τQ1),(IDQ2, τQ2) 8: RebalanceTree(Γ,leaf)

9: end

Extending a tree. An encrypted treeΓcan be extended if a queried range tokenτQintersects with one tree Γor covers this tree completely, i.e.q(s)∈Γandq(e)∈/Γ(or vice versa) or evenΓ⊂Q. The server sends the newly learned range tokenτQand the root node to the client. The client decrypts all ranges contained in the root to reconstruct the whole range currently covered by this tree. A new range token for the gap between the range covered by the current tree and the limiting points of the new range token extending the current tree is created and added to the updated tree. We refer to Protocol 7.4 for a formal description. The resulting tree must be rebalanced after tree extension since at least one leaf got a new entry.

Merging two trees. Two treesΓ1,Γ2 can be merged if they both intersect with the queried range token τQ, i.e.q(s)∈ Γ1 andq(e) ∈ Γ2. Note that these two trees must not have a value gap between them. In more details, the rangeR1 = [r

(s) 1 , r

(e)

1 ]covered by one tree must be directly followed by second range

R2= [r (s) 1 , r

(e)

1 ]covered by the other tree, that is,r (e)

1 + 1 =r (s)

2 This can be achieved by the execution of

tree extension as described in Algorithm 7.4. The algorithm integrates the tree with the lower height into the tree with greater height resulting in logarithmic merge time. That is, a new entry inner node is created in the higher tree pointing to the root of the lower tree. This newly covered range must then be propagated

7.4 Evaluation

Protocol 7.4 :Extending encrypted R-tree.

Input : TreeΓ; range tokenτQ.

Output : Updated treeΓcoveringτQcompletely.

1: Setroot_nodeto the root node ofΓ

2: Sendroot_nodeand range tokenτQto client

3: @Client: SetR= [r(s), r(e)] =

S

iRifor all entries(pi, Ri)inroot_node

/* Compute the complete range covered by current tree. */

4: forr∈ {r(s), r(e)}do

5: @Client: Ask server for all nodes inΓcontainingr, retrieve node setN={nj|rnj} 6: forcur_node∈N do

7: @Client: Extract lowest resp. greatest rangeR0= [r0(s), r0(e)]incur_node

8: ifcur_nodeis not a leaf then

9: @Client: Extend this range toQ0 = [q(s), r0(e)]resp.Q0= [r0(s), q(e)]

10: @Client: Replace inner entryτR0 withτQ0 generated bySRQ-Token

11: end

12: else

13: @Client: Set rangeQ0 = [q(s), r0(s)−1]resp.Q0= [r0(e)+ 1, q(e)]

14: @Client: Create new tokenτQ0usingSRQ-Token 15: Add new entry(τQ0, IDQ0i)to leafnj

16: end

17: end

18: RebalanceTree(Γ,leaf)

19: end

through the inner nodes up to the root. See Algorithm 7.5 for a formal description. Again, rebalancing the resulting tree is required.

Merging multiple trees We can repeatedly combine the previously explained steps of tree extension and tree merging given a range tokenτQthat covers multiple indexed trees. In more details, the root nodes of all treesΓiTbtogether withΓ(0),Γ(1)and the newly queried range tokenτQare sent to the client. The client