Secure and Selective Authentication and Access Control of XML Documents

1
Secure and Selective Authentication and Access
Control of XML Documents

• Bhavani Thuraisingham
• March 29, 2007
• Lecture 22

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

3
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

4
Example XML Document
NSF
5
Publishing service how it works

• A new 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

6
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

7
Subject Credential Base Example
ltProfessor credID9 subID 16 CIssuer
2gt ltnamegt Alice Brown lt/namegt ltuniversitygt
UTD ltuniversity/gt ltdepartmentgt CS
lt/departmentgt ltresearch-groupgt Security
lt/research-groupgt lt/Professorgt ltSecretary
credID12 subID 4 CIssuer 2gt ltnamegt
John James lt/namegt ltuniversitygt UTD
ltuniversity/gt ltdepartmentgtCS lt/departmentgt ltleve
lgt Senior lt/levelgt lt/Secretarygt
8
Policy Base Example

• lt?xml version"1.0" encoding"UTF-8"?gt
• ltpolicy_basegt
• ...
• ltpolicy_spec IDP1' cred_expr"//Professordepar
  tment'CS'" target"annual_report.xml"
  path"//Patent_at_Dept'CS'//node()" priv"VIEW"/gt
• ltpolicy_spec IDP2' cred_expr"//Professordepar
  tment'CS'" target"annual_report.xml"
  path"//Patent_at_Dept'IST'/Short-descr/node()
  and //Patent_at_Dept'IST'/authors" priv"VIEW"/gt
• ltpolicy_spec IDP3' cred_expr"//Professordepar
  tment'IST' " target"annual_report.xml"
  path"//Patent_at_Dept'IST'//node()"
  priv"VIEW"/gt
• ltpolicy_spec IDP4' cred_expr"//Professordepar
  tment'IST'" target"annual_report.xml"
  path"//Patent_at_Dept'CS'/Short-descr/node() and
  //Patent_at_Dept'CS'/authors" priv"VIEW"/gt
• ltpolicy_spec IDP5' cred_expr"//secretarydepar
  tment'CS' and level'junior'"
  target"annual_report.xml" path"//Asset_at_Dept'CS
  '/node()" priv"VIEW "/gt
• ltpolicy_spec IDP6' cred_expr"//secretarydepar
  tment'CS' and level'senior'"
  target"annual_report.xml" path"//Asset_at_Dept'IS
  T'/Funds/_at_Type and //Asset_at_Dept'IST'/Funds/_at_Fu
  nding-Date" priv"VIEW "/gt
• ltpolicy_spec IDP7' cred_expr"//secretarydepar
  tment'IST' and level'junior'"
  target"annual_report.xml" path"//Asset_at_Dept'IS
  T'/node()" priv"VIEW "/gt
• ...
• lt/policy_basegt

9
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

10
System Architecture for Access Control
User
Pull/Query
Push/result
X-Access
X-Admin
Admin Tools
Credential base
Policy base
XML Documents
11
Third-Party Architecture
XML Source
policy base
Credential base
SE-XML

• 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

Owner
Publisher
Reply document
credentials
Query
User/Subject
12
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 Joes private key

13
Subject Policy Configuration
lt?xml version"1.0" encoding"UTF-8" ?gt
ltSubjectPolicyConfiguration IDProfessorCS"
created"08-05-2002"gt ltownergt
ltnamegtowner1lt/namegt ltorganizationgtCSlt/organi
zationgt ltstategtTexaslt/stategt
lturigtwww.owner1.comlt/urigt ltownergt
ltpolicygtVtaUBIxliHS1hzrqkKhYVTtYrafVSmCoJPkUVKYXCA
7yVdc7a/ne5sgIg0tGGRe3 /D2Xg6Fbwp3SAKK/Ref1teZCpD0
nlkx89GOIIcw8o9R3Mb2YY/slk5Fu0xxWXlB
YuWKWWNsXENKTkgiXL4mB1SUt4bmF6YG4lTxfxduVAwlt/poli
cygt lt/SubjectPolicyConfigurationgt
P1, P2
14
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

15
Policy Configuration/Policy Element
Where m is the number of policies applied on
document d

• 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
• ltPolicygt 1, 2, 3, 4, 5, 6, 7 lt/Policygt
• For each element, policy information in
  hexadecimal representation is also inserted

16
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-descrs PC value is 90 (hexadecimal
representation)
17
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
18
Security Enhanced XML document
XML Document

• Policy Information
• Merkle Signature

SE-XML Document
19
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))
20
Merkle Signature Example
MhX(Newspaper)h(h(Newspaper)h(Newspaper.content
) MhX
()MhX()MhX())
21
Security Enhanced XML document Example
lt?xml version"1.0" encoding"UTF-8"?gt ltAnnual
Report Year 2003 Name CS CG4g3D8/,mPVV/tT2O1
kZRFhdio"gt ltPolicygt1,2,3,4,5,6,7 lt/Policygt
ltAssetsgt ltAsset Dept CS"gt ltExpense
Tot"...." PC_ATTR"08"/gt ltFundsgt ltFund
Funding Date6/1/03" TypeNSF" Amount"..."
PC_ATTR"080808"/gt lt/Fundsgt lt/Assetgt
ltAsset DeptIST"gt ltExpenses Tot"...."
PC_ATTR"02"/gt ltFundsgt ltFund Funding
Date10/1/03" TypeDoD" Amount"..."
PC_ATTR"060602"/gt ltFund Funding
Date4/1/03" TypeCIA" Amount"..."
PC_ATTR"060602"/gt lt/Fundsgt lt/Assetgt
lt/Assetsgt - - - - - - - - - /AnnualReportgt
22
Secure Structure Example
lt?xml version"1.0" encoding"UTF-8"?gt ltx-82592553
x-4639474"rVR5DQ" x-67303774"QTQXS
Sign"OD2mc9aVV/tP4g3TG1kr4sFhdio"gt
ltPolicygt1,2,3,4,5,6,7 lt/Policygt ltx-1915689488gt
ltx-785490824 x-40276037"PlcZUo"gt ltx-590292021
x-57205665"...." PC_ATTR"08"/gt ltx-13947931gt
ltx-1037159472 x-122584813"fNhtL"
x-0260379"hgKID" x-93640287"..."
PC_ATTR"080808"/gt lt/x-13947931gt
lt/x-785490824gt ltx-785490824 x-40276037"pKGEs"gt
ltx-590292021 x-57205665"...." PC_ATTR"02"/gt
ltx-13947931gt ltx-1037159472
x-122584813"gPd39" x-0260379"hgKID"
x-93640287"..." PC_ATTR"060602"/gt
ltx-1037159472 x-122584813"o4GpM"
x-0260379"yr0QjJ" x-93640287"..."
PC_ATTR"060602"/gt lt/x-13947931gt
lt/x-785490824gt lt/x-1915689488gt /x-82592553gt
23
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

24
Merkle Hash Paths
25
Completeness Verification
lt?xml version"1.0" encoding"UTF-8"?gt ltx-82592553
x-4639474"rVR5DQ" x-67303774"QTQXS
Sign"OD2mc9aVV/tP4g3TG1kr4sFhdio"gt
ltPolicygt1,2,3,4,5,6,7 lt/Policygt ltx-1915689488gt
ltx-785490824 x-40276037"PlcZUo"gt ltx-590292021
x-57205665"...." PC_ATTR"08"/gt ltx-13947931gt
ltx-1037159472 x-122584813"fNhtL"
x-0260379"hgKID" x-93640287"..."
PC_ATTR"080808"/gt lt/x-13947931gt
lt/x-785490824gt ltx-785490824 x-40276037"pKGEs"gt
ltx-590292021 x-57205665"...." PC_ATTR"02"/gt
ltx-13947931gt ltx-1037159472
x-122584813"gPd39" x-0260379"hgKID"
x-93640287"..." PC_ATTR"060602"/gt
ltx-1037159472 x-122584813"o4GpM"
x-0260379"yr0QjJ" x-93640287"..."
PC_ATTR"060602"/gt lt/x-13947931gt
lt/x-785490824gt lt/x-1915689488gt /x-82592553gt

• 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 the Publisher
• Match it with the obtained node-set.

/Asset_at_DeptIST/Funds/
//x-785490824_at_x-40276037pKGEs'/ x-13947931/
26
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

27
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
28
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)

29
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
  Owners public key
• If the two values coincide then all the nodes
  belonging to the path are authentic, otherwise
  the algorithm terminates and returns false

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

31
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

32
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

33
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

34
Authenticity
.traditional digital signatures do not fit well
in third-party architectures!!
BusinessEntity
ltdsigSignaturegt
tModel
BusinessService
PublisherAssertion
BindingTemplate
Service provider
35
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
ltdsigSignaturegt
tModel
BusinessService
PublisherAssertion
BindingTemplate
36
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