XML Signature 2.0

1. XML Signature 2.0

2. Timelines • 2002 – XML Signature 1.0 • 2007 – XML Signature 1.0, 2nd edition • Adds support for Canonicalization • 2009 end – XML Signature 1.1 • Adds support for Elliptic Curve algorithms required for NIST Suite B • SHA2 algorithms, DER format for keys, OCSP Response and few other things • 2010 mid – XML Signature 2.0 • Major changes – discussed in rest of presentation. • The first draft of XML Signature 2.0 is out, and it now open for public review.

3. Primary goals • Robustness • Security & Policy check • Streaming & Performance • Simplicity • Backward compatibilty • See draft specs • Signature 2.0: http://www.w3.org/TR/2009/WD-xmldsig-core2-20091022/ • Canonicalization 2.0 http://www.w3.org/TR/2009/WD-xml-c14n2-20091022/

4. Robustness • XML Signature 1.x is surprisingly brittle • Developers spent a lot of time in interops and escalations chasing signature verification issues. • Why does the signature verification fail? • Any change in whitespace causes the signature to break. • It is popular misconception that canonicalization takes care of whitespace. It doesn’t ! • All of these will break the signature : a) pretty printing the document, b) converting spaces to tabs, c) adding new lines, d) copy/pasting from log file . • _ • The other major reason is namespaces • Change in the prefix value breaks the signature. E.g <soap:Body> is not considered the same as <s:Body> even if the prefixes “soap” and “s” are defined to be the same. • Unused namespace declarations can break signature. – especially uses around default prefix. • Exclusive canonicalization solves some namespace problems but not all.

5. Robustness (contd) • XML Signature 2.0 solves most of these problems • Merges “Inclusive” and “Exclusive” canonicalization into one – the new canonicalization 2.0. XML Signature 2.0 needs to use this canonicalization. • In canonicalization 2.0 • Text nodes are “trimmed”, i.e. leading and trailing whitespace is removed • Namespace prefixes are rewritten. E.g. both <soap:Envelope> and <s:Envelope> will be converted to <n1:Envelope> • Prefixes that are embedded in content are also changed. The most common place is the xsi:type attribute. E.g. if the original value of xsi:type was “xsd:string”, its value will be changed during rewriting. • These changes will help in JAXB based canonicalization. • Canonicalization 2.0 is “parameter based”. i.e. all of these new changes are controlled by parameters and they can be turned off to get output that is completely same as canonicalization 1.x

6. Security • XML Signature 1.x’s flexibility leads to vulnerability. • A signature has a set of “Transforms” to convert from XML -> bytes • A transform is a procedural step e.g. XPath selection, XSLT snippet, canonicalization etc. • Low level crypto algorithm can only sign bytes. These transforms convert XML -> bytes. • The simplest signature has only one transform – canonicalization. • But a complex signature can have many e.g. an XPath selection, followed by XSLT transformation, followed by canonicalization • The signature verifier needs to execute each of these transforms and at the end of the transform will get the bytes. • Transforms can be misused for many kinds of attacks.See http://www.w3.org/TR/xmldsig-bestpractices/ • Denial of Service attacks – complex XPath and XSLT • Wrapping attacks – what is signed is not evident • Cross site scripting attacks – gain elevated access privileges

7. Security (contd) XML Signature is used in these security models • Client <-> Server messaging. • E.g. in Web services, SAML, ebXML, remote Portlets etc. • The server checks the signature in client’s message to determine if the message is valid. This happens before any kind of authorization. (The message is completely untrusted when the signature check is happening, so the signature check process needs to be secure. For outside firewall servers, the message can have originated from anywhere on the internet.) • Long term document storage • The server signs the document and stores it in an untrusted storage. Later on it retrieves the document , and makes sure it has not been tampered with.(Much more limited attack scope.)

8. Security (contd) • XML signature 2.0 introduces “declarative model” • Basic premise: before verification, signature is untrusted, so it cannot specify how to verify itself. i.e. No TRANFORMS. • Transforms are replaced by simple properties • Type/subtype of data, URI, Inclusion XPath, Exclusion XPath, Enveloped etc. • Verifier decides how to actually check the signature instead of blindly running through all the transforms. • Earlier Procedural – Signature says do these steps to verify me . • Now Declarative – Signature says this is what I sign. Verifier decides how to verify. • Impacts the extension mechanism • Earlier a verifier could verify a signature without understanding what it is actually signing, it simply has to execute a different sequence of transforms. • But now it can’t. Extensibility has to be accomplished by adding new property and these properties have to be exchanged out of band.

9. Security (contd) • XML signature 2.0 eliminates all DoS attacks involving loops • Since there are no transforms , the DoS attack of a Signature having 10,000 transforms is not possible any more. • The n2 attack with namespace nodes is eliminated, because “nodeset” is not used any more. • (Suppose an incoming message has ‘n’ elements and ‘n’ namespaces, i.e. total ‘2n’ nodes. XML Signature 1.x will expand this out to ‘n2’ nodes. This is exploited in many DoS attacks). • Another n2 attack with XPath transform is eliminated too, because in XML Signature 2.0, the Included XPath and exluded Xpath is executed only once, not once per node. • (suppose an incoming message has ‘n’ elements. It is easy to contruct an XPath expression that iterates through all the nodes. Since XPath transform’s XPath is executed for every node, this would result in ‘n2’ traversals). • An XPath Filter 2 Transform, could have thousands of Intesect/Union/Subtract XPaths. But in signature 2.0 there are only two include and exclude. • Loops in XSLT are also eliminated because XSLT is disallowed completely.

