XML and Security

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

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

3. XML Security Graph XML Security Encryption Controlled Fruition Digital Rights Management Access Control Subject-Role Modeling Policy Languages Resource/ Service Modeling Identity and Trust

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

5. 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)

6. 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)

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

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

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

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

11. 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)

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

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

14. User profiles • May contain digital certificates for roles (see later) • Environment conditions can be specified via external, independent XML information

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

16. Enter Web Services Abstraction of middleware Traditional middleware Request gets here somehow Service-agnostic request handler Source: A Web Services Primer, XML.com

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

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

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

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

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

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

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

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

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

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

27. Sample architecture

28. Enter DRM

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

30. License Server • Encryption key repository • User identity database • Usernames • Machine IDs • DRM License Generator

31. Client • DRM Controller • Nerve center of process • Rendering application • Content packages • Licenses • Identity

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

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

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

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

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

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

38. 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)

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

40. 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”

41. 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)

42. A XrML example “Grant unlimited rights of printing and viewing an e-book to Alice for an up-front payment of USD $15”

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

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

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

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

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

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

49. 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)