Secure and selective authentication and access control of xml documents
This presentation is the property of its rightful owner.
Sponsored Links
1 / 36

Secure and Selective Authentication and Access Control of XML Documents PowerPoint PPT Presentation


  • 37 Views
  • Uploaded on
  • Presentation posted in: General

Secure and Selective Authentication and Access Control of XML Documents. Bhavani Thuraisingham March 29, 2007 Lecture #22. Outline. Motivation for Research on XML Security Technical Details of the Research on XML Security Related work and Future Directions

Download Presentation

Secure and Selective Authentication and Access Control of XML Documents

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Secure and selective authentication and access control of xml documents

Secure and Selective Authentication and Access Control of XML Documents

Bhavani Thuraisingham

March 29, 2007

Lecture #22


Outline

Outline

  • Motivation for Research on XML Security

  • Technical Details of the Research on XML Security

  • Related work and Future Directions

  • Based on paper published in IEEE Transactions on Knowledge and Data Engineering, October 2004 (Bertino, Ferrari, Carminati, Thuraisingham)


Motivation for research on xml security

Motivation for Research on XML Security

  • XML (extensible Markup Language) Security

    • XML has become the standard document interchange language for the web

    • XML is a critical technology for the semantic web

      • RDF and other specifications are built on XML

    • XML documents must satisfy security and privacy policies

    • Challenges: Access Control, Secure publishing, Secure Web Services Applications, Securing RDF, Secure semantic web, Temporal models, Privacy, Handling evolving XML specifications

  • Outline of XML Security Presentation

    • Access Control

      • Example XML document, Policy Specification, Access Control Strategy and Architecture

    • Third Party Publication of XML Documents

      • Architecture

      • Interactions between Owner, Publisher and Subject

      • Checking for Authenticity and Completeness

      • Potential Attacks and Performance Issues

      • Integrating Confidentiality with Authenticity and Completeness

      • Application: Secure Web Services


Example xml document

Year: 2003

Annual report

Name: UTD

Assets

Patents

Other

Equipment

Asset

Asset

Patent

Dept

Patent

Expenses

Books

Author

Cash

CS

ID

Tot

Date

Tech-details

Funds

Dept

Fund

Amout

Date

Short-desc

UTD

Type

6/1/03

1m$

Example XML Document

NSF


Publishing service how it works

Publishing Service

WEB

Users

Publishing service: how it works

  • Anew class of information-centered applications based on Data dissemination

  • Possible scenarios:

    • Information commerce (Digital libraries, Electronic news, etc.)

    • Intra-company information systems

  • Push/Pull modes

  • Security requirements:

    • Confidentiality

    • Integrity

    • Authenticity

    • Completeness


Subject credentials protection objects and policy base

Subject Credentials, Protection Objects and Policy Base

  • Subjects are given access to XML documents or portions of documents depending on user ID and/or Credentials

  • Credential specification is based on credentials a subject has

    • Professor is a credential; Secretary is a credential

  • Protection objects are objects to which access is controlled

    • Entire XML documents or portions of XML documents

  • Policy base stores security policies for protecting the XML source contents


Subject credential base example

Subject Credential Base Example

<Professor credID=“9” subID = “16: CIssuer = “2”>

<name> Alice Brown </name>

<university> UTD <university/>

<department> CS </department>

<research-group> Security </research-group>

</Professor>

<Secretary credID=“12” subID = “4: CIssuer = “2”>

<name> John James </name>

<university> UTD <university/>

<department>CS </department>

<level> Senior </level>

</Secretary>


Policy base example

Policy Base Example

<?xml version="1.0" encoding="UTF-8"?>

<policy_base>

...

<policy_spec ID=‘P1' cred_expr="//Professor[department='CS']" target="annual_report.xml" path="//Patent[@Dept='CS']//node()" priv="VIEW"/>

<policy_spec ID=‘P2'cred_expr="//Professor[department='CS']" target="annual_report.xml" path="//Patent[@Dept='IST']/Short-descr/node() and //Patent[@Dept='IST']/authors" priv="VIEW"/>

<policy_spec ID=‘P3'cred_expr="//Professor[department='IST'] " target="annual_report.xml" path="//Patent[@Dept='IST']//node()" priv="VIEW"/>

<policy_spec ID=‘P4'cred_expr="//Professor[department='IST']" target="annual_report.xml" path="//Patent[@Dept='CS']/Short-descr/node() and //Patent[@Dept='CS']/authors" priv="VIEW"/>

