SCDJWS Study Guide: XML Security


Printer-friendly version Printer-friendly version | Send this 
article to a friend Mail this to a friend


Previous Next vertical dots separating previous/next from contents/index/pdf Contents

XML Digital Signature


Introduction


Digital signatures are important because they provide end-to-end message integrity guarantees, and can also provide authentication information about the originator of a message. In order to be most effective, the signature must be part of the application data, so that it is generated at the time the message is created, and it can be verified at the time the message is ultimately consumed and processed.

SSL/TLS also provides message integrity (as well as message privacy), but it only does this while the message is in transit. Once the message has been accepted by the server (or, more generally, the peer receiver), the SSL protection must be "stripped off" so that the message can be processed. As a more subtle point, SSL only works between the communication endpoints.

An XML signature would define a series of XML elements that could be embedded in, or otherwise affiliated with, any XML document. It would allow the receiver to verify that the message has not been modified from what the sender intended.

Digital Signature

Digital Signatures are a standard in security and cryptography for applications, and are becoming more widespread in their use.

A Digital Signature is a cryptographic piece of data that is attached to a plaintext or encrypted message to verify the identity of the sender. The Digital Signature is meant to provide assurance to the receiving user (end user) that what it is they are working with is unaltered or has its original integrity. Digital Signatures also fulfill an important non-repudiation function, allowing us to identify the author of the message to which the signature is attached.

Basic Cryptography

Cryptography is the most popular mechanism for protecting digital documents exchanged across the wire between two parties involved in confidential business transactions.

The basic concept of cryptography is illustrated as follows:

  1. A sender application uses high-speed mathematical algorithms to transform a given piece of data to a complicated combination of digits and numbers just before transmission. The algorithms employed are so complex that it is impossible to reproduce the original data from this resulting chunk.
  2. This meaningless chunk of data is then transmitted across the wire. If any unintended recipients can intercept the communications, they will be able to read only this chunk (from which nothing can be derived), not the original data.
  3. On the receiving end, premeditated reverse transforms are applied in order to decipher the data chunk. The sender has to ensure that only the indented recipients are empowered with reverse transforms.

The transformation process applied at the sender's end is known as encryption; the process at the receiver's end is known as decryption.

Over the years, several famous algorithms that can achieve very high levels of security have evolved. Many of these algorithms use specific combinations of numbers and digits—called keys—during the encryption/decryption process. Information encrypted by using specific keys can be decrypted only by using corresponding key pairs. This enables the reuse of same encryption algorithms across different applications.

XML Digital Signature

XML Signatures contain a series of XML elements and attributes that define various components that are needed to sign an XML document more securely. This includes information about the location of the XML document to be signed, the algorithm used for signing, and information about the key used for signing.

An important feature of XML Signature is the ability to sign only specific portions of the XML tree rather than the complete document. In another words, it has the ability to have multiple digital signatures contained within one XML document. A single XML document may have a long history in which the different components are authored at different times by different parties, each signing only those elements relevant to itself. This flexibility will also be critical in situations where it is important to ensure the integrity of certain portions of an XML document, while leaving open the possibility for other portions of the document to change.

An XML signature can sign more than one type of resource. For example, a single XML signature might cover character-encoded data (HTML), binary-encoded data (a JPG), XML-encoded data, and a specific section of an XML file. Signature validation requires that the data object that was signed be accessible. The XML signature itself will generally indicate the location of the original signed object. This reference can be:

  • Referenced by a URI within the XML signature;
  • Reside within the same resource as the XML signature (the signature is a sibling);
  • Be embedded within the XML signature (the signature is the parent);
  • Have its XML signature embedded within itself (the signature is the child).

Adding a digital signature to an XML document helps ensure that the data contained in the document is more secure, and that the identity of the person who signed the XML document can be verified.

XML Signatures are applied to arbitrary digital content (data objects) via an indirection. Data objects are digested, the resulting value is placed in an element (with other information) and that element is then digested and cryptographically signed.

Basically, an XMLdsig is comprised of four main components or elements: <SignedInfo>, <SignatureValue>, <KeyInfo> and <Object>. The <SignedInfo> element includes all of the content or resources to be signed with each item having a corresponding <Reference> element, which identifies the content and a digest over it. The <Reference> elements are digested and cryptographically signed in a manner similar to signing when using a standard digital signature. The resulting signature value is stored in the <SignatureValue> element. The <KeyInfo> and <Object> elements are optional.

