1 / 47

XML Security

XML Security. Donald E. Eastlake, III Donald.Eastlake@Motorola.com. Introduction. How did I get involved? Who is specifying the basic standards? Who is specifying the higher level standards? Who is implementing the standards? What is XML?. How did I get involved?.

alexia
Download Presentation

XML 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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. XML Security Donald E. Eastlake, III Donald.Eastlake@Motorola.com Secure XML

  2. Introduction • How did I get involved? • Who is specifying the basic standards? • Who is specifying the higher level standards? • Who is implementing the standards? • What is XML? Secure XML

  3. How did I get involved? • Started working on eCommerce protocols with CyberCash in 1996 (RFC 1898). • This led to working on the Internet Open Trading Protocol (IOTP) at CyberCash and then IBM. • IOTP was transferred to the IETF when the TRADE working group was formed which I chair. IOTP used XML and needed signatures (RFCs 2801, 2802, 2803, 2935, 2936). • This led to working on Secure XML at IBM and Motorola.(RFCs are at http://www.rfc-editor.org) Secure XML

  4. Who is specifying the standards? • Joint IETF/W3C XML Digital Signature working group <http://www.w3.org/Signature/> • I am co-chair of this group and co-editor of the main specification. • W3C XML Encryption working group <http://www.w3.org/Encryption/2001/> • I am co-editor of this specification. • W3C XML Key Management working group<http://www.w3.org/2001/XKMS> • I am a member of this working group. Secure XML

  5. Who is specifying the higher level standards? • Many application efforts • P3P, SOAP, IOTP, ... • European Telecommunications Standards Institute<http://www.etsi.org> • “Advanced” Digital Signatures • Organization for the Advancement of Structured Information Standards (OASIS)<http://www.oasis-open.org> • Security Assertion Markup Language (SAML) Secure XML

  6. Who is implementingthe standards? • See interoperability matrixes at the working group web pages • Includes: • Microsoft, NEC, Fujitsu, RSA, IBM, Entrust, HP, DSTC, IAIK, Baltimore, Apache Secure XML

  7. What is XML? • Yet another profile of SGML (Standard General Markup Language) as was HTML. • HTML is presentation oriented and in practice has been mucked up by the browser wars. • XML is structure oriented, extensible, and intended to have a much more rigorously enforced syntax. Secure XML

  8. What is XML (cont.)? • <?xml version='1.0' ?><element attribute="value"> text content of the element <child-element> . . . </child-element> <!-- comment --></element> Secure XML

  9. What is XML Security? • XML Digital Signatures (XMLDSIG) • XMLDSIG means that the “signature” structure is in XML. The signed data could be anything. • XML Encryption • XML Encryption means that the encryption information is in XML. The data which was encrypted could be anything. • XML Canonicalization • XML Key Management • Trust Extensions Secure XML

  10. Digital “Signatures” • “Sign” by calculating a “signature” based on the message(s) and a signing key. • Verify by a calculation based on the message(s), signature, and a verification key. • By itself, it only binds data to a key. • For “symmetric” secret key systems, the signing & verification keys are the same. Efficient but any verifier can forge signatures. • For asymmetric “public” key systems, the signing & verification keys are different. Less efficient but more secure. Secure XML

  11. Message Sign Verify Signature Pass/Fail Secret Key Digital “Signatures” (cont.) Secure XML

  12. Message Message Digest Message Digest Sign Verify Signature Pass/Fail Private Key Public Key Asymmetric Key Pair Digital “Signatures” (cont.) Secure XML

  13. XML Digital Signatures • First digests are calculated for each piece of data to be signed and a <Reference> element created. • <Reference (URI=)? (Id=)? (Type=)?> (Transforms)? (DigestMethod) (DigestValue)</Reference> Secure XML

  14. XML Digital Signatures (cont.) • Then a <Signature> element is created from the <Reference>s, keying information, signature algorithm & value. The signature is actually calculated over the SignedInfo subset of this information. • NOTE: This means that the actual signature algorithm is ALWAYS applied to XML. Secure XML

  15. XML Digital Signatures (cont.) • <Signature> <SignedInfo> (CanonicalizationMethod) (SignatureMethod) (Reference)+ </SignedInfo> (SignatureValue) (KeyInfo)? (Object)*</Signature> Secure XML

  16. Algorithms • There is no standard syntax for expressing an algorithm invocation in XML. • We used a “role” element, identifying the algorithm with an attribute and any needed explicit parameters as element content. • <Role Algorithm="http://example/foo"> <parameter>value</parameter>…</Role> Secure XML

  17. XML Digital Signatures (cont.) • The data being signed can be inside the <Signature>, within an <Object> element (enveloping), or • external to the <Signature> in the same document or elsewhere (detached), or • surrounding the <Signature> (enveloped), or • any combination of these. Secure XML

  18. Signature SignedInfo Reference Object Signed Data Enveloping Signature Secure XML

  19. XML Document Signed Data Signed Data Signature SignedInfo Reference Reference Detached Signatures Secure XML

  20. Signed Document Signature SignedInfo Reference Enveloped Signature Secure XML

  21. XML Digital Signatures (cont.) • To verify an XML digital signature you need to • verify the digests in each Reference, and • verify the signature value over the SignedInfo with the appropriate key and given signature algorithm. Secure XML

  22. What about <Transforms>? • A way to specify a sequence of algorithmic processing steps to apply • to the results retrieved from a URI to • produce the data to be signed, verified, or decrypted. • Can include compression, encoding, subset extraction, etc. • Not needed in simple cases but essential in complex cases Secure XML

  23. What is XML Security? • XML Digital Signatures (XMLDSIG) • XMLDSIG means that the “signature” structure is in XML. The signed data could be anything. • XML Encryption • XML Encryption means that the encryption information is in XML. The data which was encrypted could be anything. • XML Canonicalization • XML Key Management • Trust Extensions Secure XML

  24. Encryption • To encrypt, perform a calculation on the original “plaintext” and the encryption key to produce “ciphertext”. Ciphertext, by definition, does not reveal the original information. • To decrypt, perform a calculation on the “ciphertext” and the decryption key to recover the “plaintext”. • Symmetric secret key and asymmetric public key encryption available. Secure XML

  25. Encrypt Decrypt Private Decryption Key Public Encryption Key Asymmetric Key Pair Encryption (cont.) Secure XML

  26. XML Encryption • Provides two similar elements: <EncryptedData> and <EncryptedKey>. • Such elements provide the encryption algorithm, keying information, and either the ciphertext or a URL to the ciphertext. Secure XML

  27. XML Encryption • <EncryptedData (Id=)? (Type=)?> (EncryptionMethod)? (ds:KeyInfo)? <CipherData> <CipherValue>? (CipherReference URI='' '' )? </CipherData></EncryptedData> Secure XML

  28. Why Encryption is Easierthan Signature • Ways they are the same: • You must communicate the needed keying / algorithm / protocol information. • You must communicate some “random” binary information: • the encrypted data • the “signature” data • These are not too hard. In particular, it is known from the start that the binary info has no human meaning and must be communicated bit-for-bit correctly. Secure XML

  29. Why Encryption is Easierthan Signature (cont.) • The way they are different: • For signature only, you must communicate the original data that was signed. This data is usually changed as it is stored, transmitted, parsed, and processed, in ways such as • Character set and encoding • Numeric / date / time representation • Line endings • XML Namespace prefixes • etc. Secure XML

  30. What is XML Security? • XML Digital Signatures (XMLDSIG) • XMLDSIG means that the “signature” structure is in XML. The signed data could be anything. • XML Encryption • XML Encryption means that the encryption information is in XML. The data which was encrypted could be anything. • XML Canonicalization • XML Key Management • Trust Extensions Secure XML

  31. Why XML Canonicalization is Hard • EXACTLY the same sequence of data bytes must be used for signing as for verifying. Thus insignificant aspects that can change in transmission must be discarded. This is very hard with due to: • The problem of DTDs & Schemas • The problem of white space • The curse of namespaces • Plus the usual: • Encodings & character sets ( UTF-8, UTF-16, … ) • Multiple representations (<foo/>, <foo></foo>) Secure XML

  32. XML Canonicalization:DTDs and Schemas • XML (like SGML) provides for Document Type Descriptions (DTDs) which can define abbreviations (“entities”), insert default attribute values, and change the normalization of attributes. • XML has Schemas which can do similar things. • DTDs and Schemas can be internal or external and the same DTD/Schema processing must be done at both signing and verification. Secure XML

  33. XML Canonicalization:White Space • The indenting of XML with spaces and tabs makes it look free form. With secure XML, this is an illusion. You can never tell if white space in element content is significant, so it must be rigidly preserved. • <e> stuff and nonsense </e> • <e> <f>foo</f> <g/> </e> • White space in start and end tags is not significant. • <e z = "v " a = 'v2' >foo</e> Secure XML

  34. XML Canonicalization:Namespaces • So that XML from different sources can be combined without conflicts, element and attribute names can be qualified with a “namespace” prefix which represents a URI. • For brevity and because namespace prefixes are separated by a colon and URIs always contain a colon, URIs are bound to arbitrary prefix names and this binding effects all nested XML until overridden. Secure XML

  35. XML Canonicalization:Namespaces (cont.) • <e xmlns="http://a.test" xmlns:foo="ftp://b.example"> <default id="mumble"> <foo:bar q="value"> asdfghjkl mnbvcxz qwertyuiop </foo:bar> </default> <barbar foo:r="value2">. . .</barbar></e> Secure XML

  36. XML Canonicalization:Namespaces (cont.) • Problems: • Early definitions of XML canonicalization/serialization used generated prefixes but later XML standards (XSLT) have namespace prefixes in attribute values, etc. So they are significant. • The only one of the many different XML data models that preserves prefixes is XPATH so canonicalization uses it. • XPATH destroys the information as to where actual namespace declaration were in the input! It maps the declaration over all descendant nodes until overridden. • If XML is moved from one ancestor context to another, as is common for protocols, it can be invaded by different ancestor namespace declarations! Secure XML

  37. XML Canonicalization:Namespaces (cont.) • The Canonical XML specification imports ancestor namespace declaration. This protects against moving XML to a different context and having the signature still verify but mean something else due to changes in namespace bindings. • Exclusive XML Canonicalization excludes, as much as practical, ancestor namespace declarations. It permits XML to be encapsulated and de-capsulated without breaking signatures. Secure XML

  38. What is XML (take 2)? • An internal abstract data structure with a defined family of external representations in various character sets (DOM). • A family of UNICODE strings with external representations in various character sets (XSLT). • Something in between? Secure XML

  39. XML Canonicalization • Canonicalization must specify a myriad of other serialization aspects: • UTF-8 encoding, CDATA expanded, etc. • Deterministic attribute ordering • Handling of comments and processing instructions including those before/after the document • etc. Secure XML

  40. XML URI Format • Amazingly enough, before XML Security, there was no standard way of serializing URIs with miscellaneous UNICODE in them! • The %xx hex escape only escapes bytes, not characters. • So Canonicalization must specify a particular encoding (UTF-8) and exactly how to handle every special character on serializing and parsing URIs. Secure XML

  41. What is XML Security? • XML Digital Signatures (XMLDSIG) • XMLDSIG means that the “signature” structure is in XML. The signed data could be anything. • XML Encryption • XML Encryption means that the encryption information is in XML. The data which was encrypted could be anything. • XML Canonicalization • XML Key Management • Trust Extensions Secure XML

  42. XML Key Management (XKMS) • Originally from • VeriSign, Microsoft, webMethods • Key Information Service • retrieval of information about keys • Key Registration Service • store of information about keys • Uses the SOAP protocol for communication Secure XML

  43. What is XML Security? • XML Digital Signatures (XMLDSIG) • XMLDSIG means that the “signature” structure is in XML. The signed data could be anything. • XML Encryption • XML Encryption means that the encryption information is in XML. The data which was encrypted could be anything. • XML Canonicalization • XML Key Management • Trust Extensions Secure XML

  44. ETSI “Advanced” Signature • ETSI TS 101 903 draft v1.1.1 (February 2002) • Designed to comply with European Directive • Define assorted Policy and Time Stamp extensions • Add <SignedProperties> and <UnsignedProperties> element in an <Object> • Assumes public key certificates and CRLs • Defines series of extended signatures, each a superset of the previous • minimum: add policy/semantic and time stamp • maximum: full certificate chain and CRL set Secure XML

  45. SAML • Security Assertion Markup Language • An XML-based security standard for exchanging authentication and authorization information. • Being produced by OASIS<http://www.oasis-open.org> Secure XML

  46. Bonus Slide: Book Comparison Secure XML

  47. END W3C documents are at <http://www.w3.org/TR> Secure XML

More Related