10. Security (contd) • XML signature 2.0 eliminates the XSLT transform • XSLT can be exploited for many kinds of attacks. • E.g. an XSLT transform can execute code to shutdown the system<xsl:variable name="runtime" select="java:lang.Runtime.getRuntime()"/> <xsl:value-of select="os:exec($runtime, 'shutdown -i')" /> • E.g. an XSLT transform can run a very large loop causing a Dos attack • XML Signature 2.0 also removes the Decrypt Transform • The decrypt transform enabled signatures to be verified even if the order of the operations Sign and Encrypt operations is not known. • In all real uses cases the order of operations is known beforehand, e.g. through a Policy, so decrypt transform is not used in practice. • The other bigger issue is that during decryption there is no check done of what key was used to encrypt the data, what was the strength of the algorithm used to encrypt it etc, decryption just happens as a side effect. This means it insecure. • Decrypt transform also has a performance impact, because after the decryption transform the decrypted data is just passed to the next transform, they are not stored anywhere, So decryption needs to be repeated.

11. Policy Check • XML Signature 2.0 gives a mechanism to find out what was signed. • In XML security 1.x some transforms select data to be signed, and some convert that to bytes, and some transforms do both (.e.g STR-Transform). These transforms can be intermixed in any order. This makes it very hard to determine what is actually signed. • 2.0 has clean separation between “Selection” and “Canonicalization”. • Selection chooses the data to be signed using Ids, XPaths etc. • Canonicalization converts the data to be signed. • A Policy checker can look at the Selection part and figure out what was signed. • This policy check helps prevent “Wrapping attacks” • (E.g. in a WS-Security wrapping attack the Signature it will appear to sign the soap:Body element, but this is not real soap:Body element, but rather another soap:Body element that is squirreled away deep inside some soap:Header )

12. Streaming • Streaming is major goal for XML Signature 2.0 • It should be possible to sign/verify without loading the whole document in memory • Currently web services prefer to work in streaming mode. But many implementations end up converting to DOM just to execute sign/verify operations. This has a very high overhead. • Estimate that streaming will give a 2x-4x boost on software. • For Hardware devices streaming is an absolute most. Most current implementation work with only the subset of XML signature that can be streamed. • The biggest impediment to streaming was XPath. • XML Signature 2.0 describes all operations in terms of “subtrees” instead of XPath “nodesets”. Nodesets are by definition not streamable. • 2.0 also defines a stremable subset of XPath, only XPaths in this subset are allowed. • Note: Streaming does not imply One pass. Some things require “1 ½” passes. • In WS-Security the signature is before the data that is being signed, so obviously one needs to make a second pass to update the signature value.

13. Performance • XML Signature 2.0 has performance improvements for the non streaming implementations too. • Canonicalization is done by simple treewalk instead of iterating over nodeset.The performance of canonicalization should be same as XML serialization. • If you follow the 1.x spec exactly it would be extremely slow. Most mature implementations already do a tree walk, instead of following the spec exactly. So really the spec will be updated to what some implementations are already doing. • Does not do a namespace node expansion • XML Signature 1.x is based on the XPath data model, in which namespace nodes are expanded out – this results in very high memory usage. E.g. if there are O(n) elements and O(m) namespaces, it would use O(n * m) memory. With the new approach it only uses O(n + m). (Again some implementations are already doing this internally. • Does not evaluate XPath multiple times • XPath evaluation is expensive, and in XPath Filter Transform, the XPath needs to be evaluated for every node. XPath Filter 2 Transform solves this problem, but it was not popular as many implementations do not support it, also it has nodeset and namespace issues mentioned above. Signature 2.0 has a very simplfied XPath model. • Does not to automatic nodeset -> binary -> nodeset conversion • In XML Signature 1.x, the transform processing is supposed to do these expensive operations whenever there is an impedance mismatch between one transforms output and the next one’s input. They are no longer applicable for 2.0 • Recommends combining canonicalization and digesting operations.

14. Simplicity • XML signature 2.0 also simplifies many aspects of XML signature • Complex/strange combinations of transforms are gone. Only the simplest and most common use cases are supported. • Any complex XML processing has been pushed outside the scope of the spec – other technology should be used for this. E.g XProc (see http://www.w3.org/TR/xproc/) • There is only way to do XPath, and it is much simpler than either of the XPath transforms. E.g. the XPath Filter 1 Transform:ancestor-or-self::bar:Something and (count(parent::node()/namespace::*) = count(parent::node()/namespace::* | self::node())) • Nodeset has been removed. Nodesets are not only expensive, they are notoriously tricky to implement. There are some complex test vectors that almost no implementation supports.

15. Backward compatibility • XML Signature 2.0 is backwards compatible with 1.x • Every feature that was mentioned as removed in this presentation, is not actually removed, just deprecated. • The declarative syntax is packaged as a new transform, so if a 1.x implementation gets a 2.0 signature, it will fail gracefully. • If instead we had changed the schema, some implementations would give a Runtime error which would be very hard to debug, but with this approach it will give a proper error – “unknown transform”.

16. Summary • XML Signature 2.0 solves many of the problems currently faced, while improving performance • It will take a while to achieve adoption, 1.x is deeply entrenched. • 2.0 versions often do not gain widespread acceptance on their own. E.g XPath 2.0, WSDL 2.0. We need to actively push for adoption. • There may not be a 3.0 at all. With specs, usually you get at most one more chance to fix things, and this is it.