An XML Dsig has the <Signature> element as the root element for its XML tree. It contains the four main components and has the following generic structure as defined in the specification, where “?” denotes zero or one occurrences, “*” denotes zero or more occurrences, and “+” denotes one or more occurrences”:



Signatures are related to data objects via URIs. Within an XML document, signatures are related to local data objects via fragment identifiers. Such local data can be included within an enveloping signature or can enclose an enveloped signature. Detached signatures are over external network resources or local data objects that reside within the same XML document as sibling elements; in this case, the signature is neither enveloping (signature is parent) nor enveloped (signature is child). Since a Signature element (and its Id attribute value/name) may co-exist or be combined with other elements (and their IDs) within a single XML document, care should be taken in choosing names such that there are no subsequent collisions that violate the ID uniqueness validity constraint.

Simple example:

<Signature Id="MyFirstSignature" xmlns="http://www.w3.org/2000/09/xmldsig#">
  <SignedInfo>
    <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
    <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>
    <Reference URI="http://www.w3.org/TR/2000/REC-xhtml1-20000126/">
      <Transforms>
        <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
      </Transforms>
      <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
      <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue>
    </Reference>
  </SignedInfo>
   
  <SignatureValue>MC0CFFrVLtRlk=...</SignatureValue>

  <KeyInfo>
    <KeyValue>
      <DSAKeyValue>       
      <P>...</P><Q>...</Q><G>...</G><Y>...</Y>
      </DSAKeyValue>
    </KeyValue>
  </KeyInfo>
</Signature>

The required SignedInfo element is the information that is actually signed. Core validation of SignedInfo consists of two mandatory processes: validation of the signature over SignedInfo and validation of each Reference digest within SignedInfo. Note that the algorithms used in calculating the SignatureValue are also included in the signed information while the SignatureValue element is outside SignedInfo.

The CanonicalizationMethod is the algorithm that is used to canonicalize the SignedInfo element before it is digested as part of the signature operation. Note that this example is not in canonical form.

The SignatureMethod is the algorithm that is used to convert the canonicalized SignedInfo into the SignatureValue. It is a combination of a digest algorithm and a key dependent algorithm and possibly other algorithms such as padding, for example RSA-SHA1. The algorithm names are signed to resist attacks based on substituting a weaker algorithm. To promote application interoperability we specify a set of signature algorithms that MUST be implemented, though their use is at the discretion of the signature creator. We specify additional algorithms as RECOMMENDED or OPTIONAL for implementation; the design also permits arbitrary user specified algorithms.

Each Reference element includes the digest method and resulting digest value calculated over the identified data object. It also may include transformations that produced the input to the digest operation. A data object is signed by computing its digest value and a signature over that value. The signature is later checked via reference and signature validation.

KeyInfo indicates the key to be used to validate the signature. Possible forms for identification include certificates, key names, and key agreement algorithms and information - we define only a few. KeyInfo is optional for two reasons. First, the signer may not wish to reveal key information to all document processing parties. Second, the information may be known within the application's context and need not be represented explicitly. Since KeyInfo is outside of SignedInfo, if the signer wishes to bind the keying information to the signature, a Reference can easily identify and include the KeyInfo as part of the signature.


XML Digital Signature Elements


The <Signature> Element


<element name="Signature" type="ds:SignatureType"/>
  
<complexType name="SignatureType">
    <sequence>
        <element ref="ds:SignedInfo"/>
        <element ref="ds:SignatureValue"/>
        <element ref="ds:KeyInfo" minOccurs="0"/>
        <element ref="ds:Object" minOccurs="0" maxOccurs="unbounded"/>
    </sequence> 
    <attribute name="Id" type="ID" use="optional"/>
</complexType>
 

The <Signature> element is the top-level element in an XML Signature tree. It has information about what is being signed, the signature, the keys used to create the signature, and a place to store arbitrary information.

This element identifies a complete XML Signature within a given context. This parent element can contain a sequence of children as follows: <SignedInfo>, <SignatureValue>, <KeyInfo>, and <Object>. Note that the last two elements are optional. Two things are important about the <Signature> element.

