36
Secure Third Party Publication of XML Data Application: Secure Sharing of Digital Evidence Bhavani Thuraisingham June 2012

Secure Third Party Publication of XML Data Application: Secure Sharing of Digital Evidence

Embed Size (px)

DESCRIPTION

Secure Third Party Publication of XML Data Application: Secure Sharing of Digital Evidence. Bhavani Thuraisingham June 2012. Motivation. Digital Evidence Represented in XML (eXtensivle Markup Language) XML documents have to be secured - PowerPoint PPT Presentation

Citation preview

Secure Third Party Publication of XML DataApplication: Secure Sharing of Digital Evidence

Bhavani Thuraisingham

June 2012

Motivation Digital Evidence Represented in XML (eXtensivle Markup Language) XML documents have to be secured

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

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

Example XML Document

NSF

Patents

Asset

Year: 2003

Name: UTD

Expenses

Dept

Author

Short-desc

ID

Annual report

Assets

Asset

Equipment

Books

Patent

Other

Tot

Funds

Date

6/1/03Type

Amout

1m$

Date

Dept

UTD

Tech-details

Patent

CashCS

Fund

04/19/23 4

Users

Publishing Service

WEBWEB

Push/Pull modes Security requirements:

Confidentiality Integrity Authenticity Completeness

Publishing service: how it worksA new class of information-centered applications based on Data

dissemination

Possible scenarios:

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

Intra-company information systems

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

<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>

04/19/23 7

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']/Funds/@Type and //Asset[@Dept='IST']/Funds/@Funding-Date" 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 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

UserPull/Query Push/result

XML Documents

X-Access X-AdminAdmin Tools

Policybase

Credentialbase

04/19/23 10

Third-Party Architecture

Credential base

policy baseXML Source

User/Subject

Owner

Publisher

Query

Reply documen

t

SE-XML

credentials

The Owner is the producer of information It 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

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

04/19/23 12

<?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>

Subject Policy Configuration

P1, P2

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

04/19/23 14

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

Where m is the number of policies applied on document d

04/19/23 15

Policy Configuration: example Consider the short-descr element 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-descr element is 1001000

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

04/19/23 16

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 elementi.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 3P1

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

04/19/23 17

• Policy Information• Merkle Signature

XML Document

SE-XML Document

Security Enhanced XML document

04/19/23 18

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

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

titletitleAuthor

Author

paragraph

Politic_page Literary_page

Paragraphs

title

date

titleAuthor

titleAuthortopictitleAuthortopictitleAuthortopic

titleAuthortopic

Article

Newspaper

Frontpage

Leading

Sport_page

news newsPolitic

paragraph

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

Merkle Signature Example

04/19/23 19

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

titletitleAuthor

Author

Politic_page Literary_page

Paragraphs

title

date

titleAuthor

titleAuthortopictitleAuthortopictitleAuthortopic

titleAuthortopic

Article

Newspaper

Frontpage

Leading

Sport_page

news newsPolitic

paragraphparagraph

MhX(Newspaper)

Merkle Signature of Newspaper XML file

Merkle Signature Example

04/19/23 20

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>

04/19/23 21

<?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>

Secure Structure Example

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

04/19/23 23

Merkle Hash Paths

5

8

11

9

13

4

2

10 12

6

14 1615 17

7

3

1

8

11

9

13

4

2

10 12

6

14 1615 17

7

1

3

5

8

11

9

13

4

2

10 12

6

14 1615 17

7

1

5

3

w w w

v v v

MhPath(4,1) MhPath(7,1) MhPath(5,1)

04/19/23 24

<?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>

Completeness Verification

Verify authenticity and integrity of ST by using the Merkle Signature

Verify the completness1. Translate the submitted query

2. Evaluate the obtained query on the secure structure

3. Check the policy configuration4. Hash the result answer received by

the Publisher5. Match it with the obtained node-

set.

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

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

Applications to Digital Forensics

Owner is the FBI person who collects the forensics Publisher is the FBI web site that may be hacked (e.g.,

CENTCOM was hacked recently – 60 minutes CBS Nov 8, 2009) Subject is an FBI agent located anywhere in the US or in the

world Digital evidence represented as an XML document (XML is now

used for digital evidence) Not all agents have access to all evidence Policies set by owner will specify who has access to what

APPENDIX

Bhavani Thuraisingham

November 11, 2009

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 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

Authors

Short-descr

Sign

MhPath

MhPath MhPath

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)

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 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 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 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 ServicesHow 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

04/19/23 35

Authenticity

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

Service requestor

Service provider

UDDIQuery

BusinessEntity

BusinessService

BindingTemplate

<dsig:Signature>

BusinessService

tModel

PublisherAssertion

04/19/23 36

Merkle Signature• An alternative way to sign an XML doc

• By applying a unique digitalsignature on an XML docit 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

BusinessService

BindingTemplate

<dsig:Signature>

tModel

PublisherAssertion