Using Multi-Encryption to Provide Secure and Controlled Access to XML Documents

Using Multi-Encryption to Provide Secure and Controlled Access to

XML DocumentsTomasz Müldner, Jodrey School of Computer Science,

Acadia University, Wolfville, NS, CanadaGregory Leighton, Department of Computer Science,

University of Calgary, Calgary, CanadaKrzysztof Miziołek, Centre for Studies on the Classical Tradition

in Poland and East-Central Europe, Warsaw University, Warsaw, Poland

The Extreme Markup Languages Conference, Montreal, August 7-11, 2006

The Extreme Markup Languages Conference, Montreal, August 10, 2006 2

GOAL • Share XML documents within decentralized and distributed computing environments.

• We need mechanisms to facilitate controlled and secure access to these documents.


TERMINOLOGYAccess Control:•Different users have different access rights•Access right are defined using permission policies•Permission policies may be

Static Dynamic

•Permission policies may define accessors, usingRoles, such as auditorCredentials, such as defined by an XPath


GOAL • Share XML documents within decentralized and distributed computing environments. We need mechanisms to facilitate controlled and secure access to these documents.

• the ability to make selective (parts of) documents available to users in multiple, possibly overlapping roles


INTRODUCTIONI will make my parts of the document available

to some users

Multiple users access the same document


INTRODUCTION

Multiple viewsSelect nodes which can

be accessed –use them to create an XML

document (a view)

Problems:

• A view may be invalid.

•overhead


INTRODUCTION

Publish a single view


SUMMARY We consider: XML documents accessed by multiple users in P2P

environments using static permission policies using role-based policies

permissions are represented by meta-information which is visible only to authorized users

We describe permission policies implemented using cryptographic tools: a key encryption function, which generates internal keys

needed to provide controlled access use of multi-encryption to provide access specified by the

permission policy


TERMINOLOGY• Super-encryption

• Multiple-encryption• Partial encryption

Encrypted with more than one key

Various elements are encrypted with different keys


TABLE OF CONTENTS

Security Overview of controlled access Detailed description of access to parts of documents

Permission policy Key encryption function Encrypting largest parts Step 1: Encryption Step 2: Meta-information Multi-encrypted document Access Future work


SECURITY: ISSUES

Confidentiality Integrity Authentication


CONFIDENTIALITY

Plain text Cyphertext


SYMMETRIC ENCRYPTION

DocumentDocumentDocumentDocumentDocumentDocument

Encrypted

Document

EncryptedEncrypted

DocumentDocument

Encrypted

Document

EncryptedEncrypted

DocumentDocument Encrypted

Document

EncryptedEncrypted

DocumentDocument

Encrypted

Document

EncryptedEncrypted

DocumentDocument



ASYMMETRIC ENCRYPTION

Public key Private key


ASYMMETRIC ENCRYPTIONDocumentDocumentDocumentDocumentDocumentDocument

Encrypted

Document

EncryptedEncrypted

DocumentDocument

Encrypted

Document

EncryptedEncrypted

DocumentDocument Encrypted

Document

EncryptedEncrypted

DocumentDocument

Encrypted

Document

EncryptedEncrypted

DocumentDocument



INTEGRITY

Your new salary will be $5,000

Your new salary will be $1,000


CRYPTOGRAPHIC HASH

THIS IS MY TEXT

Encrypted DIGEST

hash


DIGITAL SIGNATURE

THIS IS MY TEXT

SIGNED TEXT:

THIS IS MY TEXT

DIGEST


CERTIFICATE

NameIssuerPublic KeySignature

NameIssuerPublic KeySignature


TABLE OF CONTENTS




CONTROLLING ACCESS: BASIC CONCEPTS Roles identify subjects.

Fixed set of roles Ψ = {R1, R2, ..., Rt}

Views are parts of the document Permission policy associates roles with the specific

type of permissions (read/write access) for one or more views

Creator of the document defines a permission policy that specifies the access for selected roles


CONTROLLING ACCESS: USE OF KEYS

(Asymmetric) Key κ is a pair (public part, private part) For each role R, there is an external key κR associated

with this role Users who enter the system are assigned one or more

roles The private part of the external key κR is available only

to users who are currently in role R.This key will give access to internal keys.


TABLE OF CONTENTS




CONTROLLING ACCESS: VIEWS Definition 1. For an XML document D, a view VD = (D, e), where e is an extended

Xpath for D.

Here, an extended Xpath is of the form: p ¬ pwhere p is a correct Xpath expression.

Intuition: A view represents a tree fragment for which we define an access.

Student

Instructor


VIEWS To define permissions for the document D, we define (in any order):

a number of views (let V be the union of all these views) a special view: Vread / write

Let V0 = D-(VVread / write)