First, an optional Id attribute can be added as an identifier. This is useful in the case of multiple <Signature> instances within a single file or context. The global Id attribute allows a document to contain multiple signatures, and provides a way to identify particular instances. Multiple signatures are common in business policies, such as when both the manager and the Travel Office must approve a trip application.

Secondly, the <Signature> element must be laxly-schema valid to its constraining schema definition. This type of validity is related to a best-effort attempt at schema validation.

The <SignedInfo> Element

The next element in the sequence is the <SignedInfo> element. The content of <SignedInfo> element can be divided into two parts, information about the <SignatureValue>, and information about the application content, as we can see from the following XML Schema fragment:

<element name="SignedInfo" type="ds:SignedInfoType"/>
  
<complexType name="SignedInfoType">
    <sequence>
      <element ref="ds:CanonicalizationMethod"/>
      <element ref="ds:SignatureMethod"/>
      <element ref="ds:Reference" maxOccurs="unbounded"/>
    </sequence> 
    <attribute name="Id" type="ID" use="optional"/>
</complexType>

This element is the most complex element (it has the most children) and ultimately contains a reference to every data object that is to be included in the signature. As the name implies, <SignedInfo> encompasses all the information that is actually signed; that is, the signed information. The content of <SignedInfo> includes a sequence of the following elements: < CanonicalizationMethod>, < SignatureMethod>, and one or more <Reference> elements. The < CanonicalizationMethod> and < SignatureMethod> elements describe the type of canonicalization algorithm and signature algorithm used in the generation of the <SignatureValue>. These two elements simply contain identifiers; they do not actually point to any data used in signature generation. These identifiers must be included as part of the <SignedInfo> to prevent against substitution attacks. For example, if the <SignatureMethod> element were explicitly defined outside the <SignedInfo> element, an adversary could modify the signature method identifier and wreak havoc with someone trying to properly validate the signature.

Another interesting and important element is the <Reference> element.References define the actual data that we are signing. Most of the added features of XML Signatures show up in the definition and usage of < Reference> elements.

The <SignatureValue> Element

This element contains the actual signature. As signatures are always binary data, XML DSIG specifies that the signature value is always a simple element with Base64-encoded content. 

<element name="SignatureValue" type="ds:SignatureValueType"/>
 
<complexType name="SignatureValueType">
     <simpleContent>
        <extension base="base64Binary">
            <attribute name="Id" type="ID" use="optional"/>
        </extension>
     </simpleContent>
</complexType>
 

The <KeyInfo> Element

Following <SignatureValue> is the optional <KeyInfo> element. The <KeyInfo> element is a powerful element that allows for the integration of trust semantics within an application that utilizes XML Signatures.

<element name="KeyInfo" type="ds:KeyInfoType"/>
   
<complexType name="KeyInfoType" mixed="true">
    <choice maxOccurs="unbounded">    
      <element ref="ds:KeyName"/>
      <element ref="ds:KeyValue"/>
      <element ref="ds:RetrievalMethod"/>
      <element ref="ds:X509Data"/>
      <element ref="ds:PGPData"/>
      <element ref="ds:SPKIData"/>
      <element ref="ds:MgmtData"/>
      <any processContents="lax" namespace="##other"/>
      <!-- (1,1) elements from (0,unbounded) namespaces -->
    </choice>
    <attribute name="Id" type="ID" use="optional"/>
</complexType>

Simply put, a <KeyInfo> element contains specific information used to verify an XML Signature. The information can be explicit, such as a raw public key or an X.509 certificate, or the information can be indirect and specify a remote public-key information source. <KeyInfo> is a powerful element because it allows a recipient to verify the signature without having to explicitly hunt for the verification key. This feature is useful for automating signature verification, but this type of element can also be dangerous. This element moves the problem of trust away from the signature syntax and into the domain of the application. An application that is receiving the signature must know how to make proper trust decisions based on any included <KeyInfo> material. A receiving application must know when to trust material inside <KeyInfo> and when to discard it. Without explicit trust semantics, any XML Signature with a proper <KeyInfo> element will successfully verify, giving the recipient little reason to trust the sender.

One way to manage trust in an application that relies on XML Signatures is to delegate to a trust engine that takes as input a <KeyInfo> element and makes a trust decision based on its contents.

 

