1/4722 January 2003Secure XML XML Security Donald E. Eastlake, III [email protected].

22 January 2003 Secure XML 1/47

XML Security

Donald E. Eastlake, [email protected]


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


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.


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)


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


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.

What is XML (cont.)?

• <?xml version='1.0' ?><element attribute="value">

text content of the element<child-element>. . .</child-element>

</element>


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


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.


Digital “Signatures” (cont.)

Pass/Fail

Sign Verify

Secret Key

Signature

Message


Digital “Signatures” (cont.)

Sign Verify

Private Key

Public Key

Asymmetric Key Pair

Message Digest

Message Digest

Signature Pass/Fail

Message


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>


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.


XML Digital Signatures (cont.)• <Signature>

<SignedInfo>(CanonicalizationMethod)(SignatureMethod)(Reference)+

</SignedInfo>(SignatureValue)(KeyInfo)?(Object)*

</Signature>


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>



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


Enveloping Signature

Signature

SignedInfo

Reference

Object

Signed Data


Detached SignaturesXML Document

Signature

SignedInfo

Reference

Reference

Signed Data

Signed Data


Enveloped Signature

Signed Document

Signature

SignedInfo

Reference



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


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


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.


Encryption (cont.)

Encrypt Decrypt

Public Encryption

Key

Private Decryption

Key

Asymmetric Key Pair


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.


XML Encryption

• <EncryptedData (Id=)? (Type=)?>(EncryptionMethod)?(ds:KeyInfo)?<CipherData>

<CipherValue>?(CipherReference URI='' '' )?

</CipherData></EncryptedData>


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.


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.


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


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.


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>


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.


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>



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



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


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?


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.


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.


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


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


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>


Bonus Slide: Book Comparison

Title: Secure XML XML SecurityPublisher: Addison-Wesley RSA PressList Price: $44.99 $59.99Pages: 532 379Price/Page: $0.084568 $0.158285Impl. Info: Brief info on 25 Impl. Chapter on RSA sigs.Published 2002: July February

Candidate REC+signature, canon, excl-canon, encrypt signature, canon


ENDW3C documents are at<http://www.w3.org/TR>

1/4722 January 2003Secure XML XML Security Donald E. Eastlake, III [email protected].

Documents

Transcript of 1/4722 January 2003Secure XML XML Security Donald E. Eastlake, III [email protected].