be the of all elements which have not been defined in the above procedure. These elements will be hidden, i.e. encrypted and inaccessible to any user


VIEWS and ROLESThe next step in defining permissions involve associating roles and views.Definition 2a.

Given an XML document D, a role RjΨ, VDi - views of D for i = 1,...,k

A single permission is:

pj = [Rj,

read, VDi1,VD

i2,...,VD

im,

write, VDh1

,VDh2

,...,VDhn

]

(m,n≤k). Here, a write permission does not automatically give a read permission

Conventions; e.g. skip the write part if there are no views in this part.


PERMISSION POLICY Definition 2b.

Given an XML document D, VDi - views of D for i = 1,...,k

a permission policy Π(D) = {p1,p2,...,pt , Vread / write }

Protection requirement: the user in role R can access precisely the set of nodes defined by the

union of all views associated with R (by the permission for R) as well as nodes from the set Vread / write


MULTI-VIEW DOCUMENT Definition 3. Given an XML document D a permission policy Π(D)

a multi-view document

DΠ = [D, VD0,VD

1,...,VD

k],

where VD

1,...,VD

k are all the views in Π(D)

VD

0 contains all nodes which don’t belong to any view

VD

i, i = 1,2,...,k


Example Example. Roles: Auditor (access to employees in Marketing)Checker (access to H-R and Marketing, level < 9)Permission policy Π(D) [Auditor, read, /organization/department[@name="Marketing"]/*] [Checker, read, /organization/department[@name="Marketing"]/employee[@level<9]|/organization/department[@name="H-R"]/*]


TABLE OF CONTENTS




Various parts of the document will be encrypted with different internal keys. However, these keys can not be assigned per-view:

ASSIGNING KEYS

V1

V2

d1

d2

d3

D

κ1

κ2


Key Assignment assigns keys to nodes in a document, based on how the set of nodes is partitioned by views.

Let’s now fix an XML document D, a permission policy Π(D), and the corresponding multi-view document DΠ = [D, VD

0,VD

1,...,VD

k], and consider a set of keys Κ.

KEY ASSIGNMENT

The protection requirement for the view VD

i is satisfied iff

Availableξ(Neededξ(VD

i))= VD

i.

The key assignment function ξ:D->K will be used as follows:

• the node sD will be encrypted with (s)

• to encrypt nodes in VDi we will need the set of keys Neededξ(VD

i)= VDi)

• the set of nodes in D that can be decrypted with keys from the set of keys K0 is defined as Availableξ(K0) = (K0)


Availableξ(Neededξ(VD

i))= VD

i.

True for any one-to-one function ξ:D->K, however such functions may unnecessarily assign too many keys. “Weaker” functions may be sufficient:

KEY ASSIGNMENT

Neededξ(V1) = {κ1}, Availableξ({κ1}) = V1

Needed ξ(V2) = {κ1,κ2}, Available ξ ({κ1,κ2}) = V2

κ1

κ2

V1

V2

d1

d2

d3

D

ξ

K


We define a characteristic vector χ:D{0,1}n where n is the total number of views, as follows:

χ(s) = {[c1,c2,...cn]: for i=1,2,…,n, ci = 1 if sVDi and 0 otherwise}

KEY ASSIGNMENT

1 11 1

1 11 1

0 1 0 1

χ

V1

V2

d1

d2

d3

D


Definition 4. A key assignment ξ:D->K is said to be correct if it satisfies the following condition:

ξ(s) = ξ(t) iff χ(s) = χ(t) for any two elements s,tD(weaker than one-to-one)

KEY ASSIGNMENT

χ

The above key assignment is correct.

1 11 1

1 11 1

0 1 0 1

d1

d2

d3

DK

ξ

κ1

κ2

Note: The set of all elements that belong to a single view is assigned the same key


Lemma 1.If the key assignment ξ is correct then the

protection requirement is satisfied, i.e. Availableξ(Neededξ(VD

i)) = VD

i, for i = 1,2,...,n.

KEY ASSIGNMENT


Key Assignment Algorithm 1.Input: DΠ = [D, VD

0,VD

1,...,VD

k],

Output: correct key assignment ξ:DK.

KEY ASSIGNMENT

χ

1 11 1

1 11 1

0 1 0 1

d1

d2

d3

DK

ξ

κ1

κ2


Theorem 1. The key assignment algorithm produces a correct key assignment,

its time complexity is O(m), where m is the number of elements in D, and it produces the minimum number of keys. ▄

KEY ASSIGNMENT


TABLE OF CONTENTS




SUBTREES IDENTIFICATION

Fixed XML document D, and permission policy Π(D). A subtree rooted at dD is called complete if it consists of

all descendents of d and is of height at least two.Subtrees Identification Algorithm 2.Input: multi-view XML document DΠ = [D, VD

0,VD

1,...,VD

k],

Output: set ΘD = {largest complete subtrees θ(d), dD, which are rooted at d, and whose nodes have all the same characteristic vector; i.e. belong to the same set of views in DΠ}.


TABLE OF CONTENTS


Permission policy Key encryption function Encrypting largest parts Creating a multi-encrypted document. Step 1: Encryption Step 2: Meta-information Access Future work


MULTI-ENCRYPTION:INTRODUCTION

The creator (owner) of the document D wants to define for various users access permissions to this document through the permission policy Π.

Based on specifications in Π, the system will create the multi-encrypted document EncΠ(D).

The document EncΠ(D) will be made available to other users, who will access the allowed parts of D for a role R as long as they are in this role.


MULTI-ENCRYPTION: INTRODUCTION

There are two steps:1. Generate internal keys and use them to encrypt

largest subtrees2. Add meta-information that specifies user’s

permissions


STEP 1: ENCRYPTION Consider a multi-view document based on the permission policy ΠDΠ = [D, VD

0,VD

1,...,VD

k],

Let ξ be the key mapping generated by the Algorithm 1 and ΘD be the set of trees generated by the Algorithm 2.

Elements dVread/write are not encrypted; the remaining elements are encrypted using the private part of the internal key ξ(d): for dD which are roots of trees from ΘD, encrypt the entire tree θ(d)

using the W3C XML encryption standard for remaining dD, use a single-element encryption

The structure of the encrypted document is partly visible.


STEP 1: EXAMPLE SUBTREES IDENTIFICATION

Fixed XML document D, and permission policy Π(D). A subtree rooted at dD is called complete if it consists of

all descendents of d and is of height at least two.Subtrees Identification Algorithm 2.Input: multi-view XML document DΠ = [D, VD

0,VD

1,...,VD

k],

Output: set ΘD = {largest complete subtrees θ(d), dD, which are rooted at d, and whose nodes have all the same characteristic vector; i.e. belong to the same set of views in DΠ}.

Encrypted Enc.

Encrypted

Enc.


TABLE OF CONTENTS




STEP 2: ADDING META INFORMATION

To the encrypted document from Step 1, we add additional meta-nodes. For each role, one meta-node is added to as child of the root

D

ACLD

signed using the creator’s private part of the key κC


META INFORMATION A meta-node contains a <role> element, which defines read or write permission

for one or more nodes, corresponding to the views associated with this role.

<role name="R"> <permission name="read"> <node xpath="..." key="..."/> </permission> …</role> This design supports pseudo-anonymity requirement:

meta-information specifying what parts of the document are available in role R is visible only to the user in role R

Encrypted with the public part of the external key associated with the corresponding role


TABLE OF CONTENTS




MULTI-ENCRYPTION Definition 7. Consider an XML document D and a

permission policy Π(D).

Multi-encrypted document

EncΠ(D) = [Encrypted(D), CertD]

certificate CertD (signed by the certificate authority) contains the identification of the owner, the digital signature of the ACLD, and the public part of the creator’s key κC


TABLE OF CONTENTS


Permission policy Key encryption function Encrypting largest parts Step 1: Encryption Step 2: Meta-information Multi-encrypted document Access and Extensions Future work


ACCESS Consider a multi-encrypted document EncΠ(D).Assume that Q is currently in role R (it has the key κR.) Q determines its permissions on D as follows:

Q retrieves the certificate CertD and uses it to determine the owner P of D (Q may verify this certificate by accessing the certificate authority). Once this certificate is verified, Q can trust that the public key κP stored in this certificate belongs to P.

Q accesses D’s ACL (it can verify the ACL’s signature using P’s public key), specifically it accesses the element with the role R; if such an element does not exist then Q does not have any permissions for D.

Q tries to decrypt the role element for R with the private part of κR. If Q fails, the ACL has been tampered with; if it is successful, then the nested permission element specifies Q’s permissions on parts of D.


EXTENSIONS a partial acyclic order in the set of roles:

role R1 is stronger than role R2 if all permissions associated with R2 are also available in R1.

dynamic roles:the creator of a document may specify a new role R, and use it to define the permission policy.

If a peer Q should be able to access parts of the document, then Q will have to be provided with the private key of the external key pair associated with R a priori via a secure channel.


TABLE OF CONTENTS


Permission policy Key encryption function Encrypting largest parts Step 1: Encryption Step 2: Meta-information Multi-encrypted document Access

Future work


FUTURE WORK Ensuring data integrity of a document (i.e. to detect when its

contents have been tempered with). This problem may be attacked using Merkle hash functions

Our approach assumes that the protection policy is known at encryption time, and we intend to investigate strategies for allowing subsequent changes to the protection policy after the document has been initially published

We consider only read/write operations, more work is required for updates