|HOME >> Introduction to XML|
An introduction to XML encryption and XML signature
XML is a major enabler of what the Internet, and latterly Web services, require in order to continue growing and developing. Yet a lot of work remains to be done on security-related issues before the full capabilities of XML languages can be realised. At present,encrypting a complete XML document, testing its integrity, and confirming the authenticity of its sender is a straightforward process. But it is increasingly necessary to use these functions on parts of documents, to encrypt and authenticate in arbitrary sequences, and to involve different users or originators. At present, the most important sets of developing specifications in the area of XML-related security are XML encryption, XML signature, XACL, SAML, and XKMS. This article introduces the first two.
XML has become a valuable mechanism for data exchange across the Internet. SOAP, a means of sending XML messages, facilitates process intercommunication in ways not possible before, while UDDI seems to be fast becoming the standard for bringing together providers and users of Web services; the services themselves are described by XML in the form of WSDL, the Web Services Description Language. Without XML, this flexibility and power would not be possible and, as various people have remarked, it would be necessary to invent the metalanguage.
The other area of rapid growth is that of security. Traditional methods of establishing trust between parties aren't appropriate on the public Internet or, indeed, on large LANs or WANs. Trust mechanisms based on asymmetric cryptography can be very useful in such situations, but the ease of deployment and key management, the extent of interoperability, and the security offered are, in reality, far less than the enthusiastic vendors of different Public Key Infrastructures (PKI) would have us believe. There are particular difficulties in dealing with hierarchical data structures and with subsets of data with varying requirements as to confidentiality, access authority, or integrity. In addition, the application of now standard security controls differentially to XML documents is not at all straightforward.
bodies are actively involved in examining the issues and in developing
standards. The main relevant developments here are XML encryption and
the related XML signature, eXtensible Access Control Language (XACL),
and the related Security Assertion Markup Language (SAML -- a blending
of the formerly competing AuthML and S2ML). Each of these is driven
by OASIS, and XML Key Management Specification (XKMS). This article
introduces XML encryption and XML signature.
As with general encryption, there's no problem in digitally signing an XML document as a whole. However, difficulty arises when parts of a document need to be signed, perhaps by different people, and when this needs to be done in conjunction with selective encryption. It may not be possible or desirable to mandate a particular sequence of sectional encryption by specified people acting in order, yet successful processing of the different parts of the document will depend on knowing this. Further, as a digital signature asserts that a certain private key has been used to authenticate something, it's prudent that a signer view the item to be signed in plain text, and this may mean decrypting part of something already encrypted for other reasons. In other cases, data that is already encrypted may be encrypted further as part of a larger set. The more the different possibilities are considered in sets of transactions involving a single XML document -- perhaps a Web form or a series of data records used in a workflow sequence, processed by a number of different applications and different users -- the more the huge potential complexity can be seen.
There are additional problems, as well. One of the strengths of XML languages is that searching is clear and unambiguous: The DTD or schema provides information as to the relevant syntax. If a document subsection, including tags, is encrypted as a whole, then the ability to search for data relevant to those tags is lost. Further, if the tags are themselves encrypted, then, being known, they may be useful as material for mounting plain text attacks against the cryptography employed.
These are some of the areas that the working groups are considering.
The encryption working draft gives examples of how the granularity of encryption may differ according to different requirements and what the consequences might be. The code fragment in Listing 1 shows an unencrypted XML document with credit card and other personal information. In some cases (for example, concealing information on payment mechanisms) it may be desirable to encrypt everything other than the customer name, and the code fragment in Listing 2 shows how this can be done.
Listing 1. Information
on John Smith showing his bank, limit of $5,000, card number, and expiration
Listing 2. Encrypted
document where everything other than the name is encrypted
In yet other cases, it might only be necessary to conceal some sensitive content -- perhaps from a merchant or other third party -- and Listing 3 shows this. (Note that the tag name relevant to the encrypted content is shown.)
Listing 3. Encrypted
document with only the credit card number hidden
It might also be necessary to encrypt all information in the document and Listing 4 shows this.
Listing 4. Encrypted document with the complete contents hidden
The CipherData element can either envelop or reference the raw encrypted
data. In the first case, that raw data is shown by the contents of the
CipherValue element, while in the second a CipherReference element is
used, and this encloses a URI which points to the location of the encrypted
is particularly important so far as encryption and, more specifically,
digital signing are concerned because it's clearly necessary that textual
variants that have no logical change implications should not suggest
that the integrity of a document or the authentication of its sender
is suspect. This is something that might otherwise happen as a result
of different treatment by different tools (such as parsers) generating
different texts and, in turn, different message digests. Hence, during
both signature generation and validation computing, the message digest
should be done on the canonical form. If the digests match, then this
confirms that the canonical forms over which they were computed also
match, even though the textual forms may differ.
Listing 5. Example of a simple detached signature
information that is actually signed is that between lines s02 and s12,
the SignedInfo element. Reference to the algorithms used in calculating
the SignatureValue element is included within the signed section while
that element itself is outside the signed section, on line s13. The
SignatureMethod reference on line s04 is to the algorithm used to convert
the canonicalized SignedInfo into the SignatureValue. It's a combination
of a key-dependent algorithm and a digest algorithm, here DSA and SHA-1,
possibly with other manipulation such as padding. The KeyInfo element
(here lines s14 to s16 -- this element is optional) indicates the key
that's used to validate the signature.
The example below, taken from that document, shows how the recipient of a document can be advised as to the proper order of decryption and signature verification. The first fragment shows the part of the document to be signed, the order element; within this, the personal and financial details of the cardinfo element, lines 7 to 11, are in clear text but some encrypted data is already present (line 12).
Listing 6. Order element within an XML document
 <order Id="order">
Listing 7. Order document after signing and further encrypting and now showing transform information
The Signature element, lines 1 to 26, now includes the previous order
element, lines 16 to 24, with its earlier plain text cardinfo element
encrypted and shown in the single line 22. There are two transform references:
decryption (lines 6 to 8) and canonicalization (line 9). The decryption
transform instructs the signature verifier to decrypt all the encrypted
data except for the one specified on line 7 in the DataRef element.
After the EncryptedData element in line 22 is decrypted, the order element
is canonicalized and the signature duly verified.
is an imitative driven by OASIS that attempts to blend the competing
specifications AuthML and S2ML, and to facilitate the exchange of authentication
and authorisation information. Closely related to SAML, but focusing
more on a subject-privilege-object orientated security model in the
context of a particular XML document, is the eXtensible Access Control
Markup Language, also directed by OASIS and variously known (even within
the same documents) as XACML or XACL. By writing rules in XACL, a
XKMS, now being considered by a W3C committee, is intended to establish a protocol for key management on top of the XML signature standard. With SAML, XACL, and other initiatives, XKMS is an important element in the large jigsaw that makes up security as applied to XML documents. Its immediate effect is to simplify greatly the management of authentication and signature keys; it does this by separating the function of digital certificate processing, revocation status checking, and certification path location and validation from the application involved -- for example, by delegating key management to an Internet Web service.
XML security still has a long way to go before the needs of convenience in use, reliability, and robustness are met. But good progress is being made.
© 2003-2004 CYBERKRAFT TECHNOLOGIES. ALL RIGHTS RESERVED.