xflat: query-friendly encrypted xml view publishing

Available online at www.sciencedirect.com

Information Sciences 178 (2008) 774–787

www.elsevier.com/locate/ins

XFlat: Query-friendly encrypted XML view publishing

Jun Gao *, Tengjiao Wang, Dongqing Yang

Department of Computer Science, Peking University of P.R. China, 5 Yihe street, Beijing 100871, PR China

Received 16 October 2006; received in revised form 22 September 2007; accepted 24 September 2007

Abstract

The security of published XML data receives exceptional attention due to its sensitive nature in many applications. Thispaper proposes an XML view publishing method called XFlat. Compared with other methods, XFlat focuses on queryperformance over the published XML view while simultaneously protecting the sensitive data via encryption techniques.XFlat decomposes an XML tree into a set of sub-trees, in each of which multiple users have the same accessibility to allnodes, and may encrypt and store each sub-tree in a flat, sequential manner. This storage strategy can avoid the nestedencryption cost in view construction and the nested decryption cost in query evaluation. In addition, we discuss how togenerate a user-specific schema and how to minimize the total space cost of the published XML view when consideringthe overhead of the relationships among the sub-trees. We also propose an XML schema index to enhance query perfor-mance over the final XML view. The experimental results demonstrate the effectiveness and efficiency of the proposedXFlat method.� 2007 Elsevier Inc. All rights reserved.

Keywords: XML publish; Security; XML query processing

1. Introduction

With XML becoming the standard of information exchange and representation over the Internet, more andmore large corporations and organizations publish their data in XML. This trend also raises a challenge onhow to protect the security of the published XML data, especially when the data is sensitive.

Compared with the XML security research on the server side in Bertino et al. [4] and Cho et al. [18], XMLsecurity research in the publishing area is more challenging because the data will span beyond the owner’s con-trol once published. Cryptographic technology in Aoki [14] and Denning [3] can be used to combine accesscontrol specifications with the published XML view in order to protect the security of the data. In thisway, only when a user has a correct key can he/she access the authorized parts of the XML document assignedby the access control specifications.

0020-0255/$ - see front matter � 2007 Elsevier Inc. All rights reserved.

doi:10.1016/j.ins.2007.09.017

* Corresponding author.E-mail addresses: [email protected] (J. Gao), [email protected] (T. Wang), [email protected] (D. Yang).

mailto:[email protected]



J. Gao et al. / Information Sciences 178 (2008) 774–787 775

In the case that an XML document can be accessed by different users with different privileges, which is atypical case in the real-life publishing scenario, the XML security becomes more complex because of the inter-action among different access rules of the users. The naive method is to generate an accessible XML sub-treeseparate for each user, and then encrypt and publish them together. Such a method does not consider theinteraction among different rules and can generate the final XML view easily. Its main disadvantages, how-ever, are the repetitive use of encryption and the extra space cost when the sub-trees are accessed by differentusers.

Miklau and Suciu consider access specification rules for multiple users as a whole, and the published XMLview is generated in a bottom-up fashion [7]. For example, if the accessibility of sub-tree t1 is different fromthat of its parent node, t1 is encrypted first and replaced by the cipher text. The process repeats itself until theentire tree has been handled. This method has two limitations: First, the XPath evaluation over the publishedXML view needs to decrypt the encrypted sub-trees in a nested way, which incurs high cost in query evalua-tion. Second, instead of providing a user-specific schema, the method can only expose the full documentschema which is proved liable for leaking information in Fan et al. [19].

In order to handle the problems on the published XML view and to overcome the limitations of the existingmethods, we propose a novel method called XFlat which may be used to publish a query-friendly encryptedXML view. In summary, our contributions are as follows:

• In order to generate an encrypted XML view, XFlat decomposes an XML tree into a set of sub-trees ineach of which all nodes are assigned with the same accessibility. XFlat then encrypts and stores them inthe final published XML view in a flat manner. Nested encryption in view construction, as well as nesteddecryption in query evaluation, can be avoided. XFlat also supports a two-phase user-specific schema gen-eration over the final XML view.

• To conduct a query over the encrypted XML view, XFlat exploits the underlying flat structure of the XMLview to support decryption-on-demand query evaluation strategy, and hence to speed up XML query eval-uation over the encrypted XML view. In addition, we propose a schema index to reduce the evaluationcosts, especially when the query contains uncertain operators.

• The security analysis proves that the published XML view by XFlat meets the security requirements. Todemonstrate the superiority of the proposed method, we implement the algorithm and conduct experimentsover various datasets. The experimental results show the effectiveness and efficiency of XFlat in view gen-eration and query evaluation.

A preliminary version of this paper appears in Gao et al. [12], where we present the basic idea of XFlat. Inthis paper, we make the following additional contributions: We propose a two-phase method for generation ofa user-specific schema. The intermediate results in schema generation can be used as the schema index toreduce search space and improve query performance, especially when the query contains uncertain operatorsover the encrypted XML view. Furthermore, we run a more comprehensive set of experiments to demonstratethe effectiveness of XFlat.

The rest of the paper is organized as follows. Section 2 describes preliminary knowledge. Section 3 proposesan XML view construction method. Section 4 discusses how to evaluate queries over an XML view. Section 5presents experimental results. Section 6 reviews the related work. Section 7 concludes the paper and discussesfuture work.