XML Signature Forms

There are three types of XML digital signatures:

  • Enveloped - The signature is contained within the document it is signing
  • Enveloping - The signed document is contained within the signature element
  • Detached - The signature references a document that is else where through a universal resource identifier (URI).

These are just the basic forms; remember, those “one or more” and “zero or more” sections of the specification. An XML digital signature can not only sign more than one document, but it could also be simultaneously more than one of the enveloped, enveloping, and detached forms.

“Detached” means that the signed data is not in the signature element - it is elsewhere in the XML document or in some remote location. "The signature and signed data are detached from one another."

“Enveloping” means that the signed data is in the signature element. "The signature is enveloping the signed data." The signature is the parent tag of the URI reference.

“Enveloped” means that the signature is part of the signed data.  "The signature is enveloped by the signed data." The signature is a child tag of the URI reference.

  1. Enveloped Form

    An enveloped signature is useful when you have a simple XML document which you to guarantee the integrity of. For example, XKMS messages can use enveloped signatures to convey "trustable" answers from a server back to a client.

    The signature is over the XML content that contains the signature as an element. The content provides the root XML document element. Obviously, enveloped signatures must take care not to include their own value in the calculation of the SignatureValue.

    Signature is enveloped within the content been signed:

    <doc Id="myID">
        <myElement>
            ......
        </myElement>
                   
        <Signature>
             ...
           <Reference URI="#myID"/>
             ...
        </Signature>
    </doc>

  2. Enveloping Form

    An enveloping signature is useful when the signing facility wants to add its own metadata (such as a timestamp) to a signature - it doesn't have to modify the source document, but can include additional data covered by the signature within the signature document it generates. (An XML Digital Signature can sign multiple objects at once, so enveloping is usually combined with another format).

    The signature is over content found within an Object element of the signature itself. The Object (or its content) is identified via a Reference (via a URI fragment identifier or transform).

    Signature envelopes the contents to be signed:

    <Signature>
         ...
        <Reference URI="#myRefObjectID">
             ...
        </Reference>
     
        <Object Id="myRefObjectID">
           <doc>                                               
              <myElement>
                  ...              
              </myElement>
              ...
           </doc>
        </Object>                               

    </Signature>

  3. Detached Form

    A detached signature is useful when you can't modify the source; the downside is that it requires two XML documents - the source and its signature - to be carried together. In other words, it requires a packaging format - enter SOAP headers.

    The signature is over content external to the Signature element, and can be identified via a URI or transform. Consequently, the signature is "detached" from the content it signs. This definition typically applies to separate data objects, but it also includes the instance where the Signature and data object reside within the same XML document but are SIBLING elements.

    Signature is external to the content that is signed:

    <Signature>
          ...
        <Reference URI="http://www.buy.com/books/purchaseWS"/>
          ...
    </Signature>

 

How to Create an XML Signature

