Home arrow Security arrow Page 20 - Safeguarding the Identity and Integrity of XML Messages

Security Strategies for XML Signature - Security

XML Signature and XML Encryption, two of the three major pillars of the WS-Security standard, are so predominant in current thinking about Web Services Security that some people mistake them as the only strategy for securing Web services. This is really not the case at all. Read more in this chapter from Securing Web Services with WS-Security, by Rosenberg and Remy (ISBN 0672326515, SAMS, 2004).

  1. Safeguarding the Identity and Integrity of XML Messages
  2. XML Signature Fundamentals
  3. XML Signature Structure
  4. Types of XML Signatures
  5. The Signature Element Schema
  6. XML Signature Processing
  7. XML Signature Validation
  8. The XML Signature Elements
  9. Canonicalization Actions from Canonical XML Version 1.0
  10. The SignatureMethod Element
  11. The Reference Element
  12. The Transform Element
  13. XPath Filtering Transform
  14. Enveloped Signature Transform
  15. XPath Filter 2.0 Transform
  16. The DigestMethod Element
  17. The Object Element
  18. The Manifest Element
  19. The KeyInfo Element
  20. Security Strategies for XML Signature
  21. Summary
By: Sams Publishing
Rating: starstarstarstarstar / 7
September 09, 2004

print this article



XML Signature, just like any security strategy, is effective only if it is used correctly within the context and constraints of the situation. It is effective in certain areas but can be inappropriate in others. The following sections describe some security considerations when you are using XML Signatures.

Using Transforms

Perhaps the scariest aspect of XML Signatures, at least when you come from a traditional digital signature perspective, is the concept that you can change (transform) the information being signed in a hidden way (by an algorithmic process) before it is digitally signed. This capability seems to go against the assumptions about fundamental integrity on which digital signatures are based. However, as we discussed earlier when talking about Transforms, there are completely legitimate reasons for using a Transform algorithm, such as when you need to Base-64 encode a binary object or remove a signature when creating/validating an Enveloped Signature. The XML Signature working group was concerned enough about the security issues around Transforms to call out three specific principles to consider when using Transforms in XML Signatures.

Only What Is Signed Is Secure

The principle "only what is signed is secure" seems obvious, but the point is that when a Transform is involved, you must be extra diligent to understand what the Transform does and to understand that the discarded information is not digitally signed. For example, in a Web services scenario, if an XML Signature has signed the XML payload, only the XML payload is secured, not the SOAP envelope information.

Only What Is Seen Should Be Signed

If a user's judgment or consent is being conveyed by the signature, every practical effort should be made to sign what a user has seen. For example, if a contract being signed (showing intent) has been rendered to the signer as XML with an XSL stylesheet, both the XML and the XSL stylesheet should be signed. In general, implementers should adhere to the principle of What You See Is What You Sign (WYSIWYS).

"See" What Is Signed

The idea behind the principle "see what is signed" is that you should make sure you are working with (seeing) what was actually signed. Making presumptions about the signature is risky. You should run the actual Reference URI and Transforms and work with the output to be sure. For example, you may know that a signature is supposed to contain a certain field, such as an amount. If Transforms are involved (and they always are when you consider canonicalization of the SignedInfo element), you cannot be positive that that field's integrity has been validated unless you run the Reference URI/Transform algorithms and then access the field's contents from the result.

Knowing the Security Model

In the context of our discussion, the term security model means the set of assumptions and constraints associated with a particular security or cryptographic strategy. For example, XML Signature supports both public key signatures and keyed hashed authentication codes (such as HMAC).

We discussed the security model around public key signatures in Chapter 3. The main point here to remember is that public key signatures are associated with identity and integrity.

Keyed hashed authentication codes, such as HMAC, are shared key based. They tend to run much faster than public key signatures, but they are primarily associated with integrity, not identity.

XML Signatures can and will be extended over time to include other types of algorithms and techniques. If you choose one of these approaches, it is critical that you understand the underlying security model well.

Knowing Your Keys

Key management is a fundamental issue of cryptography whether it is public key or shared key oriented. It is critical (and challenging) that you protect the private keys that are used for signing and confirm that the keys you are using for validation are valid, not revoked, and represent the identity that you expect them to represent.

