The next step beyond incorporating a digital signature into an XML document is encrypting the document (or portions of the document). XML encryption extends the power of the XML digital signature system by enabling the encryption of the message that has been signed digitally. The specification outlines a standard way to encrypt any form of digital content and permits encryption of an entire XML message, a partial XML message, or an XML message that contains sections that were previously encrypted.[19]
Here is
PO.xml
with the contents of the
<Items> tag encrypted:
<PurchaseOrder xmlns="urn:oreilly-jaws-samples">
<shipTo country="US">
<name>Joe Smith</name>
<street>14 Oak Park</street>
<city>Bedford</city>
<state>MA</state>
<zip>01730</zip>
</shipTo>
<items>
<EncryptedData Id="ED" Nonce="16"
Type=http://www.w3.org/2001/04/xmlenc#Content
xmlns="http://www.w3.org/2001/04/xmlenc#"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
<EncryptionMethod Algorithm
="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
<ds:KeyInfo>
<ds:KeyName>jaws</ds:KeyName>
</ds:KeyInfo>
<CipherData>
<CipherValue>
dRDdYjYs11jW5EDy0lucPkWsBB3NmK0AFNxvFjfeUKxP75cx7KP0PB3BjXPg14kJv74i7F00XZ5Whq
OISswIkdN/pIVeqRZWqOVjFA8izR6wqOb7UCpH+weoGt0UFOEkIDGbemm23eu812Ob5eYVL8n/DtO8
1OhYeCXksSMGUZiUNj/tfBCAjvqG2jlslQM6n4jJ3QNaR4+B2RisOD6Ln+x2UtNu2J7wIYmlUe7mSg
ZiJ5eHym8EpkE4vjmr2oCWwTUu91xcayZtbEpOFVFs6A==
</CipherValue>
</CipherData>
</EncryptedData>
</items>
<Signature Id="EnvelopedSig" xmlns="http://www.w3.org/2000/09/xmldsig#">
...
</Signature>
</PurchaseOrder>The encrypted part of the document has two new tags:
<EncryptedData>
and
<CipherData>
. The
<EncryptedData> element defines the
encryption scheme to be applied. Here, convenience schemes on the W3C
web site perform the encryption. The
<CipherData> element is created to contain
the encrypted serialization of the <Items>
element. In this example, the result is contained within the
<CipherValue>
element, although as an alternative, you
can use a URI to point to another location where the cipher resides
by using the <CipherReference>
element. The
<EncryptionMethod> and
<KeyInfo> tags are optional. As shown
earlier, it is possible to obtain information about the
sender’s public key through XKMS or other means,
such as PKI.
This ability to encrypt data on an as-needed basis is an incredibly powerful tool that allows web services to provide their own security features. It neatly avoids the limitations encountered when applying external encryption—in particular, the “all or nothing” nature of external encryption.
When
creating the examples used here, we examined a couple of Java
toolkits for XML security:
IBM XML Security Suite and the
Phaos XML
Toolkit. Both were fairly new at the time, but were sufficient enough
to produce these examples. The toolkits both use Xerces and Xalan to
parse the XML data and use their own APIs to assemble the signatures
and encrypt the data. Each has a decent set of sample programs or
utilities for generating a certificate containing a public/private
key pair. Each has examples for creating signed documents using the
enveloped, enveloping, or
detached method. Each has good samples for
encrypting and decrypting portions of a document based on specifying
an element tag. The IBM toolkit uses its own custom parser extensions
so you can use an Xpath expression, such as
/PurchaseOrder/ShipTo, to identify the element to
be encrypted. The Phaos sample simply used parser APIs such as
doc.getElementsByTagName(tagName)
to access the element to be encrypted, as
shown in the following listing:
// Copyright © Phaos Technologies
public class XEncryptTest
{
public static void main (String[] args) throws Exception
{
... // usage, command line args...
// get the XML file and retrieve the XML Element to be encrypted
File xmlFile = new File(inputFileName);
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance( );
dbf.setNamespaceAware(true);
DocumentBuilder db = dbf.newDocumentBuilder( );
Document doc = db.parse(xmlFile);
Element inputElement = null;
NodeList list = doc.getElementsByTagName(tagName);
if (list.getLength( ) != 0)
inputElement = (Element) list.item(0);
else
{
System.err.println("XML element with tagName "
+ tagName + " unidentified.");
System.exit(1);
}
// Create a new XEEncryptedData instance with the owner
// Document of the input xml file,the data type URI and
// the Id "ED" for this EncryptedData element.
XEEncryptedData encData
= XEEncryptedData.newInstance(doc, "ED", dataType);
... // determine encryption algorithm
// set up the EncryptionMethod child element
XEEncryptionMethod encMethod = encData.createEncryptionMethod(algURI);
encData.setEncryptionMethod(encMethod);
// set up the symmetric key to be used in encryption
SymmetricKey key = null;
File keyFile = new File(keyFileName);
... // File stuff
// set up the ds:KeyInfo child element with the keyName
XSKeyInfo keyInfo = encData.createKeyInfo( );
keyInfo.addKeyInfoData(encData.createKeyName(keyName));
encData.setKeyInfo(keyInfo);
// set a nonce value to be prepended to the plain text
byte[] nonce = new byte[16];
encData.setNonce(RandomBitsSource.getDefault( ).randomBytes(nonce));
// encrypt the XML element and replace it with the
// newly generated EncryptedData element
System.out.print("Encrypting the XML data ... ");
XEEncryptedData newEncData
= XEEncryptedData.encryptAndReplace(inputElement, key, encData);
System.out.println("done");
// output the XML Document with the new EncryptedData element to a file
...
}
}The critical piece of this code is the call to
encryptAndReplace( )
. This method does just what its name implies:
it takes the element that we’ve given it (which we
found earlier by calling getElementsByTagName( )),
encrypts it by using the given key, and replaces the original element
with the appropriately tagged, encrypted element.
The Phaos toolkit was much easier to set up and run than the IBM toolkit. All the necessary .jar files were bundled into a single download; the IBM toolkit required downloading a beta version of Xerces, a beta version of Xalan, and a Java Cryptology Extensions ( JCE) toolkit from IBM, Sun, Cryptix, or IAIK. Both toolkits had the sorts of problems that you would expect from a 1.0 or pre-1.0 product, but that situation will probably get better over time. Web services security is a pretty big hole that needs to be filled, and many vendors will have offerings in this area.
Single-sign-on authentication is the ability for an end user or application to access other applications within a secure environment without needing to be validated by each application. The most common example of single-sign-on technology is in web-based corporate intranet applications. In this setting, users want to use various applications that allow access to timesheets, expense reports, 401K plan information, and health benefits. Requiring each application to authenticate each user individually is inconvenient, slow, and limits the value of the intranet site. The best approach is to allow access to all applications without additional intervention after the initial signon, using a profile that defines what the user is allowed to do.
Many companies provide products for web-based, single-sign-on authentication and authorization, including companies such as Netegrity, Securant (now a part of RSA), Oblix, and Verisign. In general, these products use an intermediary process that controls and manages the passing of user credentials from one application to another. Users are assigned a ticket that carries their rights information and simultaneously allows them to access many applications without the need to authenticate each one. This ticket allows applications within the secure environment to shift the burden of authentication and authorization to a trusted third party, leaving the application free to focus on implementation of business logic.
The single-sign-on concept is easily extended to web services. Web services can be given a ticket (placed in an XML/SOAP message) that can be used to validate the service with other web services. However, the secure use of web services will depend on the ability to exchange user credentials on a scale never seen before. Individual services will reside in a variety of protected environments, each using various security products and technologies. Providing a way to integrate these environments and enable their interoperability is critical for the secure and effective use of these services.
Recognizing the need to provide an interoperable, single-sign-on specification for web services, the industry leaders in this market have come together to create the adoption of a standard. Based on XML, the Security Assertion Markup Language (SAML) is an almost complete specification proposed by the Organization for the Advancement of Structured Information Standards (OASIS). The primary goal of SAML is to enable interoperability between different systems that provide security services. The SAML specification does not define new technology or approaches for authentication or authorization. Rather, it defines a common XML language that describes the information or outputs generated by these systems. A completed SAML draft is expected by early 2002. OASIS will accept specifications for approval during the second quarter of 2002. In the meantime, Microsoft and Sun Microsystems are both working on competing systems that will offer the same capabilities, but are platform-specific.
Many single-sign-on vendors have already released toolkits based on early versions of SAML, with promises for free upgrades once the specification is complete. The first to market was Netegrity, with the release of the JSAML Toolkit to build Java-based applications that use SAML. This toolkit allows Java-based web services to incorporate single-sign-on solutions that work with other SAML-based security environments. It is available for free from their web site.
One of the biggest challenges for deploying all these new encryption, digital signature, and authentication technologies will be to keep all public and private keys, digital signatures, and digital certificates organized and secure. Several PKI products currently on the market are designed to simplify the management of these security components. However, there is still no standard way to access these systems in a SOAP-based web services environment.
The XML Key Management Specification (XKMS) is an emerging effort under the auspices of the W3C. It aims to provide standardized XML-based transaction definitions for the management of authentication, encryption, and digital signature services. XKMS is designed to complement and enhance the XML Digital Signature and XML Encryption standards already emerging at the W3C, not compete with them. As discussed in a previous section, the XML Encryption and XML Digital Signature specifications describe how to use and incorporate encryption keys and digital certificates. However, these specifications assume that the web service responsible for processing the XML exists in an environment where keys and certificates are kept safe and secure. It also assumes that the web service programmer knows which certificates and keys to use.
XKMS will provide a standardized set of XML definitions that allow developers to have a trusted third party locate and provide the appropriate keys and certificates. This trusted third party will act as an intermediary that frees the web service programmer from having to track the availability of keys or certificates and ensure their validity.
In short, XKMS will provide a standardized set of XML definitions that allow developers to use remote trusted third-party services that provide encryption and decryption services, and the creation, management, and authentication of keys and digital signatures. The specification maps a set of tags that can be used to query external key management and signature validation services and a set of tags for these services to use when sending responses. For example, a client might ask a remote service to answer questions such as, “Is this certificate valid?” or, “I have a reference to a key that you are allegedly managing . . . what is its value?” The next section provides an overview of some of these requests and responses.
XKMS provides a simple retrieval
method for obtaining a decryption key from a remote source. This
retrieval method relies on the use of the
<RetrievalMethod>
tag within the
<KeyInfo>
element, as defined by XML-SIG. The
following document assumes that a service exists that can provide
information about a given key:[20]
<ds:KeyInfo>
<ds:RetrievalMethod
URI="http://www.PKeyDir.test/CheckKey"
Type="http://www.w3.org/2000/09/xmldsig#X509Certificate"/>
</ds:KeyInfo>This lookup is very simple and does not require the service to enforce the validity of the key it returns.
The
location service defines a set of tags
that an application client uses to query a remote service for
information about a public key. For example, if a web service client
wants to encrypt something based on the value of the
recipient’s public key, it first needs to contact
the key location service to obtain that key. The following listing
shows the <Locate>
,
<Query>, and
<Respond> tags used in the request:
<Locate> <Query> <ds:KeyInfo> <ds:KeyName>Alice Cryptographer</ds:KeyName> </ds:KeyInfo> </Query> <Respond> <string>KeyName</string> <string>KeyValue</string> </Respond> </Locate>
The <Query> tag provides the name of the
requested key, and the <Respond> element
lists the items that the client would like to know about. The
response looks like this:
<LocateResult> <Result>Success</Result> <Answer> <ds:KeyInfo> <ds:KeyName>Alice Cryptographer</ds:KeyName> <ds:KeyValue>Some key value</ds:KeyValue> </ds:KeyInfo> </Answer> </LocateResult>
The Validate Service is a trusted third party that validates a binding between a key and an attribute such as a name. For instance, given the following query:
<Validate>
<Query>
<Status>Valid</Status>
<ds:KeyInfo>
<ds:KeyName>...</ds:KeyName>
<ds:KeyValue>...</ds:KeyValue>
</ds:KeyInfo>
</Query>
<Respond>
<string>KeyName</string>
<string>KeyValue</string>
</Respond>
</Validate>the Validate Service would produce the following results:
<ValidateResult>
<Result>Success</Result>
<Answer>
<KeyBinding>
<Status>Valid</Status>
<KeyID>http://www.xmltrustcenter.org/assert/20010120-39</KeyID>
<ds:KeyInfo>
<ds:KeyName>...</ds:KeyName>
<ds:KeyValue>...</ds:KeyValue>
</ds:KeyInfo>
<ValidityInterval>
<NotBefore>2000-09-20T12:00:00</NotBefore>
<NotAfter>2000-10-20T12:00:00</NotAfter>
</ValidityInterval>
</KeyBinding>
</Answer>
</ValidateResult>In the previous listing, the
<Result>
and <Status>
elements have different meanings. The Success
indicated by the <Result> element simply
indicates that the request was processed successfully by the service.
The <Status> indicates the results of the
processing—in this case, the result is
Valid. The optional
<ValidityInterval>
information shows the timespan for
which the Validate Service’s results are considered
valid. Digital certificates and keys are not unconditionally valid;
they can be (and frequently are) assigned a specific time limit,
after which they expire and are no longer valid. In addition, XKMS
also defines requests and responses for the following areas:
- Key registration
How to register your key information with a third-party KMS.
- Key revocation
How to send a request to the third-party KMS to tell it that you no longer want it to manage the key on your behalf.
- Key recovery
You forgot your private key. How to send a request to obtain it and what the response looks like. The specification does not dictate the rules under which the private key should be returned. For instance, it may be the policy of the service to revoke the old key and issue a new one. However, that decision is up to the policy of the individual provider.
Verisign is one of the primary drivers of XKMS. They have already released a Java toolkit that supports XKMS development. To download the product, visit http://www.xmltrustcenter.org/xkms/download.htm.