Xml and security
This presentation is the property of its rightful owner.
Sponsored Links
1 / 49

XML and Security PowerPoint PPT Presentation


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

XML and Security. Ernesto Damiani DTI - Università di Milano. (joint work with Sabrina De Capitani di Vimercati, Stefano Paraboschi (2) and Pierangela Samarati (2) Università di Bergamo) http://seclab.dti.unimi.it. Outline of the talk. XML Security Graph XML Access Control Model

Download Presentation

XML and Security

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


Xml and security

XML and Security

Ernesto Damiani

DTI - Università di Milano

(joint work with Sabrina De Capitani di Vimercati, Stefano Paraboschi (2) and Pierangela Samarati

(2) Università di Bergamo)

http://seclab.dti.unimi.it


Outline of the talk

Outline of the talk

  • XML Security Graph

  • XML Access Control Model

  • XML-based Languages for AC

  • XML-based Controlled Fruition and DRM

  • Identity Management

  • Reputations


Xml security graph

XML Security Graph

XML Security

Encryption

Controlled Fruition

Digital Rights

Management

Access Control

Subject-Role

Modeling

Policy Languages

Resource/

Service

Modeling

Identity and Trust


How it all started

How it all started

  • Information exchanges on the Internet should meet precise protection requirements:

    • fine-grained authenticity,

    • secrecy

    • non-repudiation

    • access control

  • All of them needed to be addressed for XML data model

  • Techniques to satisfy these requirements:

    • Authentication

    • Access control

    • Encryption


Our approach

Our approach

  • Our approach:

  • Server-side access control techniques protecting information at the same granularity level provided by XML

  • Support of authorizations at the different granularity levels

  • Support of exceptions and overriding/conflict resolution policies

  • Provide easy integration with existing technology

  • Authorizations expressed in XML syntax

  • Enforcement based on standard transformation techniques

Policy

(in XML)

Request

Server

Client

XML

data

Response

(transformed XML)


Xml ac features

XML AC Features

  • Coarse and fine grained specifications:

  • Instance level authorizations: apply to individual documents

  • DTD/Schema level authorizations: apply to collections of documents sharing the same schema

  • Local authorizations: apply only to direct attributes and PCDATA

  • Recursive authorizations: recursively propagate to sub-elements

  • Positive and Negative authorizations: permissions and prohibitions

    • Overriding policy:most-specific-take-precedence principle

    • Instance level authorizations more specific that DTD ones

    • Authorizations on attributes/elements more specific than those on elements they belong to

      • Default principle can be subverted

    • Hard DTD level authorizations: do not allow exceptions

    • Soft instance level authorizations: apply only as default if no DTD authorizations are given

  • Enforcement: LPP (label, propagate and prune) on the DOM tree. Can be done using XSLT as well.

Some References:

Ernesto Damiani, Sabrina De Capitani di Vimercati, Stefano Paraboschi, Pierangela Samarati: Securing XML Documents, Proceedings of EDBT 2000

Ernesto Damiani, Sabrina De Capitani di Vimercati, Stefano Paraboschi, Pierangela Samarati: A fine-grained access control system for XML documents. IEEE Trans. Sec. 5(2): 169-202 (2002)

Ernesto Damiani, Pierangela Samarati, Sabrina De Capitani di Vimercati, Stefano Paraboschi: Controlling Access to XML Documents. IEEE Internet Computing 5(6): 18-28 (2001)


Authorization form

Authorization Form

  • An authorization is a 5-tuple hsubject,object,action,sign,typei

  • _ subject: triple of the form [user/group,ip,host-name]

  • _ object: (XPath) path expression

  • _ action: read

  • _ sign: permission (+) and denial (-)

  • _ type: LDH, RDH, L, R, LD, RD, LS, RS

  • Examples

  • _ (admin,*,*.it),EMPLOYEE,read,+,RD

  • _ (Alice,*,*),EMPLOYEE[./ROLE = “manager”]/SALARY,read,-,L

  • _ (employee, 192.20.*,*), EMPLOYEE, read, +, R

  • _ (employee,*,*),EMPLOYEE/SALARY,read,-,LS