Here is a quick overview of how to create an XML signature; please refer to the XML Signature specification for additional information.

  1. Determine which resources are to be signed.

    This will take the form of identifying the resources through a Uniform Resource Identifier (URI).

    • "http://www.abccompany.com/index.html" would reference an HTML page on the Web
    • "http://www.abccompany.com/logo.gif" would reference a GIF image on the Web
    • "http://www.abccompany.com/xml/po.xml" would reference an XML file on the Web
    • "http://www.abccompany.com/xml/po.xml#sender1" would reference a specific element in an XML file on the Web

  2. Calculate the digest of each resource.

    In XML signatures, each referenced resource is specified through a <Reference> element and its digest (calculated on the identified resource and not the <Reference> element itself) is placed in a <DigestValue> child element like

    <Reference URI="http://www.abccompany.com/news/2000/03_27_00.htm">
     <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
     <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue>
    </Reference> 

    <Reference URI="http://www.w3.org/TR/2000/WD-xmldsig-core-20000228/signature-example.xml">
     <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
     <DigestValue>UrXLDLBIta6skoV5/A8Q38GEw44=</DigestValue>
    </Reference>

    The <DigestMethod> element identifies the algorithm used to calculate the digest.

  3. Collect the Reference elements

    Collect the <Reference> elements (with their associated digests) within a <SignedInfo> element like

    <SignedInfo Id="foobar">
     <CanonicalizationMethod  Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
     <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1" />
     <Reference URI="http://www.abccompany.com/news/2000/03_27_00.htm">
      <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
      <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue>
     </Reference>
     <Reference  URI="http://www.w3.org/TR/2000/WD-xmldsig-core-20000228/signature-example.xml">
      <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
      <DigestValue>UrXLDLBIta6skoV5/A8Q38GEw44=</DigestValue>
     </Reference>
    </SignedInfo>

    The <CanonicalizationMethod> element indicates the algorithm was used to canonize the <SignedInfo> element. Different data streams with the same XML information set may have different textual representations, e.g. differing as to whitespace. To help prevent inaccurate verification results, XML information sets must first be canonized before extracting their bit representation for signature processing. The <SignatureMethod> element identifies the algorithm used to produce the signature value.

  4. Signing

    Calculate the digest of the <SignedInfo> element, sign that digest and put the signature value in a <SignatureValue> element.

    <SignatureValue>MC0ELE=</SignatureValue>

  5. Add key information

    If keying information is to be included, place it in a <KeyInfo> element. Here the keying information contains the X.509 certificate for the sender, which would include the public key needed for signature verification.

    <KeyInfo>
     <X509Data>
       <X509SubjectName>CN=Ed Simon,O=XMLSec Inc.,ST=OTTAWA,C=CA</X509SubjectName>
       <X509Certificate>MIID5jCCA0+gA...lVN</X509Certificate>
     </X509Data>
    </KeyInfo>

  6. Enclose in a Signature element

    Place the <SignedInfo>, <SignatureValue>, and <KeyInfo> elements into a <Signature> element. The <Signature> element comprises the XML signature.

    <?xml version="1.0" encoding="UTF-8"?>
    <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
      <SignedInfo Id="foobar">
       <CanonicalizationMethod  Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
         <SignatureMethod  Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1" />

         <Reference URI="http://www.abccompany.com/news/2000/03_27_00.htm">
          <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
          <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue>
         </Reference>
         <Reference  URI="http://www.w3.org/TR/2000/WD-xmldsig-core-20000228/signature-example.xml">
          <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
          <DigestValue>UrXLDLBIta6skoV5/A8Q38GEw44=</DigestValue>
         </Reference>
      </SignedInfo>
      <SignatureValue>MC0E~LE=</SignatureValue>
      <KeyInfo>
       <X509Data>
        <X509SubjectName>CN=EdSimon,O=XMLSec Inc.,ST=OTTAWA,C=CA</X509SubjectName>
        <X509Certificate>MIID5jCCA0+gA...lVN</X509Certificate>
       </X509Data>
      </KeyInfo>
     
    </Signature>


    Verifying an XML Signature

    A brief description of how to verify an XML signature:

    • Verify the signature of the <SignedInfo> element. To do so, recalculate the digest of the <SignedInfo> element (using the digest algorithm specified in the <SignatureMethod> element) and use the public verification key to verify that the value of the <SignatureValue> element is correct for the digest of the <SignedInfo> element.
    • If this step passes, recalculate the digests of the references contained within the <SignedInfo> element and compare them to the digest values expressed in each <Reference> element's corresponding <DigestValue> element.

    Conclusion

    As XML becomes a vital component of the emerging electronic business infrastructure, we need trustable, secure XML messages to form the basis of business transactions. One key to enabling secure transactions is the concept of a digital signature, ensuring the integrity and authenticity of origin for business documents. XML Signature is an evolving standard for digital signatures that both addresses the special issues and requirements that XML presents for signing operations and uses XML syntax for capturing the result, simplifying its integration into XML applications.

    Reference

    http://home.comcast.net/~fjhirsch/xml/xmlsec/starting-xml-security.html

    http://java.boot.by/wsd-guide/

    http://www.webservicesarchitect.com/content/articles/hankison03.asp

    http://www.google.com/search?hl=en&lr=&oi=defmore&q=define:digital+signature

    http://www.syngress.com/book_catalog/224_hack_xml/sample.pdf

    http://www.perfectxml.com/om/XMLSecurity.PDF

    http://www.w3.org/TR/xmldsig-core/#sec-Signature

     

     



Previous Next vertical dots separating previous/next from contents/index/pdf Contents

  |   |