2. Background knowledge

This section reviews background knowledge on encryption, XPath-based access control specifications usedin XFlat and the criteria used to evaluate the security of the published XML view.

2.1. Encryption primitives

Given a plain text string P, a cipher text C, a key K1, for encryption and a key K2 for decryption, an encryp-tion function E can be described as C = E(K1,P), and a decryption function D can be described as

776 J. Gao et al. / Information Sciences 178 (2008) 774–787

P = D(K2,C). E is called a symmetric encryption function if K1 is identical to K2; otherwise E is called anasymmetric encryption function. Generally, the symmetric encryption outperforms the asymmetric encryp-tion. Advanced Encryption Standard (AES) is a public and symmetric cryptographic technology and supportsthe key with sizes varying from 128 bits and 256 bits to 512 bits [14].

2.2. XML security access specification

This paper adopts the basic idea of access control specifications on the elements/attributes by the XPathexpression in Damiani et al. [5]. Access control specifications also support the override and inheritance ofaccessibility. That is, the accessibility of an element node in the XML document tree depends on the explicitassignment or accessibility of the nearest ancestor if not assigned.

Definition 1 (Access control specification). An access control specification is 5-tuple of the form (subject,object, condition, action, sign) where the subject is the user to whom the authorization is granted; the object isan XPath {/, //, *, [ ]} expression, where ‘‘/’’ stands for the parent/child relationship, ‘‘//’’ for the ancestor/descendant relationship, ‘‘*’’ for the wildcard and ‘‘[ ]’’ for the predicate; the condition takes the form of [Q],where Q is also an XPath {/, //, *, [ ]} expression; the action = read/write; and the sign is an indicator of theauthorization which can be either positive (allow access) or negative (forbid access).

2.3. The criteria for the published XML view

We use the following criteria to evaluate the different published XML views. First, the security of the sen-sitive data in the final published XML view is a fundamental requirement. Since the owner loses control of theXML data once the XML view is published, protecting the security in the XML publishing scenario is morecomplex than that in the XML server scenario. Second, due to the different privileges from different users overan XML document, XML publishing should support access by multiple users. Third, the space cost of thepublished XML view and query performance over the published XML views should also be considered.

2.4. Overview of the published XML view

The framework of view generation and query evaluation, which is similar to the framework proposed inMiklau and Suciu [7], is illustrated in Fig. 1. A published XML view with high security is generated froman XML document, the corresponding DTD, and a set of users (each user with several access control speci-fication rules and a key). After the encrypted XML view is published, authorized users need to securely obtaintheir corresponding keys before submitting queries against the XML view.

In contrast to the existing methods, our method focuses on query performance over the published XMLview by reorganizing the internal structure of the view and designing the related query methods. The publishedXML view is composed of three layers: the schema layer containing the specific schema for each user, the

Encryption on the XML view

DTD

XML Document Access Rules

Keys

Query evaluation

SchemaSchema

MetaDataMetaData

Encrypted Data Encrypted Data

Key

Query

DTD

Results

Secure channel

Fig. 1. The framework of XML view generation and query evaluation.


metadata layer containing the relationship among the sub-trees, and the encrypted data layer containing theencrypted data for the sub-trees in the original XML tree. When a user, u, wants to query an XML publishedview, u needs to first submit a key. The system receives the key, and then decrypts and exposes the schemainformation to u. The user then formulates an XPath based on the decomposed schema information. TheXPath is evaluated over the decrypted accessible parts of the XML view.

The problem addressed in this paper can be described as follows: given an XML instance T conforming tothe DTD D and a set of users U = {u1, . . . ,un}, each ui(1 6 i 6 n) is assigned a set of access rules Ai (defined in2.2) and a key ki(1 6 i 6 n). The question is how to generate an encrypted XML view which guarantees thesecurity of the sensitive data, supports the specific schema for each user, and lowers the space cost and queryevaluation cost over the published XML view.

3. XML security view generation

This section presents a method to generate an XML security view. We first use an example to illustrate thebasic process.

Example 1. An insurance company needs to generate a report on its customers and publish the report to awell-known server every month. A fragment of the report DTD and the related XML are illustrated in Fig. 2.The document conforming to the DTD consists of a list of customers (customer *) where each customer

contains child nodes describing information about the name, location and category of the insurance,respectively. The category of insurance contains the information on income, a description of the category and alist of the sub-category of insurance. For example, personal property insurance includes house insurance, carinsurance, etc. Notice that the element of the category is recursively defined in the DTD.

Different groups of users have different privileges concerning accessibility to the nodes in the tree. Forexample, the users in group A can only access customer information when the customer is located in the south

part of the city, while the users in group B are not allowed to access customer information with incomes higherthan $1000. The access control policies can be specified as follows:

• Rule 1: (A, /, , read, positive); /* The users in group A can access the root element node, which also indicatesthat they can access any other node in the XML document tree implicitly if there are no rules explicitlyforbidding that. */

• Rule 2: (A,/report/customer,/locationh i‘‘south’’, read, negative); /* The users in group A cannot access a cus-

tomer element explicitly or its descending nodes implicitly when the customer is not located in the south partof the city. Notice that rule 2 overrides rule 1 on the customer element when the condition of rule 2 is sat-isfied. */

• Rule 3: (B, /, , read, positive); /* The users in group B can access the root element node explicitly and otherelement nodes implicitly. */

Report

Customer

*

Name Location Category

Income Description

*

1 Report

3 Customer

10

Income$900

11

Description

2 Customer

4

NameA

5

Locationsouth

6

12

Income$200

13

Description

7

NameB

8

LocationNorth

9

16 17

Descrip tion

14

Income$900

18 19

15

Income$300

Descrip tion

Category

Category Category

Category Category

Fig. 2. An example of an insurance DTD fragment.


• Rule 4: (B,/report/customer/Category, //income > 1000, read, negative); /* The users in group B are forbid-den from accessing the category element when the income is greater than $1000. */

Miklau and Suciu handle the above rules and the XML data in Fig. 2 in the following manner [7]: The sub-tree t1 rooted with node 3 can only be accessed by the users in group B. The entire tree t2 rooted with node 1can be accessed by the users in group A and group B. The method encrypts t1 with a key known to the users inB and replaces the content of t1 with the encrypted data. t2 can be further encrypted with another key knownto both A and B. Notice that the content of t1 has to be encrypted twice, which indicates t1 may have to bedecrypted twice during query processing.

The basic idea behind XFlat can be described as follows: We decompose the entire XML tree into a set ofsub-trees in each of which all nodes are assigned with the same accessibility. Each decomposed sub-tree will beencrypted one time at most. In order to handle the issues raised by the access of multiple users, XFlat supportsthe merging of sub-trees. Since the extra space is needed to store the relationship between the sub-trees, XFlatprovides a simple yet reasonable cost model to determine whether to merge the sub-trees or not. In addition,we propose a basic decryption-on-demand query processing method and provide its optimization strategiesover the encrypted XML view.

3.1. The local similarity sub-tree and the user-specific schema

3.1.1. The local similarity sub-treeGiven an XML document tree T, and a user u with a set of access control specifications, we can detect the

accessibility of each node n in T denoted as Acc(n,u). If u can access n, Acc(n,u) is set as TRUE, otherwise,Acc(n,u) is set as FALSE. Since the nodes with the same accessibility for a user can be handled similarly, weexploit the region similarity and decompose the XML tree into a set of sub-trees; for each sub-tree, all nodesare assigned with the same accessibility. Formally, the local similarity sub-tree can be defined as:

Definition 2 (Local similarity sub-tree). A local similarity sub-tree T1 = (N1,E1,R1) for a user, u, is a sub-treein an XML document tree T = (N,E), where N denotes a set of nodes; E denotes a set of edges; N1 2 N;E1 2 E; for each node n1 2 N1, Acc(n1,u) = TRUE; and there is no element node n3 such that n3 62 N1, n3 2 N,and n3 is connected with a node in N1 and Acc(n3,u) = Acc(n1,u). Each node n1 2 N1 is assigned with an IDwhich is unique in the entire tree and generated randomly for security purposes. The sub-tree is also assignedwith a randomly generated unique ID. R1 stands for a set of relationships between LSTs in the form of link(nid, tid), where nid is the ID of a node in an LST T1, tid is the ID of an LST T2 which is the nearest under T1,and T1 is called the parent LST of T2. If there is no parent LST for T1 in T, T1 is called the top LST for u in T.The local similarity sub-tree is abbreviated as LST in the following.

Given the XML in Fig. 2 and the access control specifications in Example 1, LSTs for the users in group B

are shown in Fig. 3. Three LSTs are constructed from the original XML tree as a whole. The link relationshipwith other LSTs in LST L1 includes (3,L2), (3, L3).

1 Report

3 Customer

10

Income$900

11

Description

2 Customer

4

NameA

5

Locationsouth

6 Category 7

NameB

8

LocationNorth

16 17

Descrip tion

14 Category

Income$900

18 19

15 Category

Income$300

Descrip tion

(L1) (L2) (L3)

Fig. 3. The LSTs for the users in group B.


The LSTs for a user u can be generated during a pre-order traversal of the entire XML tree in which eachnode, n, in the tree will be visited twice. In the first visit of n, we can determine Acc(n,u) for n based on theaccess specification rules for u. If Acc(n,u) is the same as Acc(p,u), where p is the parent node of n, n and p

belong to the same LST. Otherwise, n is marked as the root of a new LST. In the second visit of n, we removethe entire sub-tree rooted with n as an LST from the original XML tree if n is marked and Acc(n,u) is TRUE.We further handle the rest of the tree iteratively with the above rules.

3.1.2. Virtual accessible tree and user-specific schema

If an end user submits a query, the XML sub-trees in which the query is evaluated can be regarded as thecombination of the LSTs the user can access. With the link relationship stored in each LST, we define:

Definition 3 (Virtual accessible tree). Virtual accessible tree Tu for a user u in an XML tree T is composed ofall LSTs for user u with virtual links and a virtual root LST containing the virtual links to the root nodes of alltop LSTs for u in T when the number of the top LSTs is greater than 1.

The virtual accessible tree for the users in group B is illustrated in Fig. 4. The nodes in the same circlebelong to the same LST. The dotted lines between the trees represent the virtual links among the LSTs.

As pointed out by Fan et al., a user-specific schema will help the user to formulate queries and reduce thepossibility of information leakage. DTD can be used to describe the structural constraints in XML documentswhich can be represented by (Ele,Reg). Ele is a finite set of the element types and Reg is a set of productionrules. Each production rule has the form of n! P(n) to define element type n with a regular expression P(n)which supports the disjunction ‘j’, the concatenation ‘,’ and the Kleene star ‘*’ of the elements [19].

Given a virtual accessible tree for a user u, we can infer the related schema from the data of each LST inSanz et al. [11]. The inferred schema can be used as the user-specific schema. However, this method may gen-erate redundant production rules. In this paper, we exploit the existing full document schema, the currentXML document instance and access specifications to generate a more reasonable schema for the virtual acces-sible tree. In contrast to the existing work in Fan et al. [19], we generate the user-specific schema at the gran-ularity of the LST. That is, we generate the schema for each LST first, and then combine the schema in abottom-up fashion to generate the final user-specific schema.

Given an LST L for a user u and access rules set A, we can reduce the production rule, P(n), for an elementnode type n in the original full document in Papakonstantinou and Vianu [20]. As for each direct child node,m1, with the element type m of a node n1 with the element type n in L, if m1 is not accessible to u from A with-out condition, we replace m with null in P(n). If m1 is not accessible from A conditionally, we replace m withmjnull in P(n), where null is a special symbol representing a null element type. The combination of modifiedproduction rules can be used as the user-specific schema for L.

1 Report

3 Customer

10

Income$900

11

Description

2 Customer

4

NameA

5

Locationsouth

6 7

NameB

8

LocationNorth

16 17

Descrip tion

14

Income$900

18 19

15

Income$300

Descrip tion

Category Category

Category

Fig. 4. The virtual accessible tree.


The user-specific schema for an LST only considers its internal structure. The specific schema for the entirevirtual accessible tree has to be generated from all LSTs in the tree which can be implemented in a bottom-upfashion via combining the user-specific schema between two connected LSTs. Specifically, given two LSTs L1

and L2 with a virtual link between them, the merged user-specific schema for L1 can be generated as follows:for two production rules n! P1(n) and n! P2(n) for the same element type n, the merged production rulescan be defined as n! P1(n)jP2(n). For each virtual link from node p in L1 to the root node r of L2, we regen-erate the production rule for the element type of p since r can be a direct accessible child of p in L1. If we com-bine the user-specific schema in a bottom-up fashion, we can generate the final user-specific schema for theentire virtual accessible tree on the top LST.

Example 2. The user-specified schema for the users in group A and B (in Example 1) can be described inFig. 5. In the left figure, for example, the customer can be null for the users in group A. The validated XMLview contains only one element report if no customer lives in the southern part of the city.

3.2. The merging of LSTs

There are two extreme methods to handle multiple users. First, we can generate LSTs for each user, build avirtual accessible tree for each user, and store the virtual accessible trees into the final XML view. Second, wecan extend LST in Definition 2 with the same accessibility acc(n, (u0, . . . ,uk)) of each node n for multiple users{u0, . . . ,uk} in a sub-tree. As discussed before, the first method may incur the redundant space cost when thesub-trees are accessible for multiple users. The second one also incurs the extra overhead space for the rela-tionship between LSTs since the consideration of multiple accessible rules may lead to many finer LSTs.

Taking Fig. 6 as an example, suppose a user u1 can access a tree T1 and a user u2 can access tree T2, which isa sub-tree of T1; we can get five LSTs for u1 and u2 if we merge T1 and T2; u1 and u2 have the same accessibilityto nodes in each LST. Although the size of the encrypted data does not increase, the merging leads to anincrease of the size of the links between LSTs. In the extreme case, each LST contains only one XML nodeand the extra space cost to store the relationships between the LSTs will overwhelm the cost of redundantaccessible sub-trees saved in the merging process.

In order to balance the cost of redundant XML sub-trees and the cost of the relationships between LSTs,we propose a merging cost model for two LSTs.

Definition 4 (Merging cost model). Given an LST L1 = (N1,E1,R1) for a user u1 and an LST L2 = (N2,E2,R2)for a user u2, the benefit of merging L1 and L2 can be defined as the size of {njn 2 N1 and n 2 N2}, denoted asBenefit(L1,L2). The cost of merging LST can be defined as the size of {njAcc(n, (u1,u2)) 5 Acc(m, (u1,u2)); m is

Report

Customer | null

*

Name Location Categroy

Income Description

*

Report

Customer

*

Name Location Categroy | Null

Income Description

*

Categroy | Null Categroy

Fig. 5. The DTD fragment for the users in group A and group B.

LST T1

LST T2 LST T1

LST T2 Merged treesMerged trees

Fig. 6. The illustration of the sub-tree merging cost.

1 Report

3 Customer

10

Income$900

11

Description

2 Customer

4

NameA

5

Locationsouth

6 Category 7

NameB

8

LocationNorth

16 17

Descrip tion

14 Category

Income$900

18 19

15 Category

Income$300

Descrip tion

Group A and Group B permitted

Group A denied Group B permitted

Fig. 7. The merged LSTs for two users.


the parent node of n, n 2 N1 [ N2, m 2 N1 [ N2}, denoted as Cost(L1,L2). The relative benefit of merging L1

and L2 is Benefit(L1,L2) * S1 � Cost(L1,L2) * S2, where S1 is the size of each node and S2 is the size of eachvirtual link.

Since the nodes in LST L1 and L2 can be stored and encrypted once for the merged LSTs, we can save thespace cost for these nodes in the final XML view; this can be described as the benefit of the merging. However,we need more space to store the relationship between LSTs, which is related to the number of the generatedLSTs (each with a virtual link) in the merging process. Notice that the benefit and cost of the merging areapproximately defined since some technical details are ignored. For example, some blank content needs tobe added into the original content to meet the length requirement of the encryption algorithm. However,the model can still reveal the basic cost and benefit in the merging process.

With the merging cost model, we can determine whether two LSTs can be merged for multiple users or not.The order of the merging of LSTs has a significant impact on the final view. Since it requires a high cost togenerate an optimal merging plan, this paper proposes a greedy method to efficiently generate a locally opti-mal plan. For each LST L1 of a user u1 and each LST L2 of a user u2, we calculate the benefit and cost of themerging operation between L1 and L2, select two LSTs with the maximal relative benefit, merge these twoLSTs together, recalculate the benefit and the cost of two LSTs if needed, and repeat the same process untilno two LSTs have a relative benefit greater than zero. Notice that if two LSTs cannot be merged, the virtuallinks to their child LSTs need not be changed.

The method also supports the merging of LSTs for multiple users in an incremental fashion. Supposeanother user u is authorized to access the XML data, we can generate all LSTs for u, which can be mergedwith the existing LSTs in the final XML view according to the merging cost model as discussed above.

Given the XML in Fig. 2 and the access specifications in Example 1, the merged LST for two users can bedescribed in Fig. 7. With those two LSTs merged, only one extra virtual link space is incurred while the redun-dancy space cost for seven nodes is saved.

If an LST L can be accessed by more than one user, which key can be used to encrypt the content of L? With-out the loss of generalization, if the authorized user A and B are assigned with the key ka and kb, respectively, weadopt the idea of intermediate key to solve the problem in Miklau and Suciu [7]. The system generates a key k

which can be used in the encryption of L. At the same time, k is encrypted as the plain text into ca with ka, andinto cb with kb. ca and cb are called intermediate keys and are distributed within the published XML file. A withka can decrypt ca to obtain k which can decrypt the encrypted LST; B with kb can similarly accomplish this task.

3.3. The whole framework of the view generation

Now we are able to present the overall framework for the generation of an encrypted XML view. The finalpublished XML view is composed of three layers: the schema layer, the metadata layer and the encrypted datalayer. The final schema for the published XML view can be described as in Table 1.

Table 1The schema fragment of the published XML view

PublishedView:– Schemas*, Metadata*, EncryptedData

Schemas:– User, EncryptedSchema*

Metadata:– User, EncryptedLink*, Intermediatekey

EncryptedLink:– FromSubTreeID, FromID, ToSubTreeID

EncryptedData:– SubTree*

SubTree:– TreeID, CipherText


The schema layer enclosed by hEncryptedSchemai contains the specific schema for each user enclosed byhUseri. The user-specific schema can be generated with the method in Section 3.1 and will be protected bythe encryption with the key known to the user.

The metadata layer enclosed by hMetadatai contains the relationship between the encrypted LSTs and theintermediate keys for the LST which can be accessed by the user encoded by hUseri. The relationship betweenthe LST L1 identified by hFromSubTreeIDi and the LST L2 identified by htoSubTreeIDi is established from thenode identified by hFromIDi in L1 to the root node of L2. The relationship is also encrypted for the purpose ofsecurity. The intermediate key for each LST is enclosed by hIntermediatekeyi.

The encrypted data layer enclosed by hEncryptedDatai contains all encrypted LSTs. The encrypted data foran LST are enclosed by hCipherTexti. In order to distinguish between different sub-trees in the metadata layer,we assign each LST with a unique and randomly generated ID enclosed by hTreeIDi tag.

How to generate the encrypted XML view by XFlat is described in Fig. 8. XFlat generates a set of LSTs fordifferent users. The generated LSTs are merged by a greedy method based on the merging cost model. The pro-duction rules are generated for each LST. The user-specific schema for the entire virtual accessible tree is generatedvia the combination of the user-specific production rules for all accessible LSTs in a bottom-up fashion. The linksbetween LSTs are recorded and the intermediate keys for an LST are generated when the LST can be accessed bymore than one authorized user. Finally, the content of each LST is encrypted and stored in the final XML view.

4. Query evaluation over the encrypted XML view

Given an encrypted published XML view, an authorized user can query the XML view with a given key.Different from the existing methods, our query evaluation method needs to consider the underlying structureof the encrypted LSTs.

Traverse the XML tree and generate thespecific production rules in one LST

XML document

DTD

Access rules

Generate user specific schema viacombinations

Production rulesfor all LSTs

Encrypt user schema for each user

User specificschema

Keys

Encrypted schema

Traverse the XML tree andgenerate the LSTs for each user

Merge LSTs and record the linksamong LSTs

Encrypt the relationship

between LSTsEncrypt the LSTs

Generate Intermediate Keys

Encrypted metadata Encrypted data

XML security View published

LSTs for each user

LSTs for all users

Final publishedXML view

Fig. 8. The framework of the XML security view generation by XFlat.


4.1. Basic query processing over the view generated by XFlat

The basic query evaluation method over the view generated by XFlat takes a top-down fashion. The sys-tem accepts an XPath and a key, decrypts the top LST (maybe a virtual LST) and evaluates the XPathwithin the top LST. If the data in another LST L1 are needed in the evaluation process, the system locatesL1 according to the link information in the metadata layer of the XML view, decrypts L1, and evaluates therest of the XPath in L1. Such a process can be continued recursively until the results of the XPath have beengenerated.

This basic method supports the decryption-on-demand strategy. That is, it is not necessary to decrypt allLSTs in query evaluation. Since the decryption cost of XML requires a high portion of the whole evaluationcost, the decryption-on-demand strategy can reduce query evaluation cost.

This basic method works efficiently on the axis {/} and explicit elements in XPath, as only the child LSTssatisfying the explicit element requirement will be handled. However, if the XPath contains uncertain opera-tors, such as the ancestor–descendant relationship {//} or the wildcards {*}, the basic method suffers a seriousperformance problem. We have to decrypt more LSTs than needed in order to guarantee the completeness ofthe results. For example, given an XPath query p = //a, the basic top-down evaluation method has to decryptall accessible LSTs to locate all nodes with the element type a.

4.2. The schema index to quicken query performance

In order to avoid unnecessary decryption costs during evaluation of the XPath with uncertain oper-ators, we design a special kind of index to capture the structure of the virtual accessible tree for auser.

Recall the basic process in the user-specific schema generation for each user. The production rules arefirst generated for each LST, which are then combined. In order to capture the structure of LSTs in thevirtual accessible tree, we extend the production rule to link the element type in the production rule withthe corresponding LST. That is, for each element type m in the production rule n! P(n) in an LST L,we annotate m with the ID of L if the XML node with the type m is in L, or with the ID of anotherLST L1 if the XML node with the type m is the root node of L1 and there is a virtual link from L toL1. The production rule with the ID of LST annotated on the element type is called the extended produc-tion rule.

The ID of LST annotated on the element type makes some differences in the combination of productionrules discussed before. For example, suppose two production rules r1 = n! P(n) in L1 and r2 = n! P(n)in L2. We cannot merge the production rules together, even if the regular expressions in r1 and r2 are the same,since the IDs annotated on n in the two production rules are different. Therefore, combinations of theextended production rules in an LST L for a user u can reveal the structure of elements in the sub-tree rootedwith L. We generate the combination of the extended production rules at the top LST of the entire virtualaccessible XML tree as the schema index for u.

Definition 5 (Schema Index). Schema index Index(u) for a user u is the combination of the extended user-specific production rules R at the top LST of the virtual accessible tree for u.

With the schema index, XPath evaluation can be divided into two-phases: the XPath evaluation over theschema index in the schema layer, and the XPath evaluation over the encrypted LSTs in the encrypted datalayer. After the schema index stored in the schema layer is decrypted, we construct a schema graph G from theextended production rules in the schema index in a similar way to Fernandez and Suciu [15]. The elementtypes, with different element labels or different IDs of LSTs, correspond to different nodes in G. We can eval-uate the XPath in G and obtain a set of IDs of LSTs which may contain the intermediate results of the XPathevaluation. Although the LST which satisfies the XPath query on the schema graph may not contain results,those LSTs which are not validated will not provide results for the query. In this way, the search space of theXPath evaluation can be reduced and the unnecessary decryption cost over the encrypted LST can be furtheravoided, even when the XPath contains uncertain operators.


5. The analysis of XFlat

5.1. Security discussion

Miklau and Suciu previously defined the security property on the encrypted XML view [7]. We discuss thesecurity of the XML view generated by XFlat with the same criteria.

Property 1. Suppose t is an XML document, P is a set of access control specifications for a user u, and t0 is the

generated XML view via XFlat which meets the requirement of P. As for u with the key k,

1. There is an efficient way to reproduce t from t0;

2. u needs to guess the missing key if k is not the correct key.

The first item is easy to prove: We can decrypt the schema of the published XML view with the key, decryptthe corresponding LSTs and the related metadata, and provide the final accessible virtual XML tree accordingto the metadata in the published XML view. Due to the efficiency of the decryption algorithm, we can repro-duce t from t0 efficiently.

The second item indicates that we cannot obtain the original XML data except when we have the correctkey. In the XML view generated by XFlat, the data, metadata and schema information are all protected by theencryption. Similar to the work in Miklau and Suciu [7], it is computationally impossible to reproduce theoriginal data without the correct key.

Since XFlat encrypts and stores sub-trees in a sequential way, some people may argue that it is possible foran attacker to replace or remove an encrypted sub-tree in the XML view. However, the replacement of anyencrypted sub-tree will incur a decryption problem since the key used to encrypt the replaced LST is an inter-mediate key generated by the system. In addition, the removal of any encrypted sub-tree will make it impos-sible to locate the corresponding encrypted sub-tree from the randomly generated ID reference stored in themetadata layer, which also raises an exception. In summary, query evaluation over the XML view generatedby XFlat terminates abnormally upon the replacement or removal of any portion of the sub-tree in the finalXML view.

5.2. Performance study

We generate the XML test data sets by XMark1 with auction DTD by an XML generator with NASADTD2 and generate XPath sets by the XPath generator [2]. We ran the experiments on a Dell Optiplex 260with CPU 2 GHz and 512 MB RAM. The programming language was Java on Windows 2000 with JDK1.31. We performed extensive experiments on the encrypted XML view generation and query evaluation overthe encrypted XML published view.

The XML data set was generated by XMark, with the factor ranging from 0.001 to 0.005. We generate 10,20, 30, 40, and 50 XPaths using XPath generator with d = 0.05, w = 0.05, p = 0.05, where d, w, p denote thepossibility rate of {//, *, [ ]}, respectively. The access control specifications are selected from the generatedXPaths set. Each user is assigned five access control specifications. The condition for each access control spec-ification is set to null and the sign for each specification is randomly set as positive or negative. The encryptionmethod used was AES with a key size of 128 bits. The implementation of AES can be found at bouncycastle.3

We mainly compare XFlat and the method to generate the XML view in a nested way. We focus on thespace cost of the generated XML view and the time cost of the related operations on the generated XML view.Since the results of the NASA data set show the same trend as those of the data generated by XMark, wereport the results of the data generated by XMark in this paper.

1 http://monetdb.cwi.nl/xml/downloads.html.2 http://www.cs.washington.edu/research/xmldatasets.3 http://www.bouncycastle.org/.

http://monetdb.cwi.nl/xml/downloads.html

http://www.cs.washington.edu/research/xmldatasets

http://www.bouncycastle.org/


The results of the time cost in the XML view generation by the nested encryption method (denoted asNested in the following) and XFlat are shown in Fig. 9. Since the length of the encrypted string and the timecost of the initialization of an AES engine are much larger in Nested than those in XFlat, XFlat is superior toNested when the access specification rules or the size of the XML increases. The number of access rules used inthe left figure is 30 and the size of the XML document is 326 K in the right figure.

The results of the space cost of the generated XML views are shown in Fig. 10. As discussed in Miklau andSuciu [7], the size of the generated XML view generated by Nested exceeds that of the original XML docu-ment, because AES automatically fills the original string to a certain size in Miklau and Suciu [7]. Although

10 20 30 40 50 0

20

40

60

80

100

120

140

160

Tim

e (s

)

The Number of Access Rules

100 200 300 400 500 600 0

20

40

60

80

100

120

140

160

180

200

Tim

e (s

)

The Size of XML(k)

XFlat

Nested XFlat

Nested

Fig. 9. The time cost in view construction.

10 20 30 40 500

100

200

300

400

500

600

Siz

e (K

)

The Number of Access Rules100 200 300 400 500 600

0

100

200

300

400

500

600

700

Siz

e (k

)

The Size of XML(k)

XFlat Nested

XFlat Nested

Fig. 10. The space cost in view construction.

100 200 300 400 500 600 012

34567

89

10111213

Tim

e (S

)

The Size of XML(K)

XFlatNoSchemInd XFlatSchemaInd Nested

10 20 30 40 500

1

2

3

4

5

Tim

e (s

)

The Number of the Access Rules

XFlatNoSchemInd XFlatSchemaInd Nested

Fig. 11. The time cost of the XPath evaluation.


XFlat introduces the cost of the relationship between LSTs, the size of the generated XML view by XFlat isnearly the same as or less than that of the XML view generated by Nested. This is because the times of encryp-tion in Nested are more than those in XFlat, which indicates that more blank data need filling in the originalXML content in Nested. The data set is the same as that in Fig. 10. The experiments also show that when thenumber of LSTs is small, for example, when the LSTs are generated from ten access rules, the space cost of theview by Nested is less than that of the view by XFlat due to reduced encryption times.

The results of query evaluation cost over the views generated by XFlat and Nested are shown in Fig. 11. Weobserve that query evaluation of the XML view generated by XFlat with the schema index works more effi-ciently than that of the XML view generated by Nested and the XML view generated by XFlat without theschema index. When considering the schema index for the entire virtual accessible XML tree, less LSTs needto be decrypted during query evaluation than those in other methods. Such trends are similar when the size ofthe XML document or the number of the access rules vary.

6. Related work

Most of XML security research efforts focus on the security techniques on the server side, where any accessto the data should be via the security layer in the data server. For example, access control models for XMLdata are studied in Bertino et al. [4] and Fan et al. [19]. Query evaluation over the security XML document isstudied in Cho et al. [18]. The granularity of access specifications and the interactions among the specificationsare studied in Damiani et al. [5] and Bertino et al. [4].

In particular, Fan et al. propose a method for optimizing query evaluation over the XML security view [19].The user-specific schema is derived from the access control specifications and a query over a security view isrewritten into an equivalent query over the original document. However, work is also performed on the serverside, which indicates the work in Fan et al. [19] faces concerning the different problems from XFlat. For exam-ple, no query rewriting is needed on the view generated by XFlat since the accessible view for a user can bedynamically merged with virtual links.

Access control on the published XML view can be implemented by cryptographic techniques in Miklau andSuciu [7]. The published data are also protected by the encryption method. Access specification rules take theform of the extended XQuery. A protected tree model is proposed and the related optimization methods onthe model are discussed. The main problem is that the tree-structured published data can entail nested encryp-tion, which leads to high costs during query evaluation. In addition, it does not provide the user-specificschema. The information disclosure problem for the published views is studied in Miklau and Suciu [8]. Aninverted index for the published XML view is discussed in Lee and Whang [13], which is also designed toreduce query evaluation cost on the published XML view. However, XFlat handles the problem via reorga-nization of the internal structure of the XML document tree rather than the inverted index technique alone.

Another kind of related work is called DAS (‘‘database as service’’). Users put their sensitive data into anuntrusted server, which implements information storage and possible query evaluation in Hacigms et al. [9].Some work focuses on how to encrypt data while simultaneously improving the query processing performancevia the index techniques in Agrawal et al. [17] and Hore et al. [1]. The different requirements in the DAS anddata publishing scenario lead to different methods.

XPath evaluation with or without DTD is studied in Gottlob et al. [6] and Fernandez and Suciu [15]. XPathevaluation over the XML view generated by XFlat shares some similar ideas with these methods. However,XPath evaluation in this paper runs at the granularity of the LST and the expensive decryption cost is con-sidered in query evaluation. The schema index proposed in XFlat plays a similar role in the existing XMLindex methods. For example, Vist in Wang et al. [10] and PRIX in Rao and Moon [16] can reduce the searchspace and improve query performance. However, the existing XML index techniques need not consider thesecurity of the XML nodes and the structure of LSTs in the view generated by XFlat.

7. Conclusions

In this paper, a method called XFlat is proposed for enforcement of access control specifications over anXML document. XFlat not only guarantees the security of the XML view, but also reduces query evaluation


cost. Experimental results illustrate the effectiveness of XFlat. We will discuss inference detection of the pub-lished XML view in future work.

Acknowledgements

This work is supported by project 2006AA01Z230 under the National High-tech Research and Develop-ment of China, project 60503037 from the National Natural Science Foundation of China (NSFC), and pro-ject 4062018 under the Beijing Natural Science Foundation (BNSF).

References

[1] B. Hore, S. Mehrotra, G. Tsudik, A privacy-preserving index for range queries, in: Proceedings of VLDB, 2004, pp. 720–731.[2] C.Y. Chan, P. Felber, M.N. Garofalakis, R. Rastogi, Efficient filtering of XML document with XPath expressions, in: Proceedings of

ICDE, 2002, pp. 235–244.[3] D.E. Denning, Cryptography and Data Security, Addison-Wesley, 1982.[4] E. Bertino, S. Castano, E. Ferrari, Securing XML documents with author-x, IEEE Internet Comput. 5 (3) (2001) 21–32.[5] E. Damiani, S.D.C. Vimercati, S. Paraboschi, P. Samarati, A fine-grained access control system for XML documents, TISSEC 5 (2)

(2002) 169–222.[6] G. Gottlob, C. Koch, R. Pichler, Efficient algorithms for processing XPath queries, in: Proceedings of VLDB, 2002, pp. 95–106.[7] G. Miklau, D. Suciu, Controlling access to published data using cryptography, in: Proceedings of VLDB, 2003, pp. 898–909.[8] G. Miklau, D. Suciu, A formal analysis of information disclosure in data exchange, in: Proceedings of SIGMOD, 2004, pp. 575–586.[9] H. Hacigms, B.R. Iyer, C. Li, S. Mehrotra, Executing SQL over encrypted data in the database-service-provided model, in:

Proceedings of SIGMOD, 2002, pp. 216–227.[10] H. Wang, S. Park, W. Fan, P.S. Yu, Vist: a dynamic index method for querying XML data by tree structures, in: Proceedings of

SIGMOD, 2003, pp. 110–121.[11] I. Sanz, J.M. Prez, R.B. Llavori, M.J.A. Cabo, XML schemata inference and evolution, in: Proceedings of DEXA, 2003, pp. 109–118.[12] J. Gao, T. Wang, D. Yang, XFlat: query friendly encrypted XML view publishing, in: Proceedings of APWeb, 2006, pp. 97–108.[13] J.G. Lee, K.Y. Whang, Secure query processing against encrypted XML data using query-aware decryption, Inform. Sci. 176 (13)

(2006) 1928–1947.[14] K. Aoki, H. Lipmaa, Fast implementations of AES candidates, in: 3rd AES Candidate Conference, 2000, pp. 106–120.[15] M.F. Fernandez, D. Suciu, Optimizing regular path expressions using graph schemas, in: Proceedings of ICDE, 1998, pp. 14–23.[16] P. Rao, B. Moon, Indexing and querying XML using prufer sequences, in: Proceedings of ICDE, 2004, pp. 288–300.[17] R. Agrawal, J. Kiernan, R. Srikant, Y. Xu, Order preserving encryption for numeric data, in: Proceedings of SIGMOD, 2004, pp.

563–574.[18] S. Cho, S.A. Yahia, L.V.S. Lakshmanan, D. Srivastava, Optimizing the secure evaluation of twig queries, in: Proceedings of VLDB,

2002, pp. 490–501.[19] W. Fan, C.Y. Chan, M.N. Garofalakis, Secure XML querying with security views, in: Proceedings of SIGMOD, 2004, pp. 587–598.[20] Y. Papakonstantinou, V. Vianu, Incremental validation of XML documents, in: Proceedings of ICDT, 2003, pp. 47–63.

xflat: query-friendly encrypted xml view publishing

Documents