A brief overview of Web security
As more and more companies use XML to transmit structured data across the Web, the security of documents becomes increasingly important. The World Wide Web Consortium (W3C) and the Internet Engineering Task Force (IETF) are currently defining an XML vocabulary for digital signatures. The Tokyo Research Lab has created the XML Security Suite, a prototype implementation of the XML signature specification. The XML Security Suite, available from IBM’s alphaWorks, contains utilities to automatically generate XML digital signatures.
When sending secure data across the Web, you need four things:
- Confidentiality — No one else can access or copy the data.
- Integrity — The data isn’t altered as it goes from the sender to the receiver.
- Authentication — The document actually came from the purported sender.
- Nonrepudiability — The sender of the data cannot deny that they sent it, and they cannot deny the contents of the data.
SSL provides the first three functions; the XML Security Suite provides the fourth.
Creating a secure session
There are several steps involved in creating a secure session:
- The secure server obtains a certificate from the appropriate certificate authority (CA).
- The secure server sends its public key to the client.
- The client uses the server’s public key to encrypt a premaster secret (a random number generated by the client. The phrase premaster secret sounds much more sophisticated than random number). The server uses its private key to decrypt the premaster secret.
- The server generates a new key based on the premaster secret. The key is known to the server, and can only be decrypted and used by the client that generated the premaster secret.
This process creates a session in which all traffic between the client and server is encrypted. Only the server and the client can decrypt each other’s data. Confidentiality, integrity, and authentication are covered. SSL doesn’t address nonrepudiability, however; if I have a document on my system, you can deny that you ever sent it, or you can deny that you created the content that’s currently in the document. Nonrepudiability is one of the functions provided by the XML Security Suite.
The XML Security Suite
The XML Security Suite provides several important functions:
- XML signatures. This implementation is based on the XML-Signature Core Syntax and Processing specification currently being developed by the World Wide Web Consortium (W3C) and the Internet Engineering Task Force (IETF). (See Resources.)
- An implementation of the W3C’s Canonical XML working draft. (See Resources.)
- Element-level encryption.
The following sections discuss each of these functions and how they contribute to Web security.
The W3C and the IETF are currently working together on a proposal for XML-based digital signatures. The proposal defines a
<signature> element that contains all the information needed to process a digital signature. Each digital signature refers to one of three things:
- An XML element contained inside the
- An external XML document, referenced by a URI
- An external non-XML resource, referenced by a URI
Examples in this article show you how to create each of these resources. See the latest draft of the XML Signature proposal (see Resources) if you’d like to read all the gory details.
Color-coding our colorful coding
Let us know what you think about these new and improved code listings.
If you’d like to do this kind of thing yourself, see Resources for the appropriate links.
To illustrate how XML Signatures work, I generated a signature file called
signature.xml for the Shakespearean sonnet used for so many of my XML examples. (View it in HTML; you can also download this file.)
In the signature file, the signed element is the sonnet, contained inside the
<dsig:Object> element. The actual signature is contained in the
<SignatureValue> element, with the signer of the document indicated in the
About the sample programs
Several sample programs illustrate the various functions of the XML Security Suite. If you want to follow along with the sample programs discussed here, there are several files you need. See Resources for information on where to get these files.
- The XML Security Suite itself Add both
xss4j.jarand the path
- A Java 2 Development Kit, Version 1.2 or higher Make sure that this is the default JDK for your system.
mail.jarfile from the JavaMail package Add this file to your
- An implementation of the Java Cryptography Extension A list of cryptographic service providers can be found at the Sun Web site. To avoid export complications, the examples here use OpenJCE, a free, open-source library. The file
jce.zipis added to the classpath.
- Version 2 of IBM XML Parser for Java Version 3.0.1 The file
xml4j.jarmust be in your classpath.
Creating a certificate
Before you can create digital signatures, you need a certificate. Although you can get a certificate from a certificate authority, for the examples here, you’ll act as your own CA. To create the X.509 certificate used in
signature.xml, use the Java 2
keytool command, the distinguished name (dname) is composed of the common name (CN), organizational unit (OU), organization (O), location (L), state (S), and country (C). The distinguished name is designed to be unique across the Internet. The password for the key store
openstds is the password for the private key for this certificate
xss4j is the alias for this certificate
Signing an internal XML resource
To create digital signatures, use the SampleSign application. This application is shipped with the XML Security Suite, and is found in the
xss4j/samples directory. Our first signature will be for an internal XML resource. This means that the digital signature and the XML resource are all in the same file. Here’s how
sonnet.xml is signed to generate
(BTW, this command was entered as a single line.)
Notice that the alias, private key password, and key store password are the same as from Listing 1, the
keytool command. Also notice the use of the
file: URL instead of a simple filename, and that the output is piped (using the > operator) into the file
signature.xml. The results of this command are the document shown in
Signing an external XML resource
Signing an external XML resource means that the
<Signature> document contains the URI of the XML resource, not the resource itself. To create this kind of digital signature, use the
This produces a document similar to
signature.xml, except the actual XML document is not contained in the
Signing a non-XML resource
The final signing example creates a digital signature for a non-XML resource. In this example, use a GIF file that contains the developerWorks logo:
To create a digital signature, use the
Verifying a digital signature
The XML Security Suite provides a utility, SampleVerify, that verifies a digital signature. You can check a given signature to ensure that the signed resource has not changed, and you can check that the signature matches the information in the sender’s certificate. If a signature is valid, Listing 5 shows the results you’ll get:
If you change the signed file, the signature will no longer be valid. To illustrate this, add a blank space to the end of one of the <line> elements. Change
<line>My mistress' eyes are nothing like the sun,</line> to
<line>My mistress' eyes are nothing like the sun, </line>.
When we check the signature again, Listing 6 shows the results:
Because the changed XML document doesn’t match the digital signature, you know not to trust the document. (If someone other than the original document signer had tried to pass themselves off as the creator of the digital signature, the SignedInfo message would have indicated that.)
The joys of nonrepudiability
The main benefit of digital signatures is that they provide nonrepudiability. If you send me a signed document, I know that you’re the one who sent it, because the signature contains your public key. In addition, because the signature is based on the contents of the document, the signature won’t match if any changes have been made to the document.
The simplest form of something (Merriam-Webster’s Collegiate Dictionary, Online Edition)
To calculate the digital signature, you need a common way to represent all XML documents. You can use the W3C’s Canonical XML standard for this.
Even though two XML documents may not be identical, they may be equivalent for the purposes of an XML application. Consider the following two elements:
If you do a simple string comparison on these two elements, they’re obviously not the same. From an XML processing perspective, though, they’re equivalent. According to the XML 1.0 Recommendation, the order of attributes is not significant. Other insignificant differences between XML source documents are the amount of white space between attributes, and whether attributes with default values were actually included in the source document. To solve this problem, the W3C is currently defining a canonical form for XML documents.
The XML Security Suite provides an XML Canonicalizer utility, a prototype implementation of the W3C’s emerging standard for Canonical XML. To convert an XML document to its canonical form, use one of the following two commands:
The C14nDOM application uses a DOM parser, while the C14nSAX application uses a SAX parser. Although you can use these applications to generate the canonical form of an XML document, they are primarily used by the XML signature code. (BTW, the c14n abbreviation means that canonicalization is spelled beginning with a c, has 14 letters, and ends with an n. You’ll often see internationalization similarly written as i18n.)
Because the XML Signature code uses canonicalization to generate digital signatures, you can make certain changes to the original document without affecting the validity of the digital signature. As an example, add some white space inside a tag. Change the line:
After you make this change, run the SampleVerify application again to make sure the digital signature is still valid:
Even though the document is different, the differences aren’t semantically significant. Because the XML Security Suite uses the canonical form of the XML documents, the semantically insignificant differences are ignored.
One of the strong points of XML is that you can choose element names so that marked-up documents are much more readable. For example, look at a customer order in XML in Listing 10. (You can also download this file.)
There are three sections to the document, an
element that lists all the items ordered by the customer, a
element that contains information about the customer, and a
element that describes the credit card used to pay for this order. (Note to apprentice cyberthieves: The information above is not, in fact, my credit card number. If you are able to purchase goods and services using this information, please let me know.)
When early Internet users were reluctant to use credit cards to shop online, many e-business proponents pointed out that all credit card purchases have a level of risk. I commonly give my credit card to a waiter in a restaurant; I trust that my card won’t be used for anything other than the meal I’ve just eaten. Likewise, when I buy something online, I’m trusting the merchant not to use my credit card for unauthorized purchases.
With the element-level encryption feature of the XML Security Suite, you could encrypt the sensitive information so that even the merchant couldn’t see it. The merchant would pass the encrypted information on to the credit card processing agency, which would have the proper keys to decrypt the sensitive information. This would enable a greater level of security than the typical transactions of today.
To demonstrate element-level encryption, I’ve slightly modified the
CipherTest.java file that ships with the XML Security Suite. (Here is the source for the modified file.) I’ll review the changes I made, then illustrate how element-level encryption works.
The first change I made to
CipherTest.java was to import the OpenJCE libraries, then define the ABAProvider class as a cryptography provider:
Instead of calling the java.security.Security.addProvider method, you could modify the
java.security file (in
JavaHome/lib/security), replacing this line:
with this one:
The only other change is to modify the code so that it will encrypt any
To illustrate this function, run CipherTest against the original XML file. The CipherTest application uses a password on the command line:
shown in Listing 14. (You can also download this file.)
In the encrypted XML document, the
element is replaced by an
element. Nothing in the document indicates how many elements are encrypted, the names of the encrypted elements, or the structure or sequence of those elements. To preserve the security of the encrypted document, we don’t use a
declaration in our source document. The encrypted document wouldn't follow the DTD, and including any reference to it would indicate the structure of the encrypted elements. If you do encrypt an XML document with a
declaration, the decryption process won't work. (The error message you'll get won't help you much; it'll say,
java.lang.NullPointerException at CipherTest.main(CipherTest.java:83), or something equally useless.)
To restore the original document, use the
-d (decrypt) option instead of the
-e (encrypt) option. Be sure the password you use is the same.
This restores the encrypted file to its original state. Be aware that element-level encryption uses Canonical XML, so the restored file may not have the exact same syntax as the original. Any differences that do appear will not be semantically significant, however.
The XML Security Suite provides two other utilities, an ASN.1-to-XML translator and a variety of DOMHASH tools. The ASN.1-to-XML translator automatically translates between ASN.1 data (such as X.509 certificates and LDAP data) and XML. (See Resources for information about ASN.1.) DOMHASH is an algorithm that generates a unique hash value for a given node in an XML document tree. The DOMHASH tools included with the XML Security Suite calculate hash values for given nodes, and provide a suite of DOMHASH test tools.
The XML Security Suite provides a variety of functions that enhance the security of XML documents. All of these technologies can be used with existing Web security. As the exchange of XML documents becomes increasingly important, the technologies in the XML Security Suite will provide vital security functions. Best of all, these technologies are based on open, emerging standards, and they work on any Java-enabled platform. If you’re curious to see the kinds of security technologies the world will be using in the very near future, the XML Security Suite is definitely worth a look.