<policy_spec ID=‘P5'cred_expr="//secretary[department='CS' and level='junior']" target="annual_report.xml" path="//Asset[@Dept='CS']/node()" priv="VIEW "/>

<policy_spec ID=‘P6'cred_expr="//secretary[department='CS' and level='senior']" target="annual_report.xml" path="//Asset[@Dept='IST'][email protected] and //Asset[@Dept='IST'][email protected]" priv="VIEW "/>

<policy_spec ID=‘P7'cred_expr="//secretary[department='IST' and level='junior']" target="annual_report.xml" path="//Asset[@Dept='IST']/node()" priv="VIEW "/>

...

</policy_base>


Access control strategy

Access Control Strategy

  • Subjects request access to XML documents under two modes: Browsing and authoring

    • With browsing access subject can read/navigate documents

    • Authoring access is needed to modify, delete, append documents

  • Access control module checks the policy based and applies policy specs

  • Views of the document are created based on credentials and policy specs

  • In case of conflict, least access privilege rule is enforced

  • Works for Push/Pull modes


System architecture for access control

System Architecture for Access Control

User

Pull/Query

Push/result

X-Access

X-Admin

Admin

Tools

Credential

base

Policy

base

XML Documents


Third party architecture

Third-Party Architecture

XML Source

policy base

Credential

base

  • The Owner is the producer of informationIt specifies access control policies

  • The Publisher is responsible for managing (a portion of) the Owner information and answering subject queries

  • Goal: Untrusted Publisher with respect to Authenticity and Completeness checking

SE-XML

Owner

Publisher

Reply

document

credentials

Query

User/Subject


Subject owner interaction

Subject Owner Interaction

  • Subjects register with Owner during subscription phase; during this phase subject is assigned by owner credentials stored at the owner site

  • Owner returns to the subject the Subject Policy Configuration (policy identifiers) that apply to the subject signed with the private key of the owner

  • Example: If polices P1 and P2 apply to John (e.g. CS prof) and policy P6 applies to Jane (IST secretary), owner Joe sends John P1 and P2 and to Jane P6 signed with Joe’s private key


Secure and selective authentication and access control of xml documents

SubjectPolicy Configuration

<?xml version="1.0" encoding="UTF-8" ?>

<SubjectPolicyConfiguration ID=“ProfessorCS" created="08-05-2002">

<owner>

<name>owner1</name>

<organization>CS</organization>

<state>Texas</state>

<uri>www.owner1.com</uri>

<owner>

<policy>VtaUBIxliHS1hzrqkKhYVTtYrafVSmCoJPkUVKYXCA7yVdc7a/ne5sgIg0tGGRe3 /D2Xg6Fbwp3SAKK/Ref1teZCpD0nlkx89GOIIcw8o9R3Mb2YY/slk5+Fu0xxWXlB YuWKWWNsXENKTkgiXL4mB1SUt4bmF6YG4lTxfxduVAw=</policy>

</SubjectPolicyConfiguration>

P1, P2


Owner publisher interaction

Owner Publisher Interaction

  • For each document the owner sends the publisher the following information

    • Information on which subjects can access which portions of the document according to the policy base (I.e. access control policies)

    • Policy element which describes the policies for the document is also inserted

    • Also for each element e based on the policies applied to e, the owner inserts policy configuration (binary string) converted to hexadecimal representation

    • Merkle Signature of each document

  • The document together with the security information is called “Security Enhanced Document” (SE-XML) and will enable the subject to verify the authenticity of the document

  • Additional information encoded in the document called Secure Structure is used by the subject to verify completeness of the result


Policy configuration policy element

Where m is the number of policies applied on document d

Policy Configuration/Policy Element

  • Consider the element e of an XML document d

  • The policy configuration of e consists of a binary string, of m bits where the i-th bit is equal to:

    • 1 if the policies, whose identifier is i, is applied on e

    • 0 otherwise

  • SE-XML document has information about the set of the m policies applied to the document:

    • <Policy> 1, 2, 3, 4, 5, 6, 7 </Policy>

    • For each element, policy information in hexadecimal representation is also inserted


Policy configuration example

Policy Configuration: example

  • Consider the short-descrelement of the CS dept:

    • The only policies applied to it are: 1st and 4th policy (i.e. P1, P4)

    • According to the Policy element, these policies are located in the first and fourth position of the policy configuration

      The policy configuration associated with short-descrelement is 1001000

