XML Signature 2.0

Timelines 2002 – XML Signature – XML Signature 1.0, 2 nd edition –Adds support for Canonicalization 2009 end – XML Signature 1.1 –Adds support for Elliptic Curve algorithms required for 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.

Primary goals Robustness Reduce security attack surface Streaming & Performance Simplicity Backward compatibility See draft specs –Signature 2.0: –Canonicalization 2.0

Robustness Simplifies creating interoperable implementations –Deals with difficult Whitespace issues Any change in whitespace causes the signature to break. It is popular misconception that canonicalization takes care of whitespace. It doesnt ! 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. –Enhances default Namespace handling Change in the prefix value breaks the signature. E.g is not considered the same as 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.

Robustness (contd) How 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 and will be converted to 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 with XML Schema to native object translation (data bindings). –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

Security XML Signature 1.x flexibility increases attack surface –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 Denial of Service attacks – complex XPath and XSLT Wrapping attacks – what is signed is not evident Cross site scripting attacks – gain elevated access privileges

Security (contd) XML Signature is used in a variety of security models 1.Client Server messaging. –E.g. in Web services, SAML, ebXML, remote Portlets etc. –The server checks the signature in clients 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.) 2.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.)

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 TRANSFORMS. –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. 1.x: Procedural – Signature says do these steps to verify me. 2.0: Declarative – Signature says this is what I sign. Verifier decides how to verify. –Impacts the extension mechanism 1.x: a verifier could verify a signature without understanding what it is actually signing, it simply has to execute a different sequence of transforms. 2.0: it cant. Extensibility has to be accomplished by adding new property and these properties have to be exchanged out of band.

Security (contd) XML signature 2.0 eliminates 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 n 2 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 n 2 nodes. This is exploited in many DoS attacks). –Another n 2 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 transforms XPath is executed for every node, this would result in n 2 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.

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

Determine what was signed 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 )

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 streamable subset of XPath, only XPaths in this subset are allowed. –Note: Streaming does not necessarily imply only one pass. 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.

Performance XML Signature 2.0 has performance improvements for the non streaming implementations too. –Canonicalization can be implemented by simple tree walk 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 can result 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 simplified 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 ones input. They are no longer applicable for 2.0 –Recommends combining canonicalization and digesting operations.

Simplicity XML Signature 2.0 also simplifies many aspects of XML signature –Signature 2.0 identifies the most common transform cases and provides a simple declarative means of using them. 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 –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.

Backward compatibility XML Signature 2.0 is backwards compatible with 1.x –XML Signature 2.0 defines new mechanisms using the 1.x syntax –Though not described, 1.x mechanisms can still be used if absolutely necessary. –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.

Summary XML Signature 2.0 offers many improvements, including simplicity, performance, streamability, and reduced attack surface. XML Signature 2.0 is a major update to XML Signature based on experience with XML Signature 1.0. Adoption will take time.