An Introduction to XML Digital Signatures

Introduction

Current security technologies in common deployment are insufficientfor securing business transactions on the Web. Most existingbrowser-based security mechanisms, generally adequate for low-valuebusiness-to-consumer transactions, do not provide the enhancedsecurity or flexibility required for protecting high-value commercialtransactions and the sensitive data exchanges that comprise them.

For instance, Secure Sockets Layer (SSL) provides for the secureinterchange of sensitive data between a browser and Web server, butonce received, the data is all too frequently left unprotected on theserver. In fact, SSL protects the data at a point in its travels whenits confidentiality is, relatively speaking, far less likely to beattacked. If you were a hacker, which would you think is a betterapplication of your time: sniffing IP packets in transit in order toobtain a single user's credit card number or breaking into a back-enddatabase containing thousands of credit card numbers? This problem isaggravated in the case where a message is routed from server toserver. If the data itself were encrypted, as opposed to just itstransport, it would help reduce the incidents of unencrypted data leftvulnerable on public servers.

Table of Contents

An Introduction to Public Key Cryptography

Introduction to XML Signatures

The Components of an XML Signature

How to Create an XML Signature

Verifying an XML Signature

As important as protecting the confidentiality of business messagesis ensuring their long-term authenticity (who sent them?), dataintegrity (have they been modified in transit?), and support fornon-repudiation (can the sender deny sending them?); in other words,functionality that ubiquitous, existing Internet security technologies(e.g., SSL and username/password) do not provide alone. Theglobally-recognized method for satisfying these requirements forsecure business transactions is to use digital certificates to enablethe encryption and digital signing of the exchanged data. A briefintroduction to these concepts is provided below. The term "publickey infrastructure" (PKI) is used to describe the processes, policies,and standards that govern the issuance, maintenance, and revocation ofthe certificates, public, and private keys that the encryption andsigning operations require.

The very features that make XML so powerful for businesstransactions (e.g., semantically rich and structured data, text-based,and Web-ready nature) provide both challenges and opportunities forthe application of encryption and digital signature operations toXML-encoded data. For example, in many workflow scenarios where an XMLdocument flows stepwise between participants, and where a digitalsignature implies some sort of commitment or assertion, eachparticipant may wish to sign only that portion for which they areresponsible and assume a concomitant level of liability. Olderstandards for digital signatures provide neither syntax for capturingthis sort of high-granularity signature nor mechanisms for expressingwhich portion a principal wishes to sign.

Two new security initiatives designed to both account for and takeadvantage of the special nature of XML data are XML Signature and XMLEncryption. Both are currently progressing through the standardizationprocess. XML Signature is a joint effort between the World Wide WebConsortium (W3C) and Internet Engineering Task Force (IETF), and XMLEncryption is solely W3C effort. This article presents a briefintroduction to the XML Signature specification and the underlyingcryptographic concepts.

An Introduction to Public Key Cryptography

Public key cryptography allows users of an insecure network, likethe Internet, to exchange data with confidence that it will be neithermodified nor inappropriately accessed. This is accomplished through atransformation of the data according to an algorithm parameterized bya pair of numbers -- the so-called public and private keys. Eachparticipant in the exchange has such a pair of keys. They make thepublic key freely available to anyone wishing to communicate withthem, and they keep the other key private and protected. Although thekeys are mathematically related, if the cryptosystem has been designedand implemented securely, it is computationally infeasible to derivethe private key from knowledge of the public key.

The nature of the relation between the public and private keys issuch that a cryptographic transformation encoded with one key can onlybe reversed with the other. This defining feature of public keyencryption technology enables confidentiality because a messageencrypted with the public key of a specific recipient can only bedecrypted by the holder of the matching private key (i.e., therecipient, if they have properly protected access to the private key).Even if intercepted by someone else, without the appropriate privatekey, this third party will be unable to decrypt the message. It'scrucial that confidentiality can be supported without requiring thatthe sender and recipient exchange any "secret" data in addition to themessage itself, as is the case in symmetric cryptography. Indeed itwas precisely the requirement of key exchange between sender andrecipient, which quickly becomes impractical as the number ofparticipants increases, that motivated the invention of public-keycryptography.

Although confidentiality is typically the first aspect ofcryptography that comes to mind, the special relationship betweenpublic and private keys also enables functionality that has noparallel in symmetric cryptography; namely, authentication (ensuringthat the identity of the sender can be determined by anyone) andintegrity (ensuring that any alterations of the message content can beeasily spotted by anyone). These new features and, through them,support for non-repudiation (ensuring the origin or delivery of datain order to protect the sender against false denial by the recipientthat the data has been received or to protect the recipient againstfalse denial by the sender that the data has been sent) provideelectronic messages with a mechanism analogous to signatures in thepaper world, that is, a digital signature.

To create a digital signature for a message, the data to be signedis transformed by an algorithm that takes as input the private key ofthe sender. Because a transformation determined by the sender'sprivate key can only be undone if the reverse transform takes as aparameter the sender's public key, a recipient of the transformed datacan be confident of the origin of the data (the identity of thesender). If the data can be verified using the sender's public key,then it must have been signed using the corresponding private key (towhich only the sender should have access).

For signature verification to be meaningful, the verifier must haveconfidence that the public key does actually belong to the sender(otherwise an impostor could claim to be the sender, presenting herown public key in place of the real one). A certificate, issued by aCertification Authority, is an assertion of the validity of thebinding between the certificate's subject and her public key such thatother users can be confident that the public key does indeedcorrespond to the subject who claims it as her own.

Largely due to the performance characteristics of public-keyalgorithms, the entire message data is typically not itselftransformed directly with the private key. Instead a small uniquethumbprint of the document, called a "hash" or "digest", istransformed. Because the hashing algorithm is very sensitive to anychanges in the source document, the hash of the original allows arecipient to verify that the document was not altered (by comparingthe hash that was sent to them with the hash they calculate from thedocument they received). Additionally, by transforming the hash withtheir private key, the sender also allows the recipient to verify thatit was indeed the sender that performed the transformation (becausethe recipient was able to use the sender's public key to "undo" thetransformation). The hash of a document, transformed with the sender'sprivate key, thereby acts as a digital signature for that document andcan be transmitted openly along with the document to therecipient. The recipient verifies the signature by taking a hash ofthe message and inputting it to a verification algorithm along withthe signature that accompanied the message and the sender's publickey. If the result is successful, the recipient can be confident ofboth the authenticity and integrity of the message.

Introduction to XML Signatures

XML signatures are digital signatures designed for use in XMLtransactions. The standard defines a schema for capturing the resultof a digital signature operation applied to arbitrary (but often XML)data. Like non-XML-aware digital signatures (e.g., PKCS), XMLsignatures add authentication, data integrity, and support fornon-repudiation to the data that they sign. However, unlike non-XMLdigital signature standards, XML signature has been designed to bothaccount for and take advantage of the Internet and XML.

A fundamental feature of XML Signature is the ability to sign onlyspecific portions of the XML tree rather than the completedocument. This will be relevant when a single XML document may have along history in which the different components are authored atdifferent times by different parties, each signing only those elementsrelevant to itself. This flexibility will also be critical insituations where it is important to ensure the integrity of certainportions of an XML document, while leaving open the possibility forother portions of the document to change. Consider, for example, asigned XML form delivered to a user for completion. If the signaturewere over the full XML form, any change by the user to the defaultform values would invalidate the original signature.

An XML signature can sign more than one type of resource. Forexample, a single XML signature might cover character-encoded data(HTML), binary-encoded data (a JPG), XML-encoded data, and a specificsection of an XML file.

Signature validation requires that the data object that was signedbe accessible. The XML signature itself will generally indicate thelocation 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 (thesignature is a sibling);
• be embedded within the XML signature (the signature is theparent);
• have its XML signature embedded within itself (the signatureis the child).

The Components of an XML Signature

How to Create an XML Signature

Here is a quick overview of how to create an XML signature; pleaserefer to theXML Signaturespecification for additional information.

1. Determine which resources are to be signed.

This will take the form of identifying the resources through aUniform 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 theidentified resource and not the<Reference> elementitself) is placed in a <DigestValue> child elementlike

<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 tocalculate 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 thealgorithm was used to canonize the<SignedInfo>element. Different data streams with the same XML information set mayhave different textual representations, e.g. differing as towhitespace. To help prevent inaccurate verification results, XMLinformation sets must first be canonized before extracting their bitrepresentation for signature processing. The<SignatureMethod> element identifies the algorithmused 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>MC0E LE=</SignatureValue>

5. Add key information

If keying information is to be included, place it in a<KeyInfo> element. Here the keying informationcontains the X.509 certificate for the sender, which would include thepublic 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=Ed Simon,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:

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

2. 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 electronicbusiness infrastructure, we need trustable, secure XML messages toform the basis of business transactions. One key to enabling securetransactions is the concept of a digital signature, ensuring theintegrity and authenticity of origin for business documents. XMLSignature is an evolving standard for digital signatures that bothaddresses the special issues and requirements that XML presents forsigning operations and uses XML syntax for capturing the result,simplifying its integration into XML applications.