LANGUAGES: All .NET Languages
ASP.NET VERSIONS: All
XML Security Standards
By Don Kiely
Because XML is proliferating applications both on the Internet and the workstation, there are many initiatives under way to apply security technologies to XML data. In this article and the next, I'll cover a couple of the initiatives that are in various states of development to make XML more secure: XML Signature and XML Encryption.
A common way to protect data, dating back long before XML took over the world, was to attach an encrypted signature to a set of data. The data might be encrypted as well, but that wasn't necessary. The idea is that the signature would encrypt identity information about the person signing the data, as well as some sort of hash or checksum of the data. If the data is changed, the encrypted hash would no longer match a hash generated from the changed data. Mathematically, this is almost impossible to defeat.
To make digital signatures more usable with XML, the W3C is developing the XML-Signature Syntax and Processing specification, commonly called XML Signature, or just XML-Sig. You can use digital signatures with any kind of data, including XML, so why a special specification? The reason is because of the different ways to write XML so that, as far as an XML parser is concerned, the data is exactly equivalent. For example, take these two lines of code:
Both forms indicate that the <SpitzBlat> element has no content, and a parser doesn't parse either any differently from the other. However, hashes made from the two lines will be completely different. Yet the data is the same. Whitespace differences cause the same kind of problems. Digital signatures weren't created to handle these kinds of variations in data.
So XML Signature defines both an XML syntax to use when attaching a signature to XML data, as well as ways of normalizing the structure of the data. Another specification from the W3C, Canonical XML, describes a normalization scheme for XML that allows reliable signing.
Here is an example of an XML signature, detached from the data that it protects (with only a subset of the encrypted data to save space):
This XML signature contains several parts, some of which are optional depending on the usage:
- The <CanonicalizationMethod> element defines which of several canonicalization algorithms was used to normalize the data. Implementations of XML Signature must support some required algorithms, and the spec provides for use of other algorithms.
- The <SignatureMethod> element provides information about the encryption methods used for the signature, and will vary so that the consuming application will know how to decrypt the signature.
- The <DigestMethod> element specifies the method used to create what is usually a hash of the XML data being protected. Most of the time this will be the SHA1 method defined by the US government, because that is the only method that an XML Signature implementation must support. The <DigestValue> element contains the actual digest value.
- The actual digital signature is contained within the <SignatureValue> element.
- If you need to include any additional information, such as a timestamp or serial number of cryptographic hardware used for encryption, you can include a <SignatureProperties> element.
XML signatures provide integrity, message authentication, and/or signer authentication services for data of any type, whether located within the XML that includes the signature, or elsewhere.
Don Kiely is senior technology consultant for Information Insights, a business and technology consultancy in Fairbanks, AK. E-mail him at mailto:[email protected].