Xml access sheet xas

XML Access Sheet (XAS)

  • Authorizations on a document/DTD specified in an XML

  • Access Sheet (XAS) associated with the document/DTD

  • <!ELEMENT set of authorizations (authorization)+>

  • <!ELEMENT authorization (subject,object,action,sign,type)>

  • <!ELEMENT subject (#PCDATA)>

  • <!ELEMENT object (#PCDATA)>

  • <!ELEMENT action empty>

  • <!ELEMENT sign empty>

  • <!ELEMENT type empty>

  • <!ATTLIST set of authorizations about CDATA #REQUIRED >

  • <!ATTLIST type value (LjRjLDHjRDHjLSjRSjLDjRD) #REQUIRED>

  • <!ATTLIST sign value (+ j _) #REQUIRED>

  • <!ATTLIST action value (read) #REQUIRED>


Today

Today

  • Several industrial and academic research groups working in the area, e.g. Tokyo IBM Research Labs;

  • See Christian Geuer-Pollman’s “XML Security Page” for detailed list of people/papers

  • XML Security Workshop held at ACM CCS Conference since 2001

  • Well-understood problem, still some open issues

    • Main one: not all semantically relevant concepts correspond to XML subtrees, so data-model level policies are not always feasible

    • Sometimes need to use metadata rather than data to identify objects

      • Performance worries


Controlled fruition

Can be seen as a ‘modern’ view of access control:

Interacting with users

Checking environment transient conditions (e.g., timing, quality) for authorized users

Enforcement by fine-grained encryption (sometimes)

Advanced facilities for managing policies and infrastructure

Crucial for digital content suppliers and distributors

Controlled Fruition


Encryption based controlled fruition

sender

Scrambled data

receiver

Control word, access rights

Encryption-based Controlled Fruition

  • Pay - TV model

  • Encryption rather than access control

  • Customer receives decryption module

  • Decryption on chipcard conditional access module (CAM)


Fruition control models and languages

Fruition Control models and languages

  • Controlled fruition based on metadata about multimedia content AND requestors

  • A fully XML-based technology: XML for requestors’ profiles, XML for multimedia metadata, XML for policies

  • AIMED AT SUPPORTING POLICY COMPOSITION AND FEDERATION

  • Available policy languages: from DRML to XrML/Content Guard, SAML, XACML

  • Infrastructure-based Enforcement PDP, PEP and authorities

  • Still evolving


Resource metadata

Resource metadata

  • Metadata describe structure and semantics of data

  • Heterogenous structure and syntax but a common underlying format

    • XML tagging

    • interspersed with multimedia flow or external

  • Problems in policies/objects binding

    • Use XML parsing/XPaths can be awkward

References: Ernesto Damiani, Sabrina De Capitani di Vimercati, Eduardo Fernández-Medina, Pierangela Samarati: Access Control of SVG Documents. DBSec 2002: 219-230


User profiles

User profiles

  • May contain digital certificates for roles (see later)

  • Environment conditions can be specified via external, independent XML information


Easy binding

Easy binding

  • Referring to user profiles and/or to resource metadata within AC and DRM policies can be made by implicit or explicit binding

    • Implicit binding: sharing or mapping namespaces

    • Explicit bindings: XPaths


Enter web services

Enter Web Services

Abstraction of middleware

Traditional middleware

Request gets here somehow

Service-agnostic request handler

Source: A Web Services Primer, XML.com


Soap execution sequence

SOAP Execution Sequence

Source: Fine Grained Access Control for SOAP E-Services, Damiani et al.


Soap message overview

SOAP Message Overview

  • Message is embedded in Envelope element

  • Envelope has Header and Body elements

    • Header is optional; Body is mandatory

    • Contents are application specific

  • Children of Header (called blocks) allow

    • SOAP processors to exchange information

    • Application specific extensions


Protecting web services

Protecting Web Services

  • A message that requests RPC must contain

    • Target of the procedure or method (final node)

    • A procedure or method name (usually a URI)

    • Parameters to the procedure or method (body)

    • Context for the service (contained in header)

  • Idea: use fine-grained security to define access control to SOAP e-services

  • Document to be protected: SOAP message

  • (Later: document to be protected = interface description in WSDL)

POST /StockQuote HTTP/1.1

Host: www.stockquoteserver.com

Content-Type: text/xml; charset="utf-8"

Content-Length: nnnn

SOAPAction: "Some-URI"

<soapenv:Envelope

xmlns:soapenv=

"http://schemas.xmlsoap.org/soap/envelope/">

<soapenv:Body>

<m:GetLastTradePrice xmlns:m="Some-URI"> <m:tickerSymbol>DIS</m:tickerSymbol>

</m:GetLastTradePrice>

</soapenv:Body>

</soapenv:Envelope>


Protecting web services our approach

Protecting Web Services: our approach

  • Policy (In XML) expresses acceptable service requests to a web-service interface

  • May contain conditions on call parameters

  • Subject/Role encoded in call header

  • Evaluated by SAX parsing for speed: limits to expressive power

  • Open issues: Performance

    • pre-compute to avoid role-hierarchy navigation

Reference: Ernesto Damiani, Sabrina De Capitani di Vimercati, Stefano Paraboschi, Pierangela Samarati: Fine grained access control for SOAP E-services. International Journal of Computer Security, 2001


Today1

Today

  • From papers to standards

    • Oasis standard XACML (Sun J2EE) released 2003, based on our and IBM Tokyo RL’s work

    • Microsoft, IBM and Verisign’s WS Security released 2003

    • Reference implementations available


Web services standards landscape

ebXML Collaboration Protocol

Business Process Spec Schema

ebXML Messaging Service

ebXML Core Components

ebXML Registry

WS-Choreography

XML Digital Signature

WS-ReliableMessaging

UBL

WS-Security

SAML

HTTP

WSDL

XML Schema

UDDI

XML

XACML

SOAP

ebXML

UN

CEFACT

W3C

OASIS

UN

CEFACT

Web Services Standards Landscape


Focus on security

ebXML Collaboration Protocol

Business Process Spec Schema

ebXML Collaboration Protocol

Business Process Spec Schema

ebXML Messaging Service

ebXML Registry

ebXML Core Components

ebXML Messaging Service

ebXML Registry

ebXML Core Components

WS-Choreography

WS-Choreography

WS-ReliableMessaging

XML Digital Signature

WS-ReliableMessaging

XML Digital Signature

UBL

SAML

HTTP

WS-Security

XML

XML Schema

WSDL

UDDI

UBL

XACML

SOAP

WS-Security

SAML

HTTP

XML

XML Schema

WSDL

UDDI

XACML

SOAP

ebXML

ebXML

UN

CEFACT

W3C

OASIS

UN

CEFACT

W3C

OASIS

Focus on Security


Focus on business process modelling

ebXML Collaboration Protocol

ebXML Collaboration Protocol

Business Process Spec Schema

Business Process Spec Schema

ebXML Messaging Service

ebXML Messaging Service

ebXML Registry

ebXML Registry

ebXML Core Components

ebXML Core Components

WS-Choreography

WS-Choreography

WS-ReliableMessaging

WS-ReliableMessaging

XML Digital Signature

XML Digital Signature

UBL

UBL

WS-Security

WS-Security

SAML

SAML

HTTP

HTTP

XML

XML

XML Schema

XML Schema

WSDL

WSDL

UDDI

UDDI

XACML

XACML

SOAP

SOAP

ebXML

ebXML

UN

CEFACT

UN

CEFACT

W3C

W3C

OASIS

OASIS

Focus on Business Process Modelling


Ws security

WS-Security

  • Published April 2002 by Microsoft, IBM e VeriSign.

  • Subject identifgied via token (e.g. X.509 cerificate) in SOAP header.

  • Use of XMl encryption and digital signatures to protect integrity.

  • Version 2.0 published recently (Sept. 2003, but several parts still missing


Sample policy

Sample policy

<wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2002/12/policy" xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext">

<wsp:ExactlyOne>

<SecurityToken wsp:Usage="wsp:Required">

<TokenType>wsse:UsernameToken</TokenType>

<Claims>

<UsePassword wsp:Usage="wsp:Required" Type="wsse:PasswordDigest" />

</Claims>

</SecurityToken>

<SecurityToken wsp:Usage="wsp:Required">

<TokenType>wsse:X509v3</TokenType>

<Claims>

<SubjectName>O=SinfoPragma, C=IT</SubjectName>

</Claims>

</SecurityToken>

</wsp:ExactlyOne>

</wsp:Policy>


Sample architecture

Sample architecture


Enter drm

Enter DRM


Content server

Content Server

  • Content Repository

    • Content Management system

    • Digital Asset Management system

    • File server

  • Product Info

    • Rights

    • Product metadata

  • DRM Packager

    • Packages content with metadata

    • Encrypts


License server

License Server

  • Encryption key repository

  • User identity database

    • Usernames

    • Machine IDs

  • DRM License Generator


Client

Client

  • DRM Controller

    • Nerve center of process

  • Rendering application

  • Content packages

  • Licenses

  • Identity


Processes

Processes

  • A. User Initiation

  • User obtains content package

  • User requests operation (view, play)

  • DRM controller collects info

    • Content

    • Identity

    • Requested rights

  • DRM controller calls license generator

  • B. License generation

  • DRM License Generator…

    • Checks content & identity

    • Obtains keys from key repository

    • Creates & sends license to client

    • Generates financial transaction, where necessary

  • C. Completion

  • DRM Controller…

    • Receives license

    • Extracts keys from license

  • Decrypts content

    • Generates financial transaction, where necessary

    • Hands content to rendering application

  • D. Rendering application plays content


Multiple digital identities

Multiple Digital Identities

  • Information you supply

    • Name

    • Email address

    • Password

  • Information inherent to you

    • Biometric, e.g. retina scan

  • Information held by trusted third party

    • Digital certificate

  • Partial identities are a group of attributes that the user can select for dealing in different scenario

  • Reference Ernesto Damiani, Sabrina De Capitani di Vimercati, Pierangela Samarati: Toward Multiple Dependable Identities, IEEE Internet Computing Dec. 2003


Identities and authentication

Identities and Authentication

  • Device authentication

    • Example: Gemstar eBook readers

    • Enables: 1 device/ users

  • User authentication

    • Example: anything with a password

    • Enables: 1 user/ devices

  • Combo authentication

    • Example: Microsoft “persona”, InterTrust, Liquid Audio

    • Enables: 1 user/N devices

8

8


Content standards hierarchy

<indecs2>RDD

Individual

Publishers

ContentManagement

Rights/holder

Management

Business

Models

XrML, ODRL,

ICE

ONIX, PRISM,

LOM, NewsML

PDF, Flash,

Real, WMP

DOI

Content

Industries

IP Identification

Formats &

Players

Product

Metadata

Rights

Passport,Liberty Alliance

RSA, BlowFish, AES, RC5, etc.

E-Commerce

Payment Schemes

Authentication

Encryption

The Internet

HTTP, HTML, XML

Content Standards Hierarchy


Digital object identifier doi www doi org

Digital Object Identifier (DOI www.doi.org)

  • Unique ID for any type of content

    • Syntax allows it to subsume any other ID scheme,E.g., ISBN, ISSN, CUSIP, ISWC

  • Invented in 1994-6

    • Association of American Publishers

    • Book and journal publishing

  • Like a URL but location independent

    • Location of content stored in central directory

    • DOI stays the same, location and ownership can change

  • Interoperable with almost any DRM technology

  • Global DOI Directory with Registration Agencies (RAs)

  • Accepted by NISO & ISO, Submitted to IETF

    • Clashes with IETF URN specification


Doi status

DOI Status

  • International DOI Foundation governs

    • Board members include publishers, HP, Microsoft, CCC

  • Certified Registration Agencies

    • Content Directions Inc. – general RA

    • Learning Objects Network – focused on DoD/SCORM

    • Enpia Systems Ltd. – Korea

    • CrossRef – nonprofit for linking scientific journal articles

  • Adoption

    • Big in the scientific journal community

    • Slow adoption in book publishing

    • Magazines starting to show interest

    • DRM system implementation: Enpia Systems


Drm languages

DRM languages

  • A DRM language specifies:

    • The parties authorized to use a resource

    • The rights granted to those parties

    • The terms and conditions under which rights can be exercised

  • Fully declarative, standard syntax, clear semantics

  • Early examples:

    • DPRL (Xerox PARC, 1996)

    • XrML 1.0 (1999)


Extensible rights markup language xrml

eXtensible Rights Markup Language (XrML)

  • Invented at Xerox PARC around 1994 (DPRL)

  • Owned by ContentGuard Inc.

    • Holds patents

    • Xerox spinoff

    • Microsoft has minority stake

  • XML-based language for describing rights models

    • Rights

    • Attributes

    • Types of users

    • Security levels

  • Uses other XML standards

    • Schema

    • Namespaces

    • Digital signature

    • Xpath

  • www.xrml.org


Xrml basics

XrML Basics

  • Lexicon: Principals, Resources, Conditions and Rights

  • Principal : a person, e.g. ‘Alice’, or a label, e.g. ‘PDQ Records’

  • Resource : some sort of content, e.g. the song ‘When the Whistle Blows’

  • Right : a fruition mode, e.g. ‘play’

  • Condition : a constraint, e.g. temporal ‘for two weeks’ or related to watermark, e.g. SDMI markup

A LICENSE :

“Under the authority of PDQ Records, Alice is granted the right to play ‘When the Whistle Blows’ for two weeks”


Xrml licenses

XrML Licenses

  • PrincipalA keyholder holding a private/public key pair provided by a CA

  • Righta token from a XML namespace (XrML 2.0 Core: obtain, issue, revoke; XrML 2.0 Extension: print, play)

  • Resourcea URI

  • Condition a token from a XML namespace (XrML 2.0 Extension: watermark, destination and renderer)


A xrml example

A XrML example

“Grant unlimited rights of printing and viewing

an e-book to Alice for an up-front payment of USD $15”


Xrml status

XrML Status

  • Complex and difficult to implement

    • E.g., 24 different types of rights

    • More like OS-level spec (a la POSIX)

  • Microsoft only licensee with shipping product

    • Currently based on subset of XrML

    • Future plans for full implementation

    • Other vendors planning implementations: Zinio, OverDrive

  • Standards body acceptance

    • Adopted (with future modification) by MPEG-21

    • Given over to OASIS for future modification

  • Patent on any rights language

    • Could sue other vendors on that basis


Open digital rights language odrl

Open Digital Rights Language (ODRL)

  • Invented 2001

    • Renato Iannella, consultant, IPR Systems, Australia

    • Used as basis for IPR’s custom implementations

  • Metadata model

    • Open, “no one to sue”

    • Derived from <indecs> meta-model

    • Like “XrML Lite”

    • Compact, elegant

  • Mostly of theoretic interest

    • Proposed by RealNetworks for MPEG-21 instead of XACML

    • Cited by various researchers

    • Only implementations in Pacific Rim

  • www.odrl.net


Enter p2p networks

Enter P2P Networks

  • Peer-to-Peer (P2P) networks are rapidly achieving an important role in the Internet experience of millions of users.

  • P2P applications allow users to connect directly to other users' machines in order to exchange files and other resources (Some examples: Kazaa, Limewire, Gnutella)

    ,

  • Four common characteristics define a P2P application:

    • Peers discover each other without the need of a centralized index;

    • Peers simulate a broadcast network over the Internet by relaying messages (within a horizon)

    • All peers can query other peers;

    • All peers can share content, i.e. resources with other peers.

References: Ernesto Damiani, Sabrina De Capitani di Vimercati, Stefano Paraboschi, Pierangela Samarati, Fabio Violante: A reputation-based approach for choosing reliable resources in peer-to-peer networks. ACM Conference on Computer and Communications Security 2002: 207-216

Fabrizio Cornelli, Ernesto Damiani, Sabrina De Capitani di Vimercati, Stefano Paraboschi, Pierangela Samarati: Choosing reputable servents in a P2P network. WWW 2002: 376-386


Anonymity and opaque identifiers

Anonymity and opaque identifiers

  • Interaction among peers is usually carried out by preserving (some degree of) anonymity.

  • Peers use opaque identifiers rather than names or IP network addresses to communicate with each other, except when downloading

  • Identifiers can be changed at every interaction

  • Anonymity means security concerns:

    • the user has no guarantee on the quality of the resources available on the network.

    • it becomes relatively easy to spread malicious content, such as viruses, Trojan horses or spam.


A democratic solution p2p xrep

A ‘democratic’ solution: P2P-XRep

  • We proposed a protocol (P2P-XRep) that permits to evaluate the reliability of the shared contents by polling the community of P2P users

  • P2P-XRep basics:

    • Peers are asked for their opinion on the trustworthiness of a resource and/or of the peer from which it is obtained.

    • The poll is based on the exchange of reputations of nodes and resources on the P2P network

    • Reputations are attached to opaque identifiers, encouraging well-intentioned peers to keep them rather than discard them after each transaction

    • Reputation is built on previous users experiences and stored locally on each node in a personal experience repository.

    • Based upon all the collected opinions, an aggregated reputation value is produced synthesizing all the received answers to the poll.


Local and network reputations

Local and network reputations

  • Reputations are defined at two levels: local and network reputations.

    • Network reputations are built by collecting and combining votes by way of the P2P-XRep protocol and represent the overall perception of the community

    • Local reputations derive from the direct experience of a peer with the other peer or resource under scrutiny.

  • Using fuzzy values for individual votes would require a shared measure of trust

  • Rather, we use crisp (boolean) votes to emphasize the role of the synthesis in constructing the reputation

  • Fuzzy techniques are used to aggregate a possibly huge number of crisp votes into a single trust value.


References

References

  • Ernesto Damiani, Sabrina De Capitani di Vimercati: Securing XML-based Multimedia Content. SEC 2003: 61-72 2002

  • Ernesto Damiani, Sabrina De Capitani di Vimercati, Eduardo Fernández-Medina, Pierangela Samarati: Access Control of SVG Documents. DBSec 2002: 219-230

  • Fabrizio Cornelli, Ernesto Damiani, Sabrina De Capitani di Vimercati, Stefano Paraboschi, Pierangela Samarati: Implementing a Reputation-Aware Gnutella Servent. NETWORKING Workshops 2002: 321-334

  • Fabrizio Cornelli, Ernesto Damiani, Sabrina De Capitani di Vimercati, Stefano Paraboschi, Pierangela Samarati: Choosing reputable servents in a P2P network. WWW 2002: 376-386

  • Ernesto Damiani, Pierangela Samarati, Sabrina De Capitani di Vimercati, Stefano Paraboschi: XML access control systems: a component-based approach. Informatica (Slovenia) 26(2): (2002)

  • Ernesto Damiani, Sabrina De Capitani di Vimercati, Stefano Paraboschi, Pierangela Samarati: A fine-grained access control system for XML documents. TISSEC 5(2): 169-202 (2002)

  • 2001

  • Piero A. Bonatti, Ernesto Damiani, Sabrina De Capitani di Vimercati, Pierangela Samarati: An Access Control Model for Data Archives. SEC 2001: 261-276

  • Ernesto Damiani, Pierangela Samarati, Sabrina De Capitani di Vimercati, Stefano Paraboschi: Controlling Access to XML Documents. IEEE Internet Computing 5(6): 18-28 (2001)


  • Login