over-encryption: management of access control evolution on ...over-encryption: management of access...
TRANSCRIPT
Over-encryption: Management of Access ControlEvolution on Outsourced Data
Sabrina De Capitani di VimercatiDTI - Universita di Milano
26013 Crema - Italy
Sara ForestiDTI - Università di Milano
26013 Crema - Italy
Sushil JajodiaCSIS - George Mason
UniversityFairfax, VA 22030-4444
Stefano ParaboschiDIIMM - Università di Bergamo
24044 Dalmine - Italy
Pierangela SamaratiDTI - Università di Milano
26013 Crema - Italy
ABSTRACTData outsourcing is emerging today as a successful paradigmallowing users and organizations to exploit external servicesfor the distribution of resources. A crucial problem to beaddressed in this context concerns the enforcement of selec-tive authorization policies and the support of policy updatesin dynamic scenarios.
In this paper, we present a novel solution to the enforce-ment of access control and the management of its evolution.Our proposal is based on the application of selective encryp-tion as a means to enforce authorizations. Two layers ofencryption are imposed on data: the inner layer is imposedby the owner for providing initial protection, the outer layeris imposed by the server to reflect policy modifications. Thecombination of the two layers provides an efficient and ro-bust solution. The paper presents a model, an algorithm forthe management of the two layers, and an analysis to iden-tify and therefore counteract possible information exposurerisks.
1. INTRODUCTIONContrary to the vision of a few years ago, where many
predicted that Internet users would have in a short timeexploited the availability of pervasive high-bandwidth net-work connections to activate their own servers, users are to-day, with increasing frequency, resorting to service providersfor disseminating and sharing resources they want to makeavailable to others.
The continuous growth of the amount of digital infor-mation to be stored and widely distributed, together withthe always increasing storage, support the view that serviceproviders will be more and more requested to be responsiblefor the storage and the efficient and reliable distribution of
Permission to copy without fee all or part of this material isgranted providedthat the copies are not made or distributed for direct commercial advantage,the VLDB copyright notice and the title of the publication and its date appear,and notice is given that copying is by permission of the Very Large DataBase Endowment. To copy otherwise, or to republish, to post on serversor to redistribute to lists, requires a fee and/or special permission from thepublisher, ACM.VLDB ‘07, September 23-28, 2007, Vienna, Austria.Copyright 2007 VLDB Endowment, ACM 978-1-59593-649-3/07/09.
content produced by others, realizing a “data outsourcing”architecture on a wide scale. This important trend is par-ticularly clear when we look at the success of services likeYouTube, Flickr, Blogger, MySpace, and many others in the“social networking” environment.
When storage and distribution do not involve publicly re-leasable resources, selective access techniques must be en-forced. In this context, it is legitimate for the data owner todemand the data not to be disclosed to the service provideritself, which, while trustworthy to properly carry out the re-source distribution functions, should not be allowed accessto the resource content.
The problem of outsourcing resource management to a“honest but curious” service has recently received consider-able attention by the research community and several ad-vancements have been proposed. The different proposalsrequire the owner to encrypt the data before outsourcingthem to the service. Most proposals assume that the dataare encrypted with a single key only [7, 10, 11]. In sucha context, either authorized users are assumed to have thecomplete view on the data or, if different views need to beprovided to different users, the data owner needs to partic-ipate in the query execution to possibly filter the result ofthe service provider. Other proposals [13, 18], developedfor the protection of XML documents, avoid this problemby applying selective encryption, where different keys areused to encrypt different portions of the XML tree. In theoutsourcing scenario, all these proposals, in case of updatesof the authorization policy, would require to re-encrypt theresources and resend them to the service. If the owner doesnot have the resources stored locally, a further preliminarystep is needed to re-acquire them from the service and de-crypt them.
In this paper, we propose a solution that removes theseissues, facilitating the successful development of outsourc-ing data in emerging scenarios. In particular, we look at theproblem of defining and assigning keys to users, by exploit-ing hierarchical key assignment schemes [3, 4, 8, 15], and ofefficiently supporting policy changes. Indeed, in scenariosinvolving potentially huge sets of resources of considerablesize, re-encryption and re-transmission by the owner maynot be acceptable. The advantage compared with a solutionrequiring to re-send a novel encrypted version of the resource
123
is typically huge and arbitrarily large (if the resource has asize of 1 GByte and the request to the server requires a 100-byte packet, in terms of network traffic, compared to thetransmission of the re-encrypted resource, the improvementis in the order of 107).
The contribution of this paper is threefold. First (Sec-tion 2), we propose a formal base model for the correctapplication of selective encryption. The model allows thedefinition of an encryption policy equivalent to the autho-rization policy to be enforced on the resources. We notethat, while it is in principle advisable to leave authorization-based access control and cryptographic protection separate,in the outsourcing scenario such a combination can provesuccessful: selective encryption allows selective access to beenforced by the service provider itself without the ownerintervention.
Second (Section 3 and Section 4), building on the basemodel we propose the use of a two-layer approach to en-force selective encryption without requesting the owner tore-encrypt the resources every time there is a change in theauthorization policy. The first layer of encryption is appliedby the data owner at initialization time (when releasing theresource for outsourcing), the second layer of encryption isapplied by the service itself to take care of dynamic pol-icy changes. Intuitively, the two-layer encryption allows theowner to outsource, besides the resource storage and dis-semination, the authorization policy management, while notreleasing data to the provider.
Third (Section 5), we provide a characterization of thedifferent views of the resources by different users and char-acterize potential risks of information exposures due to dy-namic policy changes. The investigation allows us to con-clude that, while an exposure risk may exist, it is well de-fined and identifiable. This allows the owner to address theproblem and minimize it at design time. Also, the fact thatexposure arises only in specific situations and over well iden-tified resources, allows the owner to completely eliminate itby resorting to re-encryption when necessary.
An important strength of our solution is that it doesnot substitute the current proposals, rather it complementsthem, enabling them to support encryption in a selectiveform and easily enforce dynamic policy changes.
2. BASE MODELConsistently with the typical outsourcing scenario, we dis-
tinguish three roles: the data owner , who creates the re-source; the server , who receives by the data owner a re-source in an encrypted format and makes it available onthe network; and the user , who exploits the knowledge ofa small shared secret (a key) and possibly additional publicinformation (typically available on the server) to access theresource plaintext.
2.1 Keys and tokensWe assume the existence of a set of symmetric encryption
keys K in the system. Also, we exploit the existence of thekey derivation method proposed by Atallah’s et al. [4] basedon the definition and computation of public tokens that allowthe derivation of keys from other keys. Given two keys ki
and kj , a token ti,j is defined as ti,j = kj ⊕h(ki, lj), where ljis a publicly available label associated with kj , ⊕ is the bit-a-bit xor operator and h is a deterministic cryptographicfunction (in [4] it was proposed the use of a secure hash
'&%$ !"#v1
��99
999 '&%$ !"#v2
��
'&%$ !"#v3
�������
��99
999 '&%$ !"#v4
��
'&%$ !"#v5
���������
'&%$ !"#v6
%%KKKKKKK '&%$ !"#v7
'&%$ !"#v8
source dest valuev1.k v6.k v6.k ⊕ h(v1.k, l6)v2.k v6.k v6.k ⊕ h(v2.k, l6)v3.k v6.k v6.k ⊕ h(v3.k, l6)v3.k v7.k v7.k ⊕ h(v3.k, l7)v4.k v7.k v7.k ⊕ h(v4.k, l7)v5.k v8.k v8.k ⊕ h(v5.k, l8)v6.k v8.k v8.k ⊕ h(v6.k, l8)
(a) (b)
Figure 1: An example of key derivation
r1 r2 r3 r4 r5 r6 r7 r8A 0 0 0 0 1 1 1 1B 0 0 0 0 1 1 1 1C 1 1 1 1 1 1 1 1D 0 0 1 1 0 0 0 0E 0 0 0 0 0 0 0 1
Figure 2: An example of access matrix
u φ(u)A v1.k
B v2.kC v3.kD v4.k
E v5.k
r φ(r)r1,r2 v3.k
r3,r4 v7.kr5,r6,r7 v6.k
r8 v8.k
(a) (b)
Figure 3: An example of key assignment
function). Since keys need to remain secret, while tokens arepublic, the use of tokens greatly simplifies key management.Key derivation via tokens can be applied in chains: a chainof tokens is a sequence ti,l, . . . , tn,j of tokens such that tc,d
follows ta,b in the chain only if b = c. This is formallycaptured by the following definition, associating with eachkey the set of keys reachable by it via chains of tokens.
Definition 1. (Key derivation function).Let K be the set of symmetric encryption keys in the system,and T the set of tokens in the public catalog.
The direct key derivation function τ : K 7→ 2K is defined asτ (ki)={kj∈K | ∃ti,j∈T }.
The key derivation function τ∗ : K 7→ 2K is a function suchthat τ∗(ki) is the set of keys derivable from ki by chains oftokens, including the key itself (chain of length 0).
We can graphically represent keys and tokens through agraph, having a vertex vi associated with each key in thesystem, denoted vi.k, and an edge connecting two vertices(vi, vj) if token ti,j belongs to the public token catalog T .Chains of tokens then correspond to paths in the graph.In other words, the key derivation function associates witheach τ∗(k) the keys of vertices reachable from the vertexassociated with k in the graph. For instance, Figure 1(a)represents an example of graph corresponding to a set of 8keys, along with its public token catalog composed of 7 items(see Figure 1(b)). As an example, τ (v3.k)={v6.k,v7.k} andτ∗(v3.k)={v3.k,v6.k,v7.k,v8.k}.
2.2 Access control and encryption policiesConsistently with the data distribution and dissemination
scenario, we assume access by users to the outsourced datato be read-only. The data owner therefore defines a discre-tionary access control policy to regulate read operations onthe outsourced resources. Authorizations are of the form〈user,resource〉.1
1For the sake of simplicity, here we do not deal with the fact
124
Let U be the set of users of the system and R the set ofoutsourced resources. Authorizations can be modeled via atraditional access matrix A, with a row for each user u∈U ,a column for each resource r∈R. Each entry A[u, r] is setto 1 if u can access r; 0 otherwise. Figure 2 illustrates anexample of access matrix with five users (A, B, C, D, E)and eight resources (r1, r2, . . . , r8). Given an access matrixA over sets U and R, acl(r) denotes the access control listof r (i.e., the set of users that can access r), while cap(u)denotes the capability list of u (i.e., the set of resources thatu can access). For instance, with reference to the matrix inFigure 2, acl(r1)={C} and cap(B)={r5,r6,r7,r8}.
Our initial goal is to represent the authorizations bymeans of proper encryption and key distributions. To avoidusers having to store and manage a huge number of (se-cret) keys, we exploit the key derivation method via tokens.Exploiting tokens, the release to each user of a set of keysK = {k1, . . . , kn} can be equivalently obtained by the re-lease to each user of a single key ki∈ K and the publicationof a set of tokens allowing to derive (directly or indirectly)all keys kj∈ K, j 6= i. A major advantage of using tokens isthat they are public (typically they will be stored togetherwith resources) and allow each user to derive multiple en-cryption keys, while having to securely manage a single one.In the following, we use K and T to denote the set of keysand tokens defined in the system, respectively.
We assume that each user is associated with a single key,communicated to her by the owner on a secure channel atthe time the user joins the system. Also, each resource canbe encrypted by using a single key.
Definition 2. (Key assignment). A key assignment is afunction φ : U ∪ R 7→ K, which associates with each useru ∈ U the (single) key released to her and with each resourcer ∈ R the (single) key with which the resource is encrypted.
It is easy to see that, by Definition 1, each user u canretrieve (via her own key φ(u) and the set of public tokensT ) all the keys derivable from φ(u), that is, all the keys inτ∗(φ(u)). In the following, we use φ∗(u) as a short hand forτ∗(φ(u)).Figure 3 represents an example of key assignment, with ref-erence to the key graph in Figure 1(a). Composing the graphin Figure 1(a) with the function defined in Figure 3(a), weobtain the set of keys each user knows. As an example,φ∗(B)=τ∗(v2.k)={v2.k,v6.k,v8.k}. A key derivation definedby tokens and the corresponding key assignment realize anencryption policy. This is captured by the following defini-tion.
Definition 3. (Encryption policy). Let E=(τ∗, φ) be anencryption policy composed of a key derivation function τ∗
and a key assignment function φ.
An encryption policy E is said to correctly model a set ofauthorizations A if and only if users are able to decrypt alland only the resources for which they have the authorization.This is formally captured by the following definition.
Definition 4. (Correctness). Let E=(τ∗, φ) be an encryp-tion policy, and A an access control policy. E is said to
that authorizations can be specified for predefined groups ofusers and groups of resources. Our approach will supportdynamic grouping, therefore subsuming any statically de-fined group.
correctly enforce A, denoted E ⇐⇒ A, iff both the followingconditions hold:
• Soundness. ∀u ∈ U , r ∈ R :φ(r) ∈ φ∗(u) =⇒ A[u, r] = 1
• Completeness. ∀u ∈ U , r ∈ R :A[u, r] = 1 =⇒ φ(r) ∈ φ∗(u)
As an example, the encryption policy illustrated in Fig-ures 1 and 3 correctly enforces the policy represented by theaccess matrix in Figure 2.
A straightforward approach for defining a correct E canexploit the hierarchy among sets of users, which is inducedby the partial ordering of sets of users, based on the setcontainment relationship (⊆) [9]. This strategy works asfollows:
• define a key for each access control list as well as foreach singleton set of users (when not already includedin the acls);
• define tokens between keys corresponding to sets ofusers in hierarchical relationships; 2
• assign to each user u the key corresponding to its sin-gleton group {u};
• encrypt each resource r with the key associated withacl(r).
As an example, consider policy A in Figure 2. Since thereis a set of 4 different acls (i.e., {C}, {C, D}, {A, B, C},{A, B, C, E}), which includes a singleton acl , and 5 users,we need to define 8 different keys. In particular, keysk1,. . . k5 are associated, in the order, with users A,. . . ,E, k6
is associated with {A, B, C}, k7 with {C, D}, and k8 with{A, B, C, E}. We then define a token between each pair ofkeys (ki, kj), i, j = 1 . . . , 8 and i 6= j, such that the set ofusers corresponding to ki is included in the set of users corre-sponding to kj . Figure 1(a) illustrates a graphical represen-tation of these keys and tokens, where vertex vi correspondsto key ki. Resources r1, . . . , r8 are then encrypted as shownin Figure 3(b).
3. TWO LAYER MODELThe model described in Section 2 assumes keys and tokens
are computed, on the basis of the existing authorization pol-icy, prior to sending the encrypted resources to the server.While we can note that, in general, the authorizations spec-ified at initialization time may not change frequently, manysituations require dynamic changes of authorizations, for ex-ample, for granting privileges to new users.
Every time an authorization on a resource r is granted orrevoked, acl(r) changes accordingly. In terms of the encryp-tion policy this implies the need to change the key used toencrypt the resource (i.e., φ(r)) to make it accessible (i.e.,intelligible) only to users in the new acl . This operation re-quires then decrypting the resource (with the key with whichit is currently encrypted) to retrieve the original plaintext(the owner may possibly store resources only on the externalprovider without keeping a local copy), and then re-encryptit with the new key. Imposing such an overhead (in terms
2As usual, only direct relationships are considered [12].
125
of both transmission and computation) for managing autho-rization changes does not fit our working assumption, wherethe owner outsources its data since it does not have the nec-essary resources and transmission channels to manage them.
We put forward the idea of outsourcing to the server, be-sides the resource storage, the authorization management aswell. Note that this delegation is possible since the serveris considered trustworthy to properly carry out the service.Recall, however, that the server is not trusted with confiden-tiality (honest but curious). For this reason, our solution hasbeen thought of with the goal of minimizing the case of theserver colluding with the users to breach data confidential-ity (see Section 5). The way to make this possible is via asolution that enforces policy changes on encrypted resourcesthemselves (without the need of decrypting them), and canthen be performed by the server.
3.1 Two-layer encryptionTo delegate policy changes enforcement to the server,
avoiding re-encryption for the data owner, we adopt a twolayer encryption approach. The owner encrypts the re-sources and sends them to the server in encrypted form;the server can impose another layer of encryption (followingdirections by the data owner).
We then distinguish two layers of encryption.
• Base Encryption Layer (BEL), performed by thedata owner before transmitting data to the server. Itenforces encryption on the resources according to thepolicy existing at initialization time.
• Surface Encryption Layer (SEL), performed by theserver over the resources already encrypted by the dataowner. It enforces the dynamic changes over the policy.
Both layers enforce encryption by means of a set of sym-metric keys and a set of public tokens between these keys, asillustrated in Section 2, although some adaptations are nec-essary as explained respectively in Sections 3.1.1 and 3.1.2.
In terms of efficiency, the use of a double layer of encryp-tion does not appear as a significant computational burden;experience shows that current systems have no significantdelay when managing encryption on data coming from ei-ther the network or local disks, this is also testified by thewidespread use of encryption on network traffic and for pro-tecting the storage of data on local file systems [16].
3.1.1 Base Encryption LayerCompared with the model presented in Section 2, in the
BEL level we distinguish two kinds of keys: derivation keysand access keys. Access keys are the ones actually used toencrypt resources, while derivation keys are used to providethe derivation capability via tokens, i.e., tokens can be de-fined only with the derivation key as starting point. Eachderivation key k is always associated with an access key ka
obtained by applying a secure hash function to k, that is,ka = h(k). In other words, keys at the BEL level alwaysgo in pairs 〈k, ka〉. The rationale for this evolution is todistinguish the two roles associated with keys, namely: en-abling key derivation (applying the corresponding tokens)and enabling resource access. The reason for which such adistinction is needed will be clear in Section 4.
A key derivation function τ∗
b : K 7→ 2K associates witheach derivation key the set of keys derivable from it - either
directly or indirectly - via the public token catalog and/orthe application of the hashing function. Again, the keyderivation relationship is represented by means of a graph,which now has a vertex b for each pair of keys 〈k, ka〉 andan edge connecting vertices (bi, bj) if there is a token inthe public catalog allowing the derivation of either bj.k orbj .ka from bi.k. To graphically distinguish tokens leadingto derivation keys from tokens leading to access keys we usedashed lines for the latter. Given a key ki, τ∗
b (ki) returnsall keys reachable from vertex b with b.k=ki by followingpaths of tokens and hashing. Note that dashed edges canonly appear as the last step of the path (and they allow thederivation of the access key only).
A key assignment is a function φb : U ∪ R 7→ K thatassociates with each user u∈ U the (single) derivation keyreleased to the user by the data owner and with each re-source r∈ R the (single) access key with which the resourceis encrypted by the data owner. Figure 4 illustrates an ex-ample of BEL corresponding to the example introduced inSection 2.
3.1.2 Surface Encryption LayerAs in the base model of Section 2, at the SEL level there
is no distinction between derivation and access keys (intu-itively a single key carries out both functions).
Again, we define a key derivation function τ∗
s : K 7→ 2K
that can be represented by means of a graph having a vertexfor each key k defined at SEL and an edge connecting vertices(si, sj) if there is a token in the public catalog allowing thederivation of sj.k from si.k.
A key assignment is a function φs : U ∪ R 7→ K ∪ {null}that associates with each user u∈ U the (single) key releasedto the user by the server and with each resource r∈ R the(single) key with which the resource is encrypted by theserver (if any).
3.1.3 BEL and SEL combinationIn the two-layer approach, each resource can then be en-
crypted twice: at the BEL level first, and at the SEL levelthen. Users can access resources only via the SEL level.Each user u receives two keys: one to access the BEL andthe other to access the SEL.3 Users will be able to accessresources for which they know both the keys (BEL and SEL)used for encryption.
The consideration of the two levels requires to restate thecorrectness property of the encryption policy, which is nowdefined as follows.
Definition 5. (Correctness). Let Eb=(τ∗
b , φb) be an en-cryption policy at the BEL level, Es=(τ∗
s , φs) be an encryp-tion policy at the SEL level, and A an access control pol-icy. The pair 〈Eb,Es〉 is said to correctly enforce A, denoted〈Eb,Es〉 ⇐⇒ A, iff both the following conditions hold:
• Soundness. ∀u ∈ U , r ∈ R :φb(r) ∈ φ∗
b(u) ∧ φs(r) ∈ φ∗
s (u) =⇒ A[u, r] = 1
• Completeness. ∀u ∈ U , r ∈ R :A[u, r] = 1 =⇒ φb(r) ∈ φ∗
b(u) ∧ φs(r) ∈ φ∗
s (u)
3To simplify key management, the user key φs(u) for SELcan be obtained by the application of a secure hash functionfrom the user key φb(u) for BEL. In this case, the data ownerneeds to send in the initialization phase to the server the listof SEL keys of each user.
126
BEL Delta SEL Full SEL
u φb(u)A b1.kB b2.kC b3.kD b4.kE b5.k
r φb(r)r1,r2 b3.ka
r3,r4 b7.ka
r5,r6,r7 b6.ka
r8 b8.ka
u φs(u)A s1.kB s2.kC s3.kD s4.kE s5.k
r φs(r)r1,. . . ,r8 null
u φs(u)A s1.kB s2.kC s3.kD s4.kE s5.k
r φs(r)r1,r2 s3.kr3,r4 s7.k
r5,r6,r7 s6.kr8 s8.k
/.-,()*+b1
��77
777
/.-,()*+b2
��
/.-,()*+b3
�������
��77
777
/.-,()*+b4
��
/.-,()*+b5
���������
/.-,()*+b6
$$JJJJJJJ /.-,()*+b7
/.-,()*+b8
'&%$ !"#s1 '&%$ !"#s2 '&%$ !"#s3 '&%$ !"#s4 '&%$ !"#s5 '&%$ !"#s1
��77
77'&%$ !"#s2
��
'&%$ !"#s3
������
��77
77'&%$ !"#s4
��
'&%$ !"#s5
���������
'&%$ !"#s6
$$JJJJJJJ '&%$ !"#s7
'&%$ !"#s8
Figure 4: An example of BEL and SEL combination with the Delta SEL and the Full SEL approaches
In principle, any encryption policy at BEL and SEL can bespecified as long as their combination is correct with respectto the authorizations.
Let A be the authorization policy at the initialization timeand let (τ∗
b , φb) be the encryption policy at the BEL levelcorrectly enforcing it (i.e., (τ∗
b , φb) ⇐⇒ A). We envision twobasic approaches that can be followed in the construction ofthe two levels.
Full SEL. The SEL policy is initialized to reflect exactly (i.e.,to repeat) the BEL policy: for each derivation key inBEL a corresponding key is defined in SEL; for eachtoken in BEL, a corresponding token is defined in SEL.Note that the key derivation function τ∗
s correspondsto a graph which is isomorphic to the one existing atthe BEL level. Each user is assigned the unique keyφs(u) corresponding to her φb(u). Each resource isencrypted with the unique key φs(r) corresponding tothe unique derivation key associated with access keyφb(r). The SEL policy models exactly the BEL policy,and hence by definition is correct with respect to theaccess control policy (i.e., (τ∗
s , φs) ⇐⇒ A).
Delta SEL. The SEL policy is initialized to not carry out anyover-encryption. Each user u is assigned a unique keyφs(u). No encryption is performed on resources, thatis, ∀r ∈ R : φs(r) = null. The SEL level itself doesnot provide any additional protection at start time,but it does not modify the accesses allowed by BEL.
We note that a third approach could be possible, wherethe authorization enforcement is completely delegated atthe SEL level and the BEL simply applies a uniform over-encryption (i.e., with the same key released to all users) toprotect the plaintext content from the server’s eyes. We donot consider this approach as it presents a significant expo-sure to collusion (Section 5).
It is easy to see that all the approaches described pro-duce a correct two layer encryption. In other words, givena correct encryption policy at the BEL level, the approachesproduce a SEL level such that the pair 〈Eb,Es〉 correctly en-forces the authorizations.
The reason for considering both the Full SEL andDelta SEL approaches is the different performance and pro-tection guarantees that they enjoy. In particular, Full SEL
always requires double encryption to be enforced (even when
authorizations remain unvaried), thus doubling the decryp-tion load of users for each access. By contrast, the Delta SEL
approach requires double encryption only when actuallyneeded to enforce a change in the authorizations. However,as we will see in Section 5, the Delta SEL is characterizedby greater information exposure, which instead does not af-fect the Full SEL approach. The choice between one or theother can then be a trade-off between costs and resilience toattacks.
We close this section with a remark on the implementa-tion. In the illustration of our approach we always assumeover-encryption to be managed with a direct and completeencryption and decryption of the resource, as needed. Wenote however that the server can, at the SEL level, applya lazy encryption approach, similar to the copy-on-write(COW) strategy used by most operating systems, and actu-ally over-encrypt the resource when it is first accessed (andthen storing the computed encrypted representation); theserver may choose also to always store the BEL representa-tion and then dynamically apply the encryption driven bythe SEL when users access the resource.
4. POLICY UPDATESPolicy update operations can be of three kinds: 1) insert-
ing/deleting a user; 2) inserting/deleting a resource; and3) granting/revoking an authorization. We note that inser-tion/deletion of users and resources do not have any impacton the policy (and consequently on the keys) as long asthese users and resources are not involved in authorizations.Without loss of generality, we restrict ourselves to the con-sideration of granting and revoking of authorizations (withthe note that deleting a user/resource implies revoking allthe authorizations in which the user/resource is involved).Also, for the sake of simplicity, we assume grant and revokeoperations to be referred to a single user u and a single re-source r. Their extension to sets of users and resources isimmediate.
Policy updates are demanded and regulated by the owner(i.e., at the BEL level). The two-layer approach enablesthe enforcement of policy updates without the need for theowner to re-encrypt, and to resend them to the server. Bycontrast, the owner just adds (if necessary) some tokensat the BEL level and delegates policy changes to the SEL
level by possibly requesting the server to over-encrypt theresources. The SEL level (enacted by the server) receives
127
over-encryption requests by the BEL level (under the controlof the data owner) and operates accordingly, adjusting to-kens and possibly encrypting (and/or decrypting) resources.
Before analyzing grant and revoke operations let us thensee the working of over-encryption at the SEL level.
4.1 Over-encryptThe SEL level regulates the update process through over-
encryption of resources. It receives from the BEL requests ofthe form over-encrypt(R, U) corresponding to the demandto the SEL to make the set of resources R accessible only tousers in U . Note here that the semantics is different in thetwo different encryption modes. In the Full SEL approach,over-encryption must reflect the actual access control policyexisting at any given time. In other words, it must reflect,besides the - dynamic - policy changes not reflected in theBEL, also the BEL policy itself. In the Delta SEL approach,over-encryption is demanded only when additional restric-tions (with respect to those enforced by the BEL) need tobe enforced. As a particular case, here, the set of users Umay be all when - while processing a grant operation - theBEL determines that its protection is sufficient and there-fore requests the SEL not to enforce any restriction and topossibly remove an over-encryption previously imposed.
For the sake of simplicity, in the algorithm we make useof a function Anc users that, given the key s.k of a vertex,returns the set of users that can derive it (i.e., can reachthe vertex via a path of tokens). Anc users(s.k) is thereforea short-hand defined as Anc users(s.k)={u ∈ U | s.k ∈φ∗
s (u)}, which can be dynamically computed or explicitlymaintained for each vertex.
Let us then see how the algorithm works. Algorithm over-
encrypt takes a set of resources R and a set of users U asinput. First, it checks whether there exists a vertex s whosekey s.k is used to encrypt resources in R and the set ofusers that can derive s.k is equal to U (step 2). If such avertex exists, intuitively, this means that resources in R areover-encrypted with a key that reflects the current acl ofresources in R. Note that since all resources in R share thesame key, it is sufficient to check the above condition on anyof the resources r′ in R. If this condition is evaluated totrue, the algorithm terminates. Otherwise, if the resourcesin R are currently over-encrypted (step 2.1), they are firstdecrypted.4 Then, if the set of users that should be allowedaccess to the resources in R by the SEL is not all (step 2.2),over-encryption is necessary. (No operation is executed oth-erwise, as U=all is the particular case of Delta SEL ap-proach discussed above.) The algorithm proceeds by check-ing the existence of a vertex s such that the set of users thatcan reach key s.k (i.e., belonging to Anc users(s.k)) corre-sponds to U . If such a vertex exists, then the key that willbe used for over-encryption is set to s.k. Otherwise, a newkey key is generated and a corresponding new vertex snew
is created, setting then snew .k=key . Vertex snew is then in-serted in the SEL graph and tokens defined accordingly soto make snew .k derivable by all users in U (in terms of thegraph snew must be reachable by all the keys associated withusers in U ). To this purpose, the algorithm checks existing
4If φs(r) is no more used to protect other resources in thesystem, the corresponding vertex can be removed. In thiscase, all parents of vertex φs(r) are directly connected to itschildren and the token catalog is changed accordingly [4].For simplicity, we omit this operation.
vertices in decreasing order of cardinality of Anc users. Foreach si considered, if the set of users that can reach keysi.k (i.e., Anc users(s i.k)) is contained in U , a new tokenfrom si.k to snew .k is generated and added. Set U is thenupdated by removing the set of users Anc users(s i.k) thatcan now reach key snew .k thanks to the new token. Thistoken generation process continues until U is empty, i.e.,until all users have been connected to the key. Finally, allresources in R are encrypted with the designated key andthe key assignment φs updated accordingly.
4.2 Grant and revokeConsider first a grant request grant(r,u) to grant user
u access to resource r. The BEL level starts and regulatesthe update process as follows. First, acl(r) is updated toinclude u, that is, A[u, r] = 1 (step 1). Then, the algorithmretrieves the vertex bi whose access key bi.ka is the key withwhich r is encrypted (step 2). If the resource’s access keycannot be derived by u, then a new token from user’s keyφb(u) to bi.ka is generated and added (step 3). The new to-ken is needed to make bi.ka derivable by u (i.e., belonging toφ∗
b(u)). Note that the separation between derivation and ac-cess keys for each vertex allows us to add a token only givingu access to the key used to encrypt resource r, thus limitingthe knowledge of each user to the information strictly neededto correctly enforce the authorization policy. Indeed, knowl-edge of bi.ka is a necessary condition to make r accessibleby u. However, there may be other resources r′ that areencrypted with the same key bi.ka and which should not bemade accessible to u. Since releasing bi.ka would make themaccessible to u, they need to be over-encrypted so to makethem accessible to users in acl(r′) only. Then, the algorithmdetermines if such a set of resources R′ exists (step 4). IfR′ is not empty, the algorithm partitions R′ in sets suchthat each set S ⊆ R′ includes all resources characterized bythe same acl , denoted aclS (step 5.1). For each set S, thealgorithm calls over-encrypt(S, aclS) to demand SEL toexecute an over-encryption of S for users in aclS (step 5.2).In addition, the algorithm requests the SEL level to syn-chronize itself with the policy change. Here, the algorithmbehaves differently depending on the encryption model as-sumed. In the case of Delta SEL (step 6.1), the algorithmfirst controls whether the set of users that can reach theresource’s access key (i.e., belonging to Anc users(bi.ka))corresponds to acl(r). If so, the BEL encryption sufficesand no protection is needed at the SEL level, and thereforea call over-encrypt({r},all) is requested. Otherwise, acall over-encrypt({r},acl(r)) requests the SEL to make raccessible only to users in acl(r). In the case of Full SEL
(step 6.2), this is done by calling over-encrypt(r,acl(r)),requesting the SEL to synchronize its policy so to make raccessible only by the users in acl(r).
Consider now a revoke request revoke(r,u) to revoke fromuser u access to resource r. The algorithm updates acl(r)to remove user u, that is, A[u, r] = 0 (step 1). Then, itcalls over-encrypt({r},acl(r)) to demand SEL to make raccessible only to users in acl(r) (step 2).
In terms of performance, the algorithm only requires a di-rect navigation of the BEL and SEL structure and it producesthe identification of the requests to be sent to the server ina time which in typical scenarios will be less than the timerequired to send the messages to the server.
128
BEL SEL
GRANT(r,u)
1. acl(r) := acl(r) ∪ {u}2. find the vertex bi with bi.ka = φb(r)3. if φb(r)/∈φ∗
b(u) thenfind the vertex bj with bj.k = φb(u)add token(bj .k,bi.ka)
4. find the set R′ of resources r′ such thatr′ 6=r , φb(r
′)=φb(r), Anc users(bi.ka) 6=acl(r′)5. if R′ 6= ∅ then
5.1 Partition R′ in sets such that each set Scontains resources with the same acl aclS
5.2 for each set S do over-encrypt(S ,aclS)6. case encryption model of
6.1 Delta SEL:if Anc users(b i.ka)=acl(r) then
over-encrypt({r},all)else
over-encrypt({r},acl(r))6.2 Full SEL:
over-encrypt({r},acl(r))
REVOKE(r,u)1. acl(r) := acl(r) − {u}2. over-encrypt({r},acl(r))
OVER-ENCRYPT(R,U )1. let r′ be a resource in R2. if (∃ a vertex s : s.k = φs(r
′) ∧ Anc users(s.k) = U ) then exitelse
2.1 if φs(r′) 6= null then decrypt all r∈R
2.2 if U 6=all thenif ∃ a vertex s such that Anc users(s.k)=U then
key := s.kelse
generate and add to Ks a new key keycreate a new vertex snew
snew.k := keywhile U 6= ∅
choose a vertex si by considering vertices indecreasing order of cardinality of Anc users(s i.k)
if Anc users(s i.k)⊆U thenadd token(si.k,snew .k)U := U − Anc users(s i.k)
for each r∈R doφs(r) := keyencrypt r with key
Figure 5: Algorithms for granting and revoking authorizations
4.3 ExampleWe present an example that illustrates the behavior of the
revoke and grant operations described above. We assumethe initial configuration depicted in Figure 4. Figure 6 illus-trates the evolution of the encryption policies at both BEL
and SEL in the Full SEL and Delta SEL modes, upon the fol-lowing sequence of policy changes. Here, dashed edges atthe BEL level correspond to the tokens added by the grant
algorithm.
• grant(r5,D): key b6.ka used to encrypt r5 does notbelong to φ∗
b(D). The data owner therefore adds aBEL token t4,6 in the BEL. Since b6.ka is also used toencrypt resources r6 and r7, these resources have to beover-encrypted in such a way that they are accessibleonly to users A, B, and C. In the Delta SEL scenario,over-encrypt creates a new vertex s6 for resources r6and r7. The protection of resource r5 at BEL level isinstead sufficient and no over-encryption is needed. Inthe Full SEL scenario resources r6 and r7 are alreadycorrectly protected and r5 is instead over-encryptedwith key s9.k.
• revoke(r2,C): user C is removed from acl(r2). Sincenow this acl becomes empty, resource r2 has to be over-encrypted with a key that no user can compute. Con-sequently, both in the Delta SEL and in the Full SEL
scenario, a new vertex s⊤ is created and its key is usedto protect r2.
• grant(r4,E): b7.ka used to encrypt r4 does not be-long to φ∗
b(E). The data owner therefore adds aBEL token t5,7 allowing E to compute b7.ka. Sinceb7.ka is also used to protect r3, we need to call over-
encrypt(r3,{C, D}). In the Delta SEL scenario, over-
encrypt creates a new vertex s7 for r3, while the
BEL protection of resource r4 is sufficient and no over-encryption is needed. In the Full SEL scenario, r3 isalready correctly protected and r4 is over-encryptedwith s10.k, which only C, D, and E can derive.
• grant(r6,D): b6.ka used to encrypt r6 already belongsto φ∗
b(D), and therefore the BEL encryption policydoes not change. However, since r6 shares its BEL
access key with r5 and r7, the SEL encryption pol-icy may need to be updated. In particular, both theDelta SEL and the Full SEL scenario already correctlyenforce the policy w.r.t. r5 and r7. In the Delta SEL
scenario, the over-encryption of r6 is removed becausethe BEL encryption policy is sufficient, while in theFull SEL scenario r6 is over-encrypted with a new keys9.k.
4.4 CorrectnessWe now prove that the algorithm implementing the grant
and revoke operations preserves the correctness of the en-cryption policy.
Theorem 4.1 (Correctness). Let Eb=(τ∗
b , φb) be anencryption policy at the BEL level, Es=(τ∗
s , φs) be an encryp-tion policy at the SEL level, and A an access control policysuch that 〈Eb,Es〉 ⇐⇒ A. Algorithms in Figure 5 generatea new Eb
′ = (τ ′∗
b , φ′b), Es
′ = (τ ′∗
s , φ′s), and A′ such that
〈Eb′, Es
′〉 ⇐⇒ A′.
Proof. (sketch)Since we start with a BEL encryption policy and a SEL
encryption policy that satisfy Definition 5 (as discussed inSection 3.1.3), we will therefore consider only users and re-sources for which the encryption policies change. Grant andrevoke are based on the correct enforcement of the over-encryption operation. We then examine it first.
129
BEL Delta SEL Full SEL
grant(r5,D) over-encrypt(r6,r7,ABC) over-encrypt(r6,r7,ABC)over-encrypt(r5,all) over-encrypt(r5,ABCD)
/.-,()*+b1
��77
777
/.-,()*+b2
��
/.-,()*+b3
�������
��77
777
/.-,()*+b4
��zz
/.-,()*+b5
���������
/.-,()*+b6
$$JJJJJJJ /.-,()*+b7
/.-,()*+b8
'&%$ !"#s1
��77
77'&%$ !"#s2
��
'&%$ !"#s3
������
'&%$ !"#s4 '&%$ !"#s5
'&%$ !"#s6
r φs(r)r7,r6 s6.k
r1,. . . ,r5 nullr8 null
'&%$ !"#s1
��77
77'&%$ !"#s2
��
'&%$ !"#s3
������
��77
77'&%$ !"#s4
��
'&%$ !"#s5
���������
'&%$ !"#s6
$$JJJJJJ
J
��
'&%$ !"#s7
zzttttttt
'&%$ !"#s9 '&%$ !"#s8
r φs(r)r1,r2 s3.kr3,r4 s7.k
r5 s9.kr6,r7 s6.k
r8 s8.k
revoke(r2,C) over-encrypt(r2,∅) over-encrypt(r2,∅)
/.-,()*+b1
��77
777
/.-,()*+b2
��
/.-,()*+b3
�������
��77
777
/.-,()*+b4
��zz
/.-,()*+b5
���������
/.-,()*+b6
$$JJJJJJJ /.-,()*+b7
/.-,()*+b8
/.-,()*+s⊤
'&%$ !"#s1
��77
77'&%$ !"#s2
��
'&%$ !"#s3
�������
'&%$ !"#s4 '&%$ !"#s5
'&%$ !"#s6
r φs(r)r2 s⊤.k
r6,r7 s6.kr1 null
r3,r4,r5 nullr8 null
/.-,()*+s⊤
'&%$ !"#s1
��77
77'&%$ !"#s2
��
'&%$ !"#s3
�������
��99
999 '&%$ !"#s4
��
'&%$ !"#s5
���������
'&%$ !"#s6
%%KKKKKKK
��
'&%$ !"#s7
yysssssss
'&%$ !"#s9 '&%$ !"#s8
r φs(r)r1 s3.kr2 s⊤.k
r3,r4 s7.kr5 s9.k
r6,r7 s6.kr8 s8.k
grant(r4,E) over-encrypt(r3,CD) over-encrypt(r3,CD)over-encrypt(r4,all) over-encrypt(r4,CDE)
/.-,()*+b1
��77
777
/.-,()*+b2
��
/.-,()*+b3
�������
��77
777
/.-,()*+b4
��zz
/.-,()*+b5
��
���������
/.-,()*+b6
$$JJJJJJJ /.-,()*+b7
/.-,()*+b8
/.-,()*+s⊤
'&%$ !"#s1
��77
77'&%$ !"#s2
��
'&%$ !"#s3
�������
��99
999 '&%$ !"#s4
��
'&%$ !"#s5
'&%$ !"#s6 '&%$ !"#s7
r φs(r)r2 s⊤.kr3 s7.k
r6,r7 s6.kr1 null
r4,r5 nullr8 null
/.-,()*+s⊤
'&%$ !"#s1
��77
77'&%$ !"#s2
��
'&%$ !"#s3
�������
��99
999 '&%$ !"#s4
��
'&%$ !"#s5
�������������
'&%$ !"#s6
%%KKKKKKK
��
'&%$ !"#s7
yysssssss
��::
:::
'&%$ !"#s9 '&%$ !"#s8 /.-,()*+s10
r φs(r)r1 s3.kr2 s⊤.kr3 s7.kr4 s10.kr5 s9.k
r6,r7 s6.kr8 s8.k
grant(r6,D) over-encrypt(r7,ABC) over-encrypt(r7,ABCD)over-encrypt(r6,all) over-encrypt(r6,ABCD)
/.-,()*+b1
��77
777
/.-,()*+b2
��
/.-,()*+b3
�������
��77
777
/.-,()*+b4
��zz
/.-,()*+b5
��
���������
/.-,()*+b6
$$JJJJJJJ /.-,()*+b7
/.-,()*+b8
/.-,()*+s⊤
'&%$ !"#s1
��77
77'&%$ !"#s2
��
'&%$ !"#s3
�������
��99
999 '&%$ !"#s4
��
'&%$ !"#s5
'&%$ !"#s6 '&%$ !"#s7
r φs(r)r2 s⊤.kr3 s7.kr7 s6.kr1 null
r4,r5,r6 nullr8 null
/.-,()*+s⊤
'&%$ !"#s1
��77
77'&%$ !"#s2
��
'&%$ !"#s3
�������
��99
999 '&%$ !"#s4
��
'&%$ !"#s5
�������������
'&%$ !"#s6
%%KKKKKKK
��
'&%$ !"#s7
yysssssss
��::
:::
'&%$ !"#s9 '&%$ !"#s8 /.-,()*+s10
r φs(r)r1 s3.kr2 s⊤.kr3 s7.kr4 s10.k
r5,r6 s9.kr7 s6.kr8 s8.k
Figure 6: An example of grant and revoke operations
130
Over-encrypt. We need to prove that over-
encrypt(R, U) possibly encrypts all resources inR with a key in such a way that a user u′ can derivesuch a key if and only if u′ ∈ U . The only case we needto consider is when the set of users U is different fromall (when U = all, resources in R are not needed tobe over-encrypted). Then, if the condition in the firstif statement (step 2) is evaluated to true, resourcesin R are already correctly protected and since thealgorithm terminates, the result is correct. Otherwise,resources in R are first possibly decrypted and thenencrypted with the correct key s.k or with the newgenerated key , which is assigned to a new vertexsnew. In the first case, the result is trivially correct.In the second case, correctness is guaranteed by theconstruction of the tokens in the while statement (auser will reach snew .k iff she belongs to U).
Grant. 〈Eb′, Es
′〉 =⇒ A′ (soundness)Consider user u and resource r . From step 3, itis easy to see that φ′
b(r) = φb(r) ∈ φ′∗
b (u). Fromstep 6 and by the correctness of over-encrypt, eitherφ′
s(r) = null or r is over-encrypted with a key suchthat φ′
s(r) ∈ φ′∗
s (u) (user u is included in the currentacl(r)). Since φ′
b(r) ∈ φ′∗
b (u) and φ′
s(r) ∈ φ′∗
s (u), wehave that A′[u, r] = 1.
Consider now the set of resources R′ and supposethat R′ is not empty. For each subset S of R′, user ucan now derive the key used to encrypt such a set ofresources. This implies that ∀r′ ∈ S, φ′
b(r′) = φb(r
′) ∈φ′∗
b (u). However, by the correctness of over-encrypt,a call over-encrypt(S,aclS) guarantees that allresources r′ in S are over-encrypted with a key suchthat ∀r′ ∈ S, φ′
s(r′) 6∈ φ′∗
s (u) because aclS does notinclude user u.
〈Eb′, Es
′〉 ⇐= A′ (completeness)Consider user u and resource r. From step 1, we havethat A′[u, r] = 1. From step 3, it is easy to see thatφ′
b(r) = φb(r) ∈ φ′∗
b (u). Also, from step 6 and by thecorrectness of over-encrypt, either φ′
s(r) = null or ris over-encrypted with a key such that φ′
s(r) ∈ φ′∗
s (u).
Revoke. 〈Eb′, Es
′〉 =⇒ A′ (soundness)Consider user u and resource r . A call over-
encrypt({r},acl(r)) is requested to demand the SEL
to make r accessible only to users in the currentacl(r). We know that φ′
b(r) ∈ φ′∗
b (u). Also, from theover-encrypt correctness, it is easy to see that φ′
s(r)6∈ φ′∗
s (u).
〈Eb′, Es
′〉 ⇐= A′ (completeness)Consider user u and resource r. From step 1 wehave that A[u, r] = 0. The subsequent call over-
encrypt({r},acl(r)) makes resource r no moreaccessible to user u because r is over-encrypted witha key that is no more derivable by u (this property isa consequence of the over-encrypt correctness), thatis, φ′
b(r) ∈ φ′∗
b (u) and φ′
s(r) 6∈ φ′∗
s (u). �
5. PROTECTION EVALUATIONSince the BEL and SEL are corrected at initialization time,
the correctness of the algorithm ensures that the encryption
Server’s view User’s view
r
BEL
SEL
r
BEL
SEL
r
BEL
SEL
r
BEL
SEL
r
BEL
SEL
open locked sel locked bel locked
(a) (b) (c) (d) (e)
Figure 7: Possible views on resource r
policy E correctly models the authorization policy A. Inother words, at any point in time, users will be able to accessonly resources for which they have - directly or indirectly -the necessary keys both at the BEL and at the SEL level.
The key derivation function adopted is proved to be se-cure [4]. We also assume that all the encryption functionsand the tokens are robust and cannot be broken, even com-bining the information available to many users. Moreover,we assume that each user correctly manages her keys, with-out the possibility for a user to steal keys from another user.
It still remains to evaluate whether the approach is vul-nerable to attacks from users who access and store all in-formation offered by the server, or from collusion attacks,where different users (or a user and the server) combine theirknowledge to access resources they would not otherwise beable to access. Note that for collusion to exist, both par-ties should gain in the exchange (as otherwise they will nothave any incentive in colluding). We now discuss possible in-formation exposure, with the conservative assumption thatusers are not oblivious (i.e., they have the ability to storeand keep indefinitely all information they were entitled toaccess). In the discussion we first refer to the Full SEL ap-proach; we will then analyze the Delta SEL approach.
To be able to model exposure, we first start by examiningthe different views that one can have on a resource r. Todo so, we exploit a graphical notation with resource r in thecenter and with fences around r denoting the barriers to theaccess imposed by the knowledge of the keys used for r’sencryption at the BEL (inner fence, φb(r)) and at the SEL
(outer fence, φs(r)). The fence is continuous if there is noknowledge of the corresponding key (the barrier cannot bepassed) and it is discontinuous otherwise (the barrier can bepassed).
Figure 7 illustrates the different views that can exist onthe resource. On the left, Figure 7(a), there is the view ofthe SEL server itself, which knows the key at the SEL levelbut does not have access to the key at the BEL level. Onthe right, there are the different possible views of users, forwhom the resource can be:
• open: the user knows the key at the BEL level as wellas the key at the SEL level (Figure 7(b));
• locked: the user knows neither the key at the BEL levelnor the key at the SEL level (Figure 7(c));
• sel locked: the user knows only the key at the BEL
level but does not know the key at the SEL level (Fig-ure 7(d));
• bel locked: the user knows only the key at the SEL
level but does not know the one at the BEL level (Fig-ure 7(e)). Note that this latter view corresponds tothe view of the server itself.
131
r
BEL
SEL
r
BEL
SEL r
BEL
SEL
open
locked
sel_locked
Figure 8: View transitions in the Full SEL
By the correctness of the approach (Theorem 4.1), theopen view corresponds to the view of authorized users, whilethe remaining views correspond to the views of non autho-rized users.
Before analyzing exposure, we illustrate how the differ-ent views on a resource can be produced by authorizationchanges (and consequent over-encryption).
5.1 View evolutionIn the Full SEL approach, at initialization time, BEL and
SEL are completely synchronized. Then, for each user, aresource is protected by both keys or by neither: authorizedusers will have the open view, while non authorized userswill have the locked view. Figure 8 summarizes the possibleview transitions starting from these two views.
Let us first examine the evolution of the open view. Sinceresources at the BEL level are not re-encrypted, the view ofan authorized user can change only if the user is revoked theauthorization. In this case, the resource is over-encryptedat the SEL level, then becoming sel locked for the user. Theview could be brought back to be open if the user is grantedthe authorization again (i.e., over-encryption is removed).
Let us now examine the evolution of the locked view.First, we note that - for how the SEL is constructed andmaintained in the Full SEL approach - it cannot happenthat the SEL grants a user an access that is blocked at theBEL level, and therefore the bel locked view can never bereached. The view can instead change to open, in case theuser is granted the authorization to access the resource; orto sel locked, in case the user is given the access key at theBEL level but she is not given that at the SEL level. Thislatter situation can happen if the release of the key at theBEL level is necessary to make accessible to the user an-other resource r′ that is, at the BEL level, encrypted withthe same key as r. To illustrate, suppose that at initializa-tion time resources r and r′ are both encrypted with thesame key and they are not accessible by user u (whose viewon the resources is locked). The leftmost view in Figure 9illustrates this situation. Suppose then that u is grantedthe authorization for r′. To make r′ accessible at the BEL
level, a token is added to make φb(r) derivable by u, wherehowever φb(r)=φb(r
′). Hence, r′ will be over-encrypted atthe SEL level and φs(r
′) made derivable by u. The resultingsituation is illustrated in Figure 9, where r′ is open and rresults sel locked.
5.2 Exposure riskCollusion can take place every time two entities, com-
bining their knowledge (i.e., the keys known to them) canacquire knowledge that neither of them has access to. There-
BEL
SEL
BEL
SEL
locked sel_locked
r r ’ r ’ r
open
grant ( r ’ , u )
Figure 9: From locked to sel locked views
Past_acl Bel_accessible All users acl(r)
Figure 10: Classification of users for a resource r
fore, users having the open view need not be considered asthey have nothing to gain in colluding (they already accessr). By the same line of reasoning, also users having thelocked view need not be considered as they have nothing tooffer (and therefore no one will have to gain in colluding withthem). Also, recall that in the Full SEL approach, for whatsaid in the previous subsection, nobody (but the server) canhave a bel locked view. This leaves us only with users hav-ing the sel locked view. Since users having the same viewswill not gain anything in colluding, the only possible collu-sion can happen between the server (who has a bel locked
view) and a user who has a sel locked view. In this situa-tion, the knowledge of the server allows lowering the outerfence, while the knowledge of the user allows lowering theinner fence: merging their knowledge, they would then beable to bring down both fences and enjoy the open view onthe resource.
We know, from the possible transitions between views,that there are two reasons for which a user can have thesel locked view on a resource.
• Past acl : the user was previously authorized to accessthe resource and the authorization was then revokedfrom her (transition from open to sel locked in Fig-ure 8). By colluding with the server, in this case theuser would get access to a resource she previously hadauthorization for. Since we assume users to be nonoblivious, the user - while not currently having abilityto access the resource - can have it cached at her sidealready. Then she has no gain in colluding with theserver. It is therefore legitimate to consider this caseineffective with respect to collusion risks. 5
• Policy split: the user has been granted the authoriza-tion for another resource that was, at the initializa-tion time, encrypted with the same key as r, leaving rsel locked. In this situation (from locked to sel locked),the user has never had access to r and should still nothave it; therefore there is indeed exposure to collusion.
In other words, the risk of collusion arises on resourcesfor which a user holds a sel locked view and the user neverhad the authorization to access the resource (i.e., the usernever belonged to the acl of the resource). This observationprovides a way to measure the collusion risk to which a re-source is exposed. Figure 10 provides a graphical illustrationof the set of users and their possible relationship with the
5We assume, without loss of generality, that any time aresource is updated, the data owner encrypts it with theright BEL key.
132
r
BEL
SEL
r
BEL
SEL r
BEL
SEL
open
bel_locked
sel_locked
Figure 11: View transitions in the Delta SEL
resource. The outermost set represents all the users. Fora subset of them, denoted as Bel accessible, the resourcemight be not protected at the BEL level (there is no fenceas they know φb(r)). Among them, there are the users, de-noted as Past acl , who had in the past the authorization toaccess r, some of whom (those in acl(r)) may still hold theauthorization. The users representing a collusion risk forthe resource are all those that belong to Bel accessible anddo not belong to Past acl .
Besides collusion between different parties, we also need toconsider the risk of exposure due to a single user (or server)merging her own views on a resource at different points intime. It is easy to see that, in the Full SEL approach, whereall non authorized users start with a locked view on theresource (and transitions are as illustrated in Figure 8), thereis no risk of exposure. Trivially, if the user is released thekey at the SEL level (i.e., it is possible for her to bring downthe lower fence) it is because the user has the authorizationfor r at some point in time and therefore she is (or has been)authorized for the resource. There is therefore no exposurerisk.
As for the Delta SEL approach, we start by noting thatusers not authorized to see a resource have, at initial time,the bel locked view on it. From there, the view can evolveto be sel locked or open (in case the user is given the autho-rization for the resource). View transitions are illustrated inFigure 11. It is easy to see that, in this case, a single user byherself can then hold the two different views: sel locked andbel locked. In other words a (planning-ahead) user couldretrieve the resource at initial time, when she is not autho-rized, getting and storing at her side r’s bel locked view. If,at a later point in time the user is released φ(r) to makeaccessible to her another resource r′, she will acquire thesel locked view on r. Merging this with the past bel locked
view, she can enjoy the open view on r. Note that the setof resources potentially exposed to a user coincides with theresources exposed to collusion between that user and theserver in the Full SEL approach.
It is important to note that in both cases (Full SEL andDelta SEL), exposure is limited to resources that have beeninvolved in a policy split to make other resources, encryptedwith the same BEL key, available to the user. Exposure istherefore limited and well identifiable. This allows the ownerto possibly counteract it via explicit selective re-encryptionor by proper design (as discussed in the next section).
The collusion analysis clarifies why we did not consider thethird possible encryption scenario illustrated in Section 3. Inthis scenario, all users non authorized to access a resourcewould always have the sel locked view on it and could po-tentially collude with the server. The fact that the BEL key
is the same for all resources would make all the resourcesexposed (as the server would need just one key to be ableto access them all).
5.3 Design considerationsFrom the analysis above, we can make the following ob-
servations on the Delta SEL and the Full SEL approaches.
• Exposure protection. The Full SEL approach providessuperior protection, as it reduces the risk of exposure,which is limited to collusion with the server. By con-trast, the Delta SEL approach exposes also to single(planning-ahead) users.
• Performance. The Delta SEL approach provides supe-rior performance, as it imposes over-encryption onlywhen required by a change in authorizations. By con-trast, the Full SEL approach always imposes a doubleencryption on the resources, and therefore an addi-tional load.
From these observations we can draw some criteria thatcould be followed by a data owner when choosing betweenthe use of Delta SEL or Full SEL. If the data owner knowsthat:
• the access policy will be relatively static, or
• sets of resources sharing the same acl at initializationtime represent a strong semantic relationship rarelysplit by policy evolution, or
• resources are grouped in the BEL in fine granularitycomponents where most of the BEL nodes are associ-ated with a single or few resources,
then the risk of exposing the data to collusion is limited alsoin the Delta SEL approach, which can then be preferred forperformance reasons.
By contrast, if authorizations have a more dynamic andchaotic behavior, the Full SEL approach can be preferred tolimit exposure due to collusion (necessarily involving theserver). Also, the collusion risk can be minimized by aproper organization of the resources to reduce the possibilityof policy splits. This could be done either by producing afiner granularity of encryption and/or better identifying re-source groups characterized by a persistent semantic affinity(in both cases, using in the BEL different keys for resourceswith identical acl).
6. RELATED WORKPrevious work close to our is in the area of “database-as-
a-service” paradigm [10, 11], which considers the problemof database outsourcing. Its intended purpose is to enabledata owners to outsource distribution of data on the Inter-net to service providers. The majority of existing effortson this topic focuses on techniques allowing the executionof queries on encrypted outsourced data, trying to supportall SQL clauses and different kinds of conditions over at-tributes [2, 7, 10, 11]. In general, these approaches are basedon indexing information stored together with the encrypteddata. Such indexes are used to select the data to be returnedin response to a query, without need of decrypting the data.One of the major challenges in the development of index-ing techniques is the trade off between query efficiency and
133
exposure to inference and linking attacks that strongly de-pends on the attacker’s prior knowledge [7]. A related effortin [14] focuses on the design of mechanisms for protectingthe integrity and authenticity of data from both maliciousoutsider attacks and the service provider itself.Other proposals have investigated the use of partitioning,adopting a distributed architecture to allow an organizationto outsource its data management to two untrusted serverswhile preserving data privacy [1].In addition to the application-based approaches above-mentioned, hardware-based approaches to the problem ofsecure outsourced storage have also been investigated [6].Here, the basic idea is to use a special security hardwarecomponent, which can support secure computations at bothclient and server sides.
A few research efforts have directly tackled the issues ofaccess control in an outsourced scenario. In [13] the au-thors present a framework for enforcing access control onpublished XML documents by using different cryptographickeys over different portions of the XML tree and by intro-ducing special metadata nodes in the structure. Our work iscomplementary to this proposal, as it looks at the differentproblem of enforcing policy changes.
On a different line of related work, other approaches haveinvestigated the hierarchical-based access control in the con-text of distributed environments and pay-tv [5, 17]. Whilesome commonalities can be identified (e.g., the use of cryp-tographic key-based hierarchical schemes), the outsourceddata scenario presents peculiar characteristics that requirethe development of new solutions.
7. CONCLUSIONSThere is an emerging trend towards scenarios where re-
source management is outsourced to an external service pro-viding storage capabilities and high-bandwidth distributionchannels. In this context, selective release requires enforc-ing measures to protect the resource confidentiality fromboth unauthorized users as well as “honest-but-curious”servers. Current solutions provide protection by exploitingencryption in conjunction with proper indexing capabilities,but suffer from limitations requiring the involvement of theowner every time selective access is to be enforced or theaccess policy is modified. In this paper we have put for-ward the idea of enforcing the authorization policy by usinga two-layer selective encryption. Our solution offers signifi-cant benefits in terms of quicker and less costly realizationof authorization policy updates and general efficiency of thesystem (replication of resources can carry along the policyitself). We believe these benefits to be crucial for the successof emerging scenarios characterized by a huge number of re-sources of considerable size and that have to be distributedin a selective way to a variety of users.
8. ACKNOWLEDGMENTSThis work was supported in part by the European Union
under contract IST-2002-507591, and by the Italian Min-istry of Research, within programs FIRB, under project“RBNE05FKZ2”, and PRIN 2006, under project “Basi didati crittografate” (2006099978). The work of Sushil Jajodiawas partially supported by the National Science Foundationunder grants CT-0627493, IIS-0242237, and IIS-0430402.
9. REFERENCES[1] G. Aggarwal et al. Two can keep a secret: a
distributed architecture for secure database services.In Proc. of CIDR 2005, Asilomar, CA, Jan. 2005.
[2] R. Agrawal, J. Kierman, R. Srikant, and Y. Xu. Orderpreserving encryption for numeric data. In Proc. ofACM SIGMOD 2004, Paris, France, June 2004.
[3] S. Akl and P. Taylor. Cryptographic solution to aproblem of access control in a hierarchy. ACM TOCS,1(3):239–248, August 1983.
[4] M. Atallah, K. Frikken, and M. Blanton. Dynamic andefficient key management for access hierarchies. InProc. of the 12th ACM CCS05, Alexandria, VA, USA,Nov. 2005.
[5] J. Birget, X. Zou, G. Noubir, and B. Ramamurthy.Hierarchy-based access control in distributedenvironments. In Proc. of IEEE InternationalConference on Communications, Finland, June 2002.
[6] L. Bouganim and P. Pucheral. Chip-secured dataaccess: confidential data on untrusted servers. In Proc.of the 28th VLDB Conference, Hong Kong, China,August 2002.
[7] A. Ceselli, E. Damiani, S. D. C. di Vimercati,S. Jajodia, S. Paraboschi, and P. Samarati. Modelingand assessing inference exposure in encrypteddatabases. ACM TISSEC, 8(1):119–152, Feb. 2005.
[8] J. Crampton, K. Martin, and P. Wild. On keyassignment for hierarchical access control. In Proc. ofthe 19th IEEE CSFW’06, Venice, Italy, July 2006.
[9] E. Damiani et al. An experimental evaluation ofmulti-key strategies for data outsourcing. In Proc. ofthe 22nd IFIP TC-11 International InformationSecurity Conference, South Africa, May 2007.
[10] H. Hacigumus, B. Iyer, and S. Mehrotra. Providingdatabase as a service. In Proc. of 18th ICDE, SanJose, CA, USA, Feb. 2002.
[11] H. Hacigumus, B. Iyer, S. Mehrotra, and C. Li.Executing SQL over encrypted data in thedatabase-service-provider model. In Proc. of the ACMSIGMOD 2002, Madison, Wisconsin, USA, June 2002.
[12] S. Jajodia, P. Samarati, M. Sapino, andV. Subrahmanian. Flexible support for multiple accesscontrol policies. ACM TODS, 26(2):214–260, June2001.
[13] G. Miklau and D. Suciu. Controlling access topublished data using cryptography. In Proc. of the29th VLDB conference, Berlin, Germany, Sept. 2003.
[14] E. Mykletun, M. Narasimha, and G. Tsudik.Authentication and integrity in outsourced database.In Proc. of the 11th NDSS04, San Diego, CA, USA,Feb. 2004.
[15] R. Sandhu. On some cryptographic solutions foraccess control in a tree hierarchy. In Proc. of theFJCC’87, Dallas, TX, USA, Oct. 1987.
[16] B. Schneier, J. Kelsey, D. Whiting, D. Wagner,C. Hall, and N. Ferguson. On the twofish key schedule.In Selected Areas in Cryptography, June 1998.
[17] Y. Sun and K. Liu. Scalable hierarchical access controlin secure group communications. In Proc. of the IEEEInfocom, Hong Kong, China, March 2004.
[18] XML Encryption Syntax and Processing, W3C Rec.http://www.w3.org/TR/xmlenc-core/, Dec. 2002.
134