short-descr’s PC value is 90 (hexadecimal representation)


Publisher policy evaluation example

Publisher Policy evaluation: example

1. Decrypt with the Public key of the Owner the policies applied to the subject (i.e., the Subject Policy Configuration)

P1, P2

2.Match the obtained policy identifiers with the identifiers contained in the Policy element

i.e. match P1, P2 with P1, P2, P3, P4, P5, P6, P7

3.Find the policies applicable to the element specified in the query (e.g., short description element)

P1, P4

4.Find the matching policies from steps 2 and 3

P1

The only policies applied on Short-descr element is “P1”


Secure and selective authentication and access control of xml documents

Security Enhanced XML document

XML Document

  • Policy Information

  • Merkle Signature

SE-XML Document


Secure and selective authentication and access control of xml documents

title

Newspaper

date

Frontpage

Literary_page

Politic_page

Sport_page

Leading

Paragraphs

Politic

Article

news

news

Author

title

paragraph

topic

topic

Author

title

Author

title

topic

topic

Author

title

Author

title

Author

title

paragraph

Author

title

Merkle Signature Example

MhX(Author)=h(h(Author)||h(Author.value))

MhX(title)=h(h(title)||h(title.value))

MhX(paragraph)=h(h(paragraph)||h(paragraph.content)||

MhX(Author)||MhX(title))


Secure and selective authentication and access control of xml documents

title

Newspaper

date

Frontpage

Literary_page

Politic_page

Sport_page

Leading

Paragraphs

Politic

Article

news

news

Author

title

paragraph

topic

topic

Author

title

Author

title

topic

topic

Author

title

Author

title

title

Author

paragraph

Author

title

Merkle Signature

of Newspaper XML file

MhX(Newspaper)

Merkle Signature Example

MhX(Newspaper)=h(h(Newspaper)||h(Newspaper.content)||

MhX ()……||MhX()||…||MhX())


Secure and selective authentication and access control of xml documents

Security Enhanced XML document: Example

<?xml version="1.0" encoding="UTF-8"?>

<Annual Report Year = 2003 Name = CS“CG4g3D8/,mPVV/t+T2O1kZRFhdio=">

<Policy>1,2,3,4,5,6,7 </Policy>

<Assets>

<Asset Dept = “CS">

<Expense Tot="...." PC_ATTR="08"/>

<Funds>

<Fund Funding Date=“6/1/03" Type=“NSF" Amount="..." PC_ATTR="080808"/>

</Funds>

</Asset>

<Asset Dept=“IST">

<Expenses Tot="...." PC_ATTR="02"/>

<Funds>

<Fund Funding Date=“10/1/03" Type=“DoD" Amount="..." PC_ATTR="060602"/>

<Fund Funding Date=“4/1/03" Type=“CIA" Amount="..." PC_ATTR="060602"/>

</Funds>

</Asset>

</Assets>

- - - - - - - - -

/AnnualReport>


Secure and selective authentication and access control of xml documents

Secure Structure Example

<?xml version="1.0" encoding="UTF-8"?>

<x-82592553 x-4639474="rVR5DQ" x-67303774="QTQXS“Sign="OD2mc9aVV/tP4g3TG+1kr4sFhdio=">

<Policy>1,2,3,4,5,6,7 </Policy>

<x-1915689488>

<x-785490824 x-40276037="PlcZUo">

<x-590292021 x-57205665="...." PC_ATTR="08"/>

<x-13947931>

<x-1037159472 x-122584813="fNhtL" x-0260379="hgKID" x-93640287="..." PC_ATTR="080808"/>

</x-13947931>

</x-785490824>

<x-785490824 x-40276037="pKGEs">

<x-590292021 x-57205665="...." PC_ATTR="02"/>

<x-13947931>

<x-1037159472 x-122584813="gPd39" x-0260379="hgKID" x-93640287="..." PC_ATTR="060602"/>

<x-1037159472 x-122584813="o4GpM" x-0260379="yr0QjJ" x-93640287="..." PC_ATTR="060602"/>

</x-13947931>

</x-785490824>

</x-1915689488>

/x-82592553>


Subject publisher interaction

Subject Publisher Interaction

  • The subject submits queries to publisher; it also sends its subject policy configuration

  • Publisher computes a view of the requested documents based on access control policies for the subject set by the owner

  • To verify the authenticity of the answer, subject must recompute the same bottom up hash value signed by owner (i.e. Merkle signature) and compare it with the Merkle signature generated by the owner and inserted by the publisher

  • Subject may not get the entire document; therefore publisher sends to the subject additional hash values that refer to the missing portions of the document

  • Subject verifies the authenticity of the document