Signing Object Elements

XML Signature processing does not automatically sign Object elements within a Signature element. If you want an element signed, you must create a Reference and point specifically to the Object element. This point is obvious when you are creating an Enveloping Signature, but it may seem less obvious when you are adding a SignatureProperties or Manifest element. Most of the time, you will want these elements signed. For example, if you add a "Time of Signature" property to a SignedProperties element, you usually want to add a Reference to it; otherwise, why would you provide this information to the verifier and potentially have it tampered with?

Signing DTDs with Entity References

One of the key capabilities of DTDs is keeping entity references that are resolved for you at XML parse time. For example, say you have a DTD that contains the following entity references:

<!ENTITY companyname "CompanyA">
<!ENTITY companylocation "Chicago, IL">

Then you receive a signed XML document representing an order commitment for $1,000,000 that was signed by Company A like Listing 4.29.

Listing 4.29 An <OrderCommittment> Document Signed by Company A

<?xml version="1.0"?>
<!DOCTYPE ordercommittment SYSTEM "ordercommittment.dtd">
  <CommittedItem type="cash" denom="USD">$1,000,000</CommittedItem>
      <CanonicalizationMethod ... />
      <SignatureMethod ... />
      <Reference URI="">
      <DigestMethod ... />

Notice that the signature is an Enveloped Signature that signs everything under the OrderCommittment element. Because the Reference URI is "", the entire document includes the <?xml and <!DOCTYPE lines; however, the DTD itself has not been signed. Notice that the DTD has a relative address. So, imagine that an attacker—say, from Company B—substituted a different DTD file into the same directory as the XML containing the following entity references:

<!ENTITY companyname "CompanyB">
<!ENTITY companylocation "Pendleton, NJ">

In this case, the signature is validated even though different values appear in the CompanyName and CompanyLocation elements of the XML document! And Company B will receive the $1,000,000 because of it. The point is: Signing DTDs is very important when entity references are being used.

Entity references are not a problem with XML Schemas because schemas do not have the same entity reference capability; however, a similar problem can occur with default values. It is a good idea to include a Reference to the XML Schema for the same reasons you would sign DTDs.

SOAP Security Extensions: An Initial Stab at Web Services Security - In February 2001, Microsoft and IBM submitted a W3C Note regarding the use digital signatures in SOAP messages (see http://www.w3.org/TR/SOAP-dsig/). This precursor to WS-Security defines a standard way to put an XML Signature into the header of a SOAP message. For example, a signed SOAP message would look like Listing 4.30 using this method.

Listing 4.30 Early Use of Digital Signatures in SOAP

  <SOAP-SEC:Signature xmlns:SOAP-SEC="..."
   <ds:Signature xmlns:ds="...">
     <ds:SignatureMethod Algorithm="..."/>
     <ds:Reference URI="#Body">
       <ds:Transform Algorithm="..."/>
      <ds:DigestMethod Algorithm="..."/>
  xmlns:SOAP-SEC="..." SOAP-SEC:id="Body">
  <m:GetLastTradePrice xmlns:m="some-URI">

You will not see this standard in much use today; it never went past the W3C Note stage. However, it is used in some situations, and it had a significant influence on the later WS-Security standard.

SamsThis chapter is from Securing Web Services Security with WS-Security, by Jothy Rosenberg and David Remy (Sams, 2004, ISBN: 0672326515). Check it out at your favorite bookstore today.

Buy this book now.

>>> More Security Articles          >>> More By Sams Publishing

blog comments powered by Disqus
escort Bursa Bursa escort Antalya eskort


- Secure Your Business for Data Privacy Day
- Google Testing Security Fob Password Alterna...
- Security News Highlights Concerns
- Going to Extremes for Data Security
- Skipfish Website Vulnerability Scanner
- Critical Microsoft Visual Studio Security Pa...
- US Faces Tech Security Expert Deficit
- LAN Reconnaissance
- An Epilogue to Cryptography
- A Sequel to Cryptography
- An Introduction to Cryptography
- Security Overview
- Network Security Assessment
- Firewalls
- What’s behind the curtain? Part II

Developer Shed Affiliates


Dev Shed Tutorial Topics: