Making Sense of XML Signature
|
The XML Signature specification, developed by the W3C and IETF, expresses the structure of an XML Signature as follows:
Listing 4-1
 |
<Signature> <SignedInfo> (CanonicalizationMethod) (SignatureMethod) (<Reference (URI=)? > (Transforms)? (DigestMethod) (DigestValue) </Reference>)+ </SignedInfo> (SignatureValue) (KeyInfo)? (Object)* </Signature>
|
In the preceding code listing, elements ending in a plus sign may be present multiple times, and elements ending in a question mark are not mandatory. In this section, the various parts of an XML Signature will be encountered and explained. Let’s look at what XML signature is, and what it isn’t.
An XML Signature Is a Digital Signature Expressed in XML
XML Signature isn’t a new way of performing a digital signature. The asymmetric encryption and hashing technologies that we learned about in Chapter 2 are still used to make the actual digital signature.
When evaluating a new technology, it’s frequently useful to compare it with what has gone before. This sets the new technology in context, and we can see why it is useful. Sometimes new XML formats have been said to be “XML for the sake of XML,” and that the addition of angle brackets to a document format is not useful. This is sometimes the case, but not for XML Signature. Let’s see why it is necessary.
Before XML Signature: PKCS#7 Signature and S/MIME
Digital signature technologies existed prior to XML Signature, the most common being PKCS#7 Signature. Public Key Cryptography Standards (PKCS) is a voluntary standard created by RSA Data Security and other information security industry organizations.
Before the advent of XML Signature, it was possible to digitally sign an XML document, treating it just the same as any digital document, using PKCS#7 Signature. However, it wasn’t possible to express the signature in a standardized XML format. Also, it wasn’t possible to sign just part of an XML document, and leave other parts of the document unsigned.
Bindings for digital signatures already existed. In particular, Secure Multipurpose Internet Mail Extensions (S/MIME) provides a means of attaching a digital signature to an e-mail message in such a way that the recipient can verify the integrity and (providing the user’s identity is linked to the signature) nonrepudiation of the signer.
An example of a digitally signed XML document, expressed as an S/MIME message with the signature expressed in PKCS#7 format, is shown here:
Listing 4-2
|
MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="----4566B95511D40A079BBB73F773CC7C0D" This is an S/MIME signed message ------4566B95511D40A079BBB73F773CC7C0D <?xml version="1.0" encoding="UTF-8"?> <bookOrder> <item> <title>Developing Web Applications with string and cardboard</title> <isbn>0-123-45678-9</isbn> <quantity>1</quantity> <price unit="USD">39.95</price> </item> <payment> <billedTo>John Smith</billedTo> <amount currency="USD">39.95</amount> <dueDate>1 January 2003</dueDate> <cardInfo> <cardNumber>1234 5678 9012 3456</cardNumber> <cardExpiration>08/2006</cardExpiration> </cardInfo> </payment> </bookOrder> ------4566B95511D40A079BBB73F773CC7C0D Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIG6wYJKoZIhvcNAQcCoIIG3DCCBtgCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3 DQEHAaCCBFkwggRVMIIDPaADAgECAgEBMA0GCSqGSIb3DQEBBAUAMHoxCzAJBgNV BAYTAklFMQ8wDQYDVQQIEwZEdWJsaW4xETAPBgNVBAcTCER1YmxpbiA0MRQwEgYD VQQKEwtWb3JkZWwgTHRkLjEMMAoGA1UECxQDUiZEMSMwIQYDVQQDExpWb3JkZWwg U2VsZiBTaWduZWQgQ0EgUm9vdDAeFw0wMjA0MTkxMjA0NDRaFw0wMzA0MTkxMjA0 NDRaMGkxCzAJBgNVBAYTAklFMQ8wDQYDVQQIEwZEdWJsaW4xETAPBgNVBAcTCER1 [20 lines omitted for brevity] TC51wSeO+Fi0ieZ3+r1XPAQRbq7FVptkOzbTBCOyZhaklyNIXUs9nBr/lJ5aiHho LRhXwmHbWM/BgJMA2TIV143R5xhGFwTfrR7jRb3OjipkOgTPenaO7+wWdrhvIQ4= ------4566B95511D40A079BBB73F773CC7C0D--
|
Listing 4-2 shows a digitally signed XML document, where XML Signature is
not used. Let’s look at the same-signed XML document, this time with the signature expressed in XML Signature format:
Listing 4-3
|
<bookOrder> <item> <title>Developing Web Applications with string and cardboard</title> <isbn>0-123-45678-9</isbn> <quantity>1</quantity> <price unit="USD">39.95</price> </item> <payment> <billedTo>John Smith</billedTo> <amount currency="USD">39.95</amount> <dueDate>1 January 2003</dueDate> <cardInfo> <cardNumber>1234 5678 9012 3456</cardNumber> <cardExpiration>08/2006</cardExpiration> </cardInfo> </payment> <dsig:Signature Id="" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"> <dsig:SignedInfo> <dsig:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n"> </dsig:CanonicalizationMethod> <dsig:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"> </dsig:SignatureMethod> <dsig:Reference URI=""> <dsig:Transforms> <dsig:Transform Algorithm= "http://www.w3.org/2000/09/xmldsig#enveloped- signature"> </dsig:Transform> </dsig:Transforms> <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"> </dsig:DigestMethod> <dsig:DigestValue>eyaOpi/dmWGQuHlDj6YtFwGFf6g=</dsig:DigestValue> </dsig:Reference> </dsig:SignedInfo> <dsig:SignatureValue> RhiKxqYUw50KtWlKPAxdzfXhPg5vDL/Pvt8VCIs6Ek1UO/1ljeyTkOzI0TEW32+PKvANCrCCpwgb … WIQCIBeXMuHF2gsLd9AW6JNFkkhMh3OHfT4anQ== </dsig:SignatureValue> <dsig:KeyInfo> <dsig:X509Data> <dsig:X509SubjectName> CN=Joe User,OU=Human Resources,O=Company X,L=New York City,ST=NY,C=US </dsig:X509SubjectName> <dsig:X509Certificate> MIIEVTCCAz2gAwIBAgIBATANBgkqhkiG9w0BAQQFADB6MQswCQYDVQQGEwJJRTEPMA0GA1UECBMG [20 lines omitted for brevity] </dsig:X509Certificate> </dsig:X509Data> </dsig:KeyInfo> </dsig:Signature> </bookOrder>
|
With XML Signature, the same cryptographic algorithms may be used. In particular, RSA or DSA and the same message digest algorithm (SHA-1 in this case) can be used. That means that, cryptographically speaking, the digital signature is the same. In terms of the high-level principles of security, both PKCS#7 and XML Signature amount to the same thing. On their own, they provide integrity for data, and when the signer’s identity can be linked to the signature (through an X.509 certificate in this case), they provide nonrepudiation also. In the right circumstances, digital signatures can also be used for authentication.
Replacing ASN.1 Encoding with XML
Look again at the XML Signature example, and compare it to the PKCS#7 signature. In the XML Signature example, the various components of the signature are much more obvious. This is the well-known human-readability advantage of XML. Although people may not look at XML Signature, or indeed any type of XML directly, it is useful for people designing and monitoring systems that use digital signatures. An XML processor (for example, a DOM implementation) is used to parse the XML Signature. In the case of a PKCS#7 signature, ASN.1 was used. ASN.1 is optimized for size and for machine-readability, meaning that a document which uses ASN.1, like a PKCS#7 signature, is unintelligible to humans.
Abstract Syntax Notation 1 (ASN.1) was invented in 1984 and published jointly by the International Standards Organization, the International Electrotechnical Commission, and the International Telecommunications Union. ASN.1 is a collection of techniques and notations for specifying data structures in a machine-independent manner. Token sets defined using ASN.1 can be used in combination with standardized encoding rules such as the basic encoding rules (BER) and the packed encoding rules (PER). ASN.1 is supported by mature tools for encoding and decoding binary information into and out of BER and PER format, as well as to other proprietary encoding formats. ASN.1 is widely deployed in the wireless and fixed-line communications industry as an enabling technology for cell phone messages, radio paging, free and premium phone services, and ISDN telephony. In addition, ASN.1 is used for streaming audio and video over the Internet, and is fundamental to ISO security and messaging standards, including X.509 digital certificates and X.400 e-mail.
Because of its use for X.509 digital certificates, which bind a person’s identity to a public key, ASN.1 continues to be relevant for Web Services security.
Data Transformation
Data transformation is a common feature in XML processing. Interoperability between various XML-enabled systems frequently depends on the existence of an intermediary system that will format the data such that it can be understood by both parties. In the case of XML Signature, it takes on a special significance. As well as being transformed for interoperability between XML systems, signed data may require transformation for the following reasons:
-
The data has been encrypted after being signed, in which case it must be “transformed” using decryption in to the original plaintext before the signature can be verified.
-
The data is large and has been compressed prior to transmission, in which
-
case it must be “transformed” using decompression into the original data.
-
Transformations provide the ability to selectively sign data (for example, “sign all <update> elements”) or ignore certain data (for example, “sign everything except the <Log> elements”).
There is another reason, too, which we will examine in the following section.
Canonicalization
Canonicalization is an arcane word, and its use in Web Services security is made more confusing by the fact that it is often abbreviated to “C14N” (meaning a word beginning with C, ending in N, with 14 letters; this is the same reason why “Internationalization” is sometimes abbreviated to “I18N”). In computer science, the “canonical” way of performing an action is the widely accepted “correct” way of performing that action. The fact that it’s “correct” is only based on consensus, and there may be no particular reason why another method is not used instead, except that the variation would cause confusion and incompatibility. Eric Raymond’s The New Hacker’s Dictionary explains that the word derives from the Greek and Latin word for “reed,” because a particular length of reed was widely accepted as a standard measure.
How does this relate to Web Services? Remember that a digital signature breaks if any change, however minor, occurs to the signed data. XML can change and still be valid XML. Indeed, if an XML process “cleans up” XML by removing useless data such as blank space between XML elements, that breaks the signature. The following lines of XML are both valid for a schema that accepts white space between elements:
<BookOrder> <Title>Hillwalking in Spain</Title> </BookOrder> <BookOrder><Title>Hillwalking in Spain</Title></BookOrder>
An XML processor may have “helpfully” removed the unnecessary white space between the XML elements. This may happen automatically if the XML is inputted by a DOM parser into memory, and then later rendered as XML output. There are many other “helpful” changes that can occur to XML as it travels between XML-processing systems. For example, attributes may be reordered into alphabetical order, line breaks may be added, or the format of line breaks may change. All of these changes break the signature, and it may appear that the data had been maliciously tampered with. Canonicalization addresses this type of false alarm.
Canonicalization involves changing the XML into a canonical format prior to passing it into the digest algorithm, and then changing it into this canonical format prior to recalculating the digest in order to verify the signature. The original algorithm for canonicalization was inclusive canonicalization, referenced by the following URI:
http://www.w3.org/TR/2001/REC-xml-c14n-20010315
The problem with inclusive canonicalization concerns namespaces. If an XML document is digitally signed using XML Signature, namespace declarations in that document are signed also. If the signed document is inserted into another XML document that has new namespaces that are not in the original signed XML document, canonicalization includes these new namespaces in the data that is fed into the digest algorithm used to verify the signature. The namespaces “bleed” into the signed data. The inclusion of these extra namespaces breaks the signature, even though the XML itself is the same.
This problem may sound quite esoteric until we consider SOAP. If signed data is packaged into a SOAP message, the SOAP namespace declarations find their way into the canonicalized XML. This breaks the signature. A subsequent canonicalization method called “exclusive canonicalization” fixes this problem. It is highly recommended that exclusive canonicalization be used in SOAP rather than inclusive canonicalization, for this reason.
Canonicalization was not needed in PKCS#7 signatures because there was not a possibility that ASN.1 data could change and still be valid (except for detached PKCS#7 signatures). Consequently, the PKCS#7 signature previously shown does not use canonicalization.
An XML Signature May Be Placed Inside an XML Document
Looking again at the PKCS#7 signature and the XML Signature, we can see that the XML Signature example inserts the signature into the data itself. This is only one option. In fact, there are three ways in which an XML Signature can relate to the data that is signed. These are enveloped, enveloping, and detached.
Enveloped XML Signature
Enveloped XML Signature means that the signature is contained within the signed document itself. The example we saw earlier in this chapter is an example of an enveloped XML Signature. It is important that the entity verifying the signature uses a transform to remove the signature from the signed document, before feeding the document into the digest algorithm. Otherwise, the signature would break since it obviously did not contain an XML Signature before it was signed.
The transform that is used to remove the XML Signature from the signed data is identified using the following URI: http://www.w3.org/2000/09/xmldsig#enveloped-signature. The functionality of the enveloped signature transform is equivalent to the following XPath statement:
<XPath xmlns:dsig="&dsig;"> count(ancestor-or-self::dsig:Signature | here()/ancestor::dsig:Signature[1]) > count(ancestor-or-self::dsig:Signature) </XPath>
As you can see, it is easier to reference the transform than to construct this XPath transform!
An enveloped signature is a useful form of XML Signature for Web Services. That
is because it allows for signed data to be inserted into SOAP messages, now that the problem of inclusive canonicalization has been cleared up.
It goes without saying that an enveloped signature is only useful for signing XML data, because it requires an XPath transform for validation.
Enveloping XML Signature
With an enveloping XML Signature, the signed data is contained within the XML signature structure itself. An Object tag is used to encapsulate the signed data (which may be XML data or not). Notice in the following example that the Res0 identifier is used in the Reference element in order to point at the Object data that is being signed. Being an enveloping signature, everything is located within the Signature block.
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n20010315"> </CanonicalizationMethod> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"> </SignatureMethod> <Reference URI="#Res0"> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"> </DigestMethod> <DigestValue>SytlSLP6mn+BB4gPF+nyHc4n4Xo=</DigestValue> </Reference> </SignedInfo> <SignatureValue> O9wByjog8R7yhJqaU46PGey7JqEgZ6Azfe9ShaXnRY8jJXEWDMhEBW73gMgYxy+mxDJ9tDZV QohNuKUtJBhsqKl+M/fDEXYUgtfzNjz7WwbjUE/YbNjqyEDFhmwLMb/Iy7gw+tBIM2AqyBoO BciwiLTyP4yEtXAv2oIqadh181g= </SignatureValue> <KeyInfo> <KeyValue> <RSAKeyValue> <Modulus> czG5DqYFMKxINCLVurHW6gHdUxRLf11ikpRMI7+5LGhtyM/QsgMhmX3UNjbG9TtgEO uYBnJCDXJ0364z4gof1oO0OlpNNcaqJ0N1uCqiz1QInQymHL5emzaYVtAiTMa6M5e2 88G8XoY6d4Rbozm/AM7m+6EwLxBpzzYGl/CgtDk= </Modulus> <Exponent>AQAB</Exponent> </RSAKeyValue> </KeyValue> <X509Data> <X509IssuerSerial> <X509IssuerName>CN=John Smith (RSA),OU=TRL,O=IBM,C=JP</X509IssuerName> <X509SerialNumber>1019448261</X509SerialNumber></X509IssuerSerial> <X509SubjectName>CN=John Smith (RSA),OU=TRL,O=IBM,C=JP</X509SubjectName> <X509Certificate> MIIB+TCCAWICBDzDi8UwDQYJKoZIhvcNAQEEBQAwRDELMAkGA1UEBhMCSlAxDDAKBgNVBAoTA0lC [ 8 lines omitted for brevity ] bPpHnYtbdrS1R+aNrBNkjexNzm/dnvp77+zyfI8jn0r5Gx4hcqnu7185i4wUwzQDWgEqKXI= </X509Certificate> </X509Data> </KeyInfo> <dsig:Object xmlns="" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" > <bookOrder> <item> <title>XML and Java: Developing Web Applications, Second Edition</title> <isbn>0-201-77004-0</isbn> <quantity>1</quantity> <price unit="USD">49.99</price> </item> <payment> <billedTo>John Smith</billedTo> <amount unit="USD">49.99</amount> <dueDate>3 June 2002</dueDate> <cardInfo> <cardNumber>1234 5678 9012 3456</cardNumber> <cardExpiration>08/2008</cardExpiration> </cardInfo> </payment> </bookOrder> </dsig:Object> </Signature>
Because an XML instance’s root element typically determines the processing of that data, it would not be sensible to bury a SOAP message inside an enveloping XML Signature. Enveloping XML Signatures can, however, be very useful inside SOAP messages.
Detached Signature
A detached signature is a signature that is separate from the signed entities or entities. This means that the signed data need not be XML at all. Indeed, as the XML Signature specification points out, it can be “any digital content.” An interesting corollary of detached signature processing is that if the URI cannot be dereferenced, meaning that the signed resource is no longer available, then the signature breaks. This means that detached XML Signature may find uses in guaranteeing the integrity of online resources (such as Web pages) against tampering and defacement. This signed data can be referenced using a URI, meaning that it can be located online and is not limited to data that is available locally in files. Looking at the Reference element in the following example, we can see that the W3C XSL specification is being signed:
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"> </CanonicalizationMethod> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"> </SignatureMethod> <Reference URI="http://www.w3.org/TR/xml-stylesheet"> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"> </DigestMethod> <DigestValue>60NvZvtdTB+7UnlLp/H24p7h4bs=</DigestValue> </Reference> </SignedInfo> <SignatureValue> JkWOVRLbGmvvOOBCckzEprh34sN5EvSfGsJYZapqBIbY2AShKVXApADl5UKhEdF4Fey8RVzo 4jOQAFpKwI86NVc3nRtsxj3SfQjpoL1Waf54E4AB04NUi3NvaN2KZb8Yz/3AD7H98fUn/8BB AiLNa0YX1E9yrd14rayzPqlECdc= </SignatureValue> <KeyInfo> <KeyValue> <RSAKeyValue> <Modulus> czG5DqYFMKxINCLVurHW6gHdUxRLf11ikpRMI7+5LGhtyM/QsgMhmX3UNjbG9TtgEO uYBnJCDXJ0364z4gof1oO0OlpNNcaqJ0N1uCqiz1QInQymHL5emzaYVtAiTMa6M5e2 88G8XoY6d4Rbozm/AM7m+6EwLxBpzzYGl/CgtDk= </Modulus> <Exponent>AQAB</Exponent> </RSAKeyValue> </KeyValue> <X509Data> <X509IssuerSerial> <X509IssuerName>CN=John Smith (RSA),OU=TRL,O=IBM,C=JP</X509IssuerName> <X509SerialNumber>1019448261</X509SerialNumber></X509IssuerSerial> <X509SubjectName>CN=John Smith (RSA),OU=TRL,O=IBM,C=JP</X509SubjectName> <X509Certificate> MIIB+TCCAWICBDzDi8UwDQYJKoZIhvcNAQEEBQAwRDELMAkGA1UEBhMCSlAxDDAKBgNVBAoTA0lC TTEMMAoGA1UECxMDVFJMMRkwFwYDVQQDExBKb2huIFNtaXRoIChSU0EpMB4XDTAyMDQyMjA0MDQy MVoXDTAyMDcyMTA0MDQyMVowRDELMAkGA1UEBhMCSlAxDDAKBgNVBAoTA0lCTTEMMAoGA1UECxMD VFJMMRkwFwYDVQQDExBKb2huIFNtaXRoIChSU0EpMIGeMA0GCSqGSIb3DQEBAQUAA4GMADCBiAKB gHMxuQ6mBTCsSDQi1bqx1uoB3VMUS39dYpKUTCO/uSxobcjP0LIDIZl91DY2xvU7YBDrmAZyQg1y dN+uM+IKH9aDtDpaTTXGqidDdbgqos9UCJ0Mphy+Xps2mFbQIkzGujOXtvPBvF6GOneEW6M5vwDO 5vuhMC8Qac82BpfwoLQ5AgMBAAEwDQYJKoZIhvcNAQEEBQADgYEAIUoHZxUdL2/o08/NdJ0wc+6p X7P4lviATr2vIogLY4QiuLJ8g30EC7JMxYoMuGDwFvIWfX+pBvUweoncoQ/WTuPfwjodvR1u9mu7 bPpHnYtbdrS1R+aNrBNkjexNzm/dnvp77+zyfI8jn0r5Gx4hcqnu7185i4wUwzQDWgEqKXI= </X509Certificate> </X509Data> </KeyInfo> </Signature>
XML Signature Allows Multiple Documents to Be Signed
S/MIME allowed for multiple documents, all digitally signed using PKCS#7, to be linked together in one single document. XML Signature goes one step further. Multiple documents can be signed with one single XML Signature. How is this possible? The answer is through the use of references.
Multiple Reference Elements in One SignedInfo Element
The way in which an XML Signature is constructed is clever and efficient. The most processor-intensive aspect of signature generation and signature verification is the use of asymmetric encryption—the RSA and DSA algorithms. By contrast, the calculation of a digest from a piece of data is not as processor-intensive. Therefore, it makes sense to perform asymmetric encryption over as small a portion of data as possible. This extends to the scenario where multiple documents must be signed at once.
The SignedInfo portion of an XML Signature, as the name suggests, contains information about each resource being signed. Each portion of signed data is referred to in a separate Reference. Each Reference includes (1) the digest of the data itself in a DigestValue element, (2) information about what algorithm was used to construct the digest contained in a DigestMethod element, and (3) what transforms, if any, must be performed on the data prior to verifying the digest. Multiple References may be in a single SignedInfo XML element in a digital signature. The computationally intensive asymmetric encryption only takes place over the SignedInfo section.
It is worth noting that information about which signature and canonicalization algorithms are used is also contained in the SignedInfo section. This is important to know, since if this information was subject to undetectable change, this would break the signature. For example, if it were possible to change to the algorithm information in an XML Signature produced by the DSA signing algorithm such that it appeared that the RSA signature algorithm was used instead, the signature would be in dispute.
The various items listed as references may be detached from, enveloped by, or envelope the XML Signature. Because one XML Signature can cover multiple references, a single XML Signature can be, at once, enveloping, enveloped, and detached.
XML Signature Is “XML-Aware Signature”
As we saw in the enveloped signature and enveloping signature examples, XML Signature allows for just a portion of an XML document to be signed. The Reference element can use an XPath transform to point to the signed data. In addition to the basic XPath transform, a second expanded form of the XPath transform, called XML-Signature XPath Filter 2.0, has been developed to increase the usability and efficiency of XML Signature XPath transforms. It can also be used for transforms inexpressible with a basic XPath such as adding a second enveloped signature to a document.
XML Signature is particularly useful for Web Services since it can be used to sign just a single SOAP parameter, for example, and leave volatile (that is, changeable) portions of the SOAP message unsigned. When data is being routed between different services, XML Signature provides a way to ensure that data intended for one service (called an “Actor” in SOAP 1.1 and a “Role” in SOAP 1.2) is not changed by another service.
|
