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-xmldsi
  g-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 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 .
• _
• The other major reason is namespaces
• Change in the prefix value breaks the signature.
  E.g ltsoapBodygt is not considered the same as
  ltsBodygt 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
  ltsoapEnvelopegt and ltsEnvelopegt will be
  converted to ltn1Envelopegt
• Prefixes that are embedded in content are also
  changed. The most common place is the xsitype
  attribute. E.g. if the original value of xsitype
  was xsdstring, 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.xs flexibility leads to
  vulnerability.
• A signature has a set of Transforms to convert
  from XML -gt 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 -gt 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-bestpra
  ctices/
• 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 lt-gt 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.)
• 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 cant. 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
  transforms 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 systemltxslvariable name"runtime"
  select"javalang.Runtime.getRuntime()"/gt
  ltxslvalue-of select"osexec(runtime,
  'shutdown -i')" /gt
• 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 soapBody
  element, but this is not real soapBody element,
  but rather another soapBody element that is
  squirreled away deep inside some soapHeader )

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

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 Transformancestor-or-selfba
  rSomething and (count(parentnode()/name
  space) count(parentnode()/namespac
  e selfnode()))
• 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.