Merkle hash paths

v

v

v

1

1

1

2

3

2

3

2

3

w

w

w

4

5

7

4

5

4

5

7

7

6

6

6

8

9

8

8

9

9

10

11

12

13

10

11

12

13

10

11

12

13

14

15

16

17

14

15

16

17

14

15

16

17

MhPath(4,1)

MhPath(7,1)

MhPath(5,1)

Merkle Hash Paths


Secure and selective authentication and access control of xml documents

Completeness Verification

<?xml version="1.0" encoding="UTF-8"?>

<x-82592553 x-4639474="rVR5DQ"

x-67303774="QTQXS“Sign="OD2mc9aVV/tP4g3TG+1kr4sFhdio=">

<Policy>1,2,3,4,5,6,7 </Policy>

<x-1915689488>

<x-785490824 x-40276037="PlcZUo">

<x-590292021 x-57205665="...." PC_ATTR="08"/>

<x-13947931>

<x-1037159472 x-122584813="fNhtL"

x-0260379="hgKID" x-93640287="..." PC_ATTR="080808"/>

</x-13947931>

</x-785490824>

<x-785490824 x-40276037="pKGEs">

<x-590292021 x-57205665="...." PC_ATTR="02"/>

<x-13947931>

<x-1037159472 x-122584813="gPd39"

x-0260379="hgKID" x-93640287="..." PC_ATTR="060602"/>

<x-1037159472 x-122584813="o4GpM"

x-0260379="yr0QjJ" x-93640287="..." PC_ATTR="060602"/>

</x-13947931>

</x-785490824>

</x-1915689488>

/x-82592553>

  • Verify authenticity and integrity of ST

  • by using the Merkle Signature

  • Verify the completness

    • Translate the submitted query

    • Evaluate the obtained query on the secure structure

    • Check the policy configuration

    • Hash the result answer received by thePublisher

    • Match it with the obtained node-set.

/Asset[@Dept=‘IST’]/Funds/*

//x-785490824[@x-40276037=`pKGEs']/ x-13947931/*


Reply document generation algorithm

Reply Document Generation Algorithm

  • Reply Generator Algorithm

    • Input: SE-XML version of XML document d; A query q on d submitted by s; the policy configuration of s

    • Output: Reply document r

  • Evaluate q on d and return a well-formed XML document containing all and only the nodes satisfying q

  • Determine which access control policies apply to each node satisfying q

  • Remove from node-set the nodes that s is not authorized to see based on information in SE-XML for d

  • All the attributes in the resulting document are replaced with an AtteibuteElement element

  • An additional attribute called MhPath is inserted in each node to be returned to s

  • Insert Merkle signature of d

  • Rebuild document by taking the set of nodes returned from the above steps and transform into a well-formed document


Example reply document

Example Reply Document

  • Reply document generated by Publisher to an IST Professor who requests all the patents of CS department

    • MhPath attribute associated with Short-descr contains all the hash values needed to computer the Merkle has value of Patent starting from Short-descr.

Patent

Sign

Authors

MhPath

Short-descr

MhPath

MhPath


Authentication authenticable element

Authentication: Authenticable Element

  • Document d = (Vd, vd, Ed, Fed) is defined as follows: Vd is the set of all element nodes and attribute nodes in d, vd is the node representing the document element called the document root, Ed is the set of edges in d, and FEd is the edge labeling function

  • Definition 1: Let d = (Vd, vd, Ed, FEd) be an XML document, let g = (Vg, vg, Eg, FEg) be the SE-XML version of d, and r = (Vr, vr, Er, FEr) be the reply document to a query on d submitted by s. Let VT be the set of terminal nodes of r. Let Vr,e be the set of element nodes in the reply document r. For each v in Vr, e, v is authenticable by s iff. there exists vt in VT with v in path(vt) such that it is possible through a recursive bottom up computation to compute the Merkle hash value of vd using only the values in {w.MhPath: w is in path(vt)}

  • Theorem 1: Let g = (Vg, vg, Eg, FEg) be the SE-XML version of an XML document d and r = (Vr, vr, Er, FEr) be the reply document corresponding to a query submitted on d by subject s. Each node in Vr,e is authenticable by s

  • Proof of Theorem is by Induction on the length of the relative path of w with respect to v where v is in VT, w is in Vd and v is in path(w)


Authentication subject verification algorithm

AuthenticationSubject Verification Algorithm

  • Subject Verification Algorithm: Input: Reply document r = (Vr, vr, Er, FEr) Output = True if all nodes in r are authentic. False otherwise

  • Starting from each terminal node in the reply document, the algorithm recomputes the Merkle hash value of the root of document d through a bottom-up computation that uses the values of attributes MhPath of each node belonging to the path connecting the terminal node to the root of the reply document

  • The obtained value is compared with the decryption of the Merkle Signature of d using the Owner’s public key

  • If the two values coincide then all the nodes belonging to the path are authentic, otherwise the algorithm terminates and returns false


Authentication authentic element

Authentication:Authentic Element

  • Definition 2: Let g = (Vg, vg, Eg, FEg) be the SE-XML version of d, and r = (Vr, vr, Er, FEr) be the reply document to a query on d submitted by s. Each node v in Vr, e is authentic iff. V is authenticable by s and the computed Merkle has value of vd is equal to the decryption of Sign.val using the Owner public key

  • Theorem 2:

    • Let s be a subject, q be a query submitted by s, and r be the reply document received by s as an answer to q.

    • Subject verification algorithm returns True iff. Each v in Vr,e is authentic where Vr,e is the set of element nodes in the reply document r

  • Proof:

    • By theorem 1 all nodes of a reply document correspond to elements are authenticable by s. Therefore bt definitions 1 and 2, there exists for each vt in VT a recursive bottom-up computation able to compute Merkle hash value of the root of the document d using only the values of MhPath attributes of all nodes belonging to path (vt), and this value coincides with the decryption of the value of the Sign attribute with the Owner public key

    • The proof is to show that this recursive bottom-up computation is implemented by the Subject Verification Algorithms


Potential attacks and performance issues

Potential Attacks and Performance Issues

  • Attacks

    • Subject attacks

      • Subject Si eavesdropping during subscription phase of subject Sm

      • Subject attacking the secure structure and deducing sensitive attributes

    • Publisher attacks

      • Publisher changes the Sign element in SE-XML

  • Performance Issues

    • Update management

      • Modification of document implies changes to Merkle hash and SE-XML document

    • Storage complexity of security information

      • E.g, SE-XML and Secure Structure


Challenge integrating confidentiality and authentication

Challenge: Integrating Confidentiality and Authentication

  • Currently the portion of the Publisher that actually enforces the access control policy must be trusted

    • I.e. Trust with respect to Confidentiality

  • Challenge: How can we come up with a unified approach that ensures Confidentiality, Authenticity and Completeness

    • Directions: Apply access control policies to portions of the document and encrypt the views computers; only those authorized to see the views have the keys for decryption

    • Querying encrypted databases


Application secure web services

Application: Secure Web Services

  • How authenticity, confidentiality and integrity can be ensured in the presence of an untrusted UDDI?

  • Traditional techniques are not enough!

  • Possible solutions:

    • Integrity, confidentiality: selective encryption of the data managed by the UDDI according to the specified access control policies

    • Authenticity: Merkle hash trees

  • Additional security properties:

    • Completeness

    • Consistency


Authenticity

Query

UDDI

Service requestor

BusinessService

Authenticity

….traditional digital signatures do not fit well in third-party architectures!!

BusinessEntity

<dsig:Signature>

tModel

BusinessService

PublisherAssertion

BindingTemplate

Service provider


Merkle signature

Merkle Signature

  • An alternative way to sign an XML doc

  • By applying a unique digital

  • signature on an XML doc

  • it is possible to ensure the

  • authenticity of:

    • the whole document

    • any portion of it

  • It uses a different way to compute the digest of XML docs, based on the Merkle tree authentication mechanisms

BusinessEntity

<dsig:Signature>

tModel

BusinessService

PublisherAssertion

BindingTemplate


Related work and directions on xml security

Related Work and Directions on XML Security

  • Related Work

    • University of CA, Davis (started with relational databases and extended to XML)

  • Directions

    • Keep up with security as XML specifications evolve

    • How can we integrate confidentiality with authenticity and completeness without trusting the publisher?

    • Secure RDF models

      • Paper submitted to DEXA WebS Workshop

    • Temporal access control models for XML documents

    • Secure information interoperability

    • Secure semantic web

      • Computer Standards and Interface Journal, March 2005


  • Login