SCDJWS Study Guide: XML Security


Printer-friendly version Printer-friendly version | Send this 
article to a friend Mail this to a friend


Previous Next vertical dots separating previous/next from contents/index/pdf Contents

XML Encryption

The XML Encryption provides end-to-end security for applications that require secure exchange of structured data. XML itself is the most popular technology for structuring data, and therefore XML-based encryption is the natural way to handle complex requirements for security in data interchange applications

The XML Encryption recommendation defines an XML vocabulary and processing rules enabling confidentiality to be applied to a variety of content. XML Encryption serves the purpose of maintaining the confidentiality of information, both while in transit as well as when stored. Other technologies for confidentiality such as secure sockets layer (SSL)/transport layer security (TLS) or virtual private networks (VPNs) only provide confidentiality while the information is in transit, not while it is stored at a server.

Introduction

As has been stressed repeatedly, Web services imply constant service interactions and exchange of XML-formatted business data across different subsystems. Many of these may involve confidential business transactions, in which the data exchanged must be private throughout the transaction.

Also, during complex business process, the XML business data has to pass through several systems, applications, and networks. It becomes important to ensure that the confidentiality of information is being protected during this commutation.

If Web services are to succeed in networks as insecure as the Internet, then we need to evolve rock-solid security mechanisms to protect the confidentiality of XML. Even within an organization's boundaries, we need to exercise privacy over sensitive XML information. For example, an XML document containing an employee's salary or bonus information needs to be protected against unintended audience.

In the conventional enterprise IT realm, the proven mechanisms for protecting the confidentiality of information across different systems and networks are is encryption and cryptography. The idea is to adapt these mechanisms so that that they can be used to secure XML data exchanged between Web services.

As with all other XML/Web service security standards, the challenge lies in evolving platform-independent/vendor-neutral XML standards and syntax for encoding/decoding XML documents.

Basic Cryptography

Cryptography is the most popular mechanism for protecting digital documents exchanged across the wire between two parties involved in confidential business transactions.

The basic concept of cryptography is illustrated as follows:

  1. A sender application uses high-speed mathematical algorithms to transform a given piece of data to a complicated combination of digits and numbers just before transmission. The algorithms employed are so complex that it is impossible to reproduce the original data from this resulting chunk.
  2. This meaningless chunk of data is then transmitted across the wire. If any unintended recipients can intercept the communications, they will be able to read only this chunk (from which nothing can be derived), not the original data.
  3. On the receiving end, premeditated reverse transforms are applied in order to decipher the data chunk. The sender has to ensure that only the indented recipients are empowered with reverse transforms.

The transformation process applied at the sender's end is known as encryption; the process at the receiver's end is known as decryption.

Over the years, several famous algorithms that can achieve very high levels of security have evolved. Many of these algorithms use specific combinations of numbers and digits—called keys—during the encryption/decryption process. Information encrypted by using specific keys can be decrypted only by using corresponding key pairs. This enables the reuse of same encryption algorithms across different applications.

XML Encryption

XML encryption is the process of encrypting and decrypting digital XML content, using certain syntax and algorithms. The basic concept of cryptography remains much the same, but the difference is in adopting a standard format for representing and exchanging encrypted XML data.

This standard format, often known as the XML encryption specification, includes a standard syntax for representing the encrypted content within the XML, as well as information required to decrypt its contents at the receiving end.

The W3C XML Encryption Working Group—a collaborative effort between the W3C (World Wide Web Consortium) and the IETF (Internet Engineering Task Force)—advocates XML encryption standards and specifications. (W3C and IETF are two of the frontline organizations involved in defining interoperable standards and specifications for XML/Web services technologies.)

As of March 2002, the Working Group has released the Candidate Recommendation Specification for XML encryption, which includes the following:

  • XML Encryption Requirements
  • XML Encryption Syntax and Processing

Inspirations behind the XML Encryption specification effort can be summarized as follows:

  • It is good to have standard element tags for representing encrypted elements within the XML documents. This will enable parsers to better understand encrypted elements and data during the validation process.
  • It is necessary to provide means for encrypting only the desired elements within an XML document instead of encrypting the whole document. This will pave the way for incorporating several confidential data elements that are intended for different recipients within a single XML document.
  • There should be standard mechanisms for exchanging the secret keys used for encryption and decryption processes.
  • The standard should allow encryption of different parts of the document with different keys, so that multiple recipients can decrypt only those portions that are intended for them.
  • The standards should be adaptable to both ASCII and binary data.
  • The standards should be adaptable to different cryptographic algorithms.
  • The standards should work along with other XML security standards and specifications

The XML Encryption recommendation defines the framework and processing rules for XML encryption and decryption. It defines an XML vocabulary for packaging all the information needed to process encrypted content, such as encryption algorithm and parameters, information about keys, and encrypted content. The XML Encryption recommendation supports the following features:

  1. XML and non-XML content may be encrypted, giving broad applicability to the recommendation.
  2. Confidentiality may be applied at a fine level of granularity to XML content. It may be applied to XML elements and XML element content as well as entire XML documents. This is valuable for securing portions of XML Protocol messages to be routed through intermediary processors.
  3. XML Encryption produces well-formed XML from well-formed XML. This allows portions of XML content to be encrypted yet subsequently processed by XML tools.
  4. XML Encryption is compatible with and may be used in conjunction with XML Digital Signatures.
  5. XML Encryption allows for encryption of a symmetric key that may be packaged with encrypted content.
  6. XML Encryption supports a variety of encryption algorithms and techniques.

XML Encryption Key Concepts:

  1. When an XML element or element content is encrypted, it is replaced by an <EncryptedData> element.
  2. When non-XML content is encrypted, the result is a new XML document containing an <EncryptedData> element.
  3. An <EncryptedData> element may include a Type attribute to assist the recipient in decrypting it. This Type may indicate that an XML element or element content was encrypted, or give the type of other information, such as images for example. This is done using an existing standard for mail attachments, known as MIME types.
  4. The <EncryptedData> element defines the algorithm used for encryption, provides the encrypted content, and may include information necessary to determine the key needed for decryption.
  5. The symmetric key used to encrypt content may be conveyed in an <EncryptedKey> element.
  6. XML Encryption supports the selection of appropriate encryption algorithms and defines XML identifiers for common cases and may be extended for others.
  7. Definitions for identifying key information are based on XML Digital Signature definitions and extended.
  8. User-defined properties may be associated with an encrypted element, such as a timestamp or log reference.
  9. The actual cipher text, the result of encryption, is specified using a <CipherData> element. This may contain the actual encrypted data within a <CipherValue> element, or a URI reference to encrypted data that is stored elsewhere (<CipherReference>). A reference is useful when the encrypted data is large and not needed by most parties, such as processing intermediaries.

XML Encryption Elements

Expressed in shorthand form, the <>EncryptedData element has the following structure (where "?" denotes zero or one occurrence; "+" denotes one or more occurrences; "*" denotes zero or more occurrences; and the empty element tag means the element must be empty):

<EncryptedData Id? Type? MimeType? Encoding?>
  <EncryptionMethod/>?
  <ds:KeyInfo>
      <EncryptedKey>?
      <AgreementMethod>?
      <ds:KeyName>?
      <ds:RetrievalMethod>?
      <ds:*>?
  </ds:KeyInfo>?
  <CipherData>
      <CipherValue>?
      <CipherReference URI?>?
  </CipherData>
  <EncryptionProperties>?
</EncryptedData>

The <EncryptedData> element is the most important element. Not only does its <ChiperData> child contain the encrypted data, but it is also the element that replaces the encrypted element, or serves as the new document root.

The <CipherData> is a mandatory element that provides the encrypted data. The <CipherData > element must either directly contains the cipher data (i.e., encrypted octet sequence) in the form of base64 encoded text of the <CipherValue> element, or provide a reference to an external location containing the encrypted octet sequence via the <CipherReference> element. The other elements are optional because usually the receiving party already has the information they contain. For instance, Both the <EncryptionMethod> and <KeyInfo> are optional i.e. the sender and receiver may agree on the encryption method and key in advance. The <EncryptionMethod> lets you specify the algorithm and key size, but usually you and the other party will agree on those beforehand. The same goes for <KeyInfo>: it gives you the flexibility to give the other party the material to decrypt your message, but you'd probably want to send it through some out-of-band mechanism. <EncryptionProperties> serves as another optional element used for, optional information, such as a date/time stamp.

Let's look at a typical XML-encrypted document. The following table shows the XML data structure before encryption and XML Encryption allows you to encrypt arbitrary data, and have the result be an XML element.

Original XML Data-Structure

<EmployeeInfo xmlns="http://www.aol.com/xml/nmsp/employee">
 <CompanyName>AOL</CompanyName>
 <Employee>
   <Name>John Wong</Name>
   <Age>30</Age>
   <Salary>70000</Salary>
 </Employee>
 <Department>Editorial</Department>
 <Division>Publishing</Division>
</EmployeeInfo>



Encrypted XML Data-Structure

<EmployeeInfo
xmlns="http://www.aol.com/xml/nmsp/employee">
  <EncryptedData
   Type="http://www.w3c.org/2001/04/xmlenc#Element"
   xmlns="http://www.w3c.org/2001/04/xmlenc#">
    <CipherData>
      <CipherValue>ABCXXXWWWER</CipherValue>
    </CipherData>
  </EncryptedData>
</EmployeeInfo>


<EncryptedData> Element


The <EncryptedData> element begins the XML-encrypted section within the document. In the above table, because we decided to encrypt the entire document, we see the <EncryptedData> element in the location of the original data elements.

An XML document may contain zero or more EncryptedData elements. EncryptedData cannot be the parent or child of another EncryptedData element. However, the actual data encrypted can be anything, including EncryptedData and EncryptedKey elements (i.e., super-encryption). During super-encryption of an EncryptedData or EncryptedKey element, one must encrypt the entire element. Encrypting only the content of these elements or encrypting selected child elements is an invalid instance under the provided schema.

<pay:PaymentInfo xmlns:pay='http://example.org/paymentv2'>
  <EncryptedData Id='ED1' xmlns='http://www.w3.org/2001/04/xmlenc#'
        Type='http://www.w3.org/2001/04/xmlenc#Element'>
    <CipherData>
      <CipherValue>originalEncryptedData</CipherValue>
    </CipherData>
  </EncryptedData>
</pay:PaymentInfo>

A valid super-encryption of "//xenc:EncryptedData[@Id='ED1']" would be:

<pay:PaymentInfo xmlns:pay='http://example.org/paymentv2'>
  <EncryptedData Id='ED2' xmlns='http://www.w3.org/2001/04/xmlenc#'
        Type='http://www.w3.org/2001/04/xmlenc#Element'>
    <CipherData>
      <CipherValue>newEncryptedData</CipherValue>
    </CipherData>
  </EncryptedData>
</pay:PaymentInfo>
 
where the CipherValue content of 'newEncryptedData' is the base64 encoding of the encrypted octet sequence resulting from encrypting the EncryptedData element with Id='ED1'.
 

The following rules govern the <EncryptedData> element:

  • It is the core element that should enclose all encrypted XML data.
  • It cannot be a parent or child of another <EncryptedData> element.
  • It may become a root of the document (in case the whole document is encrypted, as in this example).
  • Its standard namespace is xmlns:xenc='http://www.w3c.org/2001/04/xmlenc#'

<CipherData> Element

The second element in the encrypted XML document that draws our attention is the <CipherData> element. Being a child of the <EncryptedData> element, it encloses the actual cipher string that results from the encryption process.

The <CipherData> element makes use of the <CipherValue> tag to enclose the encrypted string. This is called enveloping the raw encrypted data.

In case the encrypted string is available elsewhere in the network, it is referred within the <CipherReference> tag. This is called referencing the encrypted data.

You can encrypt information in different levels from element to content, for example:

Encrypted <Salary> Element

<EmployeeInfo
xmlns="http://www.aol.com/xml/nmsp/employee">
  <CompanyName>XYZWS</CompanyName>
  <Employee>
    <Name>John Wong</Name>
    <Age>30</Age>
    <EncryptedData
     Type="http://www.w3c.org/2001/04/xmlenc#Element"
     xmlns="http://www.w3c.org/2001/04/xmlenc#">
      <CipherData>
        <CipherValue>ATBCCCD</CipherValue>
      </CipherData>
    </EncryptedData>
  </Employee>
  <Department>Editorial</Department>
  <Division>Publishing</Division>
</EmployeeInfo>



Encrypted Content of <Salary> Element

<EmployeeInfo
xmlns="http://www.aol.com/xml/nmsp/employee">
  <CompanyName>XYZWS</CompanyName>
  <Employee>
    <Name>John Wong</Name>
    <Age>30</Age>
    <Salary>
      <EncryptedData
       Type="http://www.w3c.org/2001/04/xmlenc#Element"
       xmlns="http://www.w3c.org/2001/04/xmlenc#">
        <CipherData>
          <CipherValue>ABREEE</CipherValue>
        </CipherData>
      </EncryptedData>
    </Salary>
  </Employee>
  <Department>Editorial</Department>
  <Division>Publishing</Division>
</EmployeeInfo>

 

<EncryptedKey> Element

As was discussed earlier in this article, the XML encryption standard provides room for embedding relevant key information, required for decrypting the data, at the receiving end. The <EncryptedKey> element is used for this purpose.

Have a look at the following “XML keys exchange using the <EncryptedKey> element, which illustrates the transmission of encrypted symmetric keys from sender to receiver. Here, we assume that the public key of the receiver is already available with the sender.

....
<EncryptedKey CarriedKeyName="Mike Hu" xmlns="http://www.w3c.org/2001/04/xmlenc#">
  <EncryptionMethod Algorithm="http://www.w3c.org/2001/04/xmlenc#rsa-1_5"/>
  <CipherData>
    <CipherValue>xx22324ssssdATBCCCD</CipherValue>
  </CipherData>
</EncryptedKey>
....

You may wonder about what sort of security we are talking about—if we are bundling the secret key along with the encrypted document, so painstakingly produced! The next section offers the much-required explanation to this paradox.

Encryption Algorithms and Keys Exchange

Two types of cryptographic approaches are available for encrypting data within XML documents:

  • Symmetric key cryptography
  • Public key cryptography

In symmetric key cryptography, the same key is used to encrypt and decrypt data at either end. To send confidential information to a receiver, the sender must also share the symmetric key with the recipient but not anyone else. This can be difficult without person to person contact.

But in public key cryptography, the keys function as pairs: One is a secret key or private key that is held by specific parties involved in confidential transactions; the other is called a public key, and it is distributed to all. Anybody can encrypt data using the public key; but for decryption, you need the private key as well as the public key.

Symmetric key cryptography is much faster than public key cryptography, and it is suitable for encrypting large chunks of information. But the disadvantage is obviously the usage of same key on both ends, so there is reduced privacy.

On the other hand, public key cryptography is relatively much more secure because the private key, required for decryption, is held only in one end. But the problem is that it is relatively slow and useful only for encrypting small pieces of information.

Because public key cryptography is less efficient than symmetric cryptography in term of the “speed”, the XML-encryption process uses an ingenious combination of both algorithms to secure communications between the services. The symmetric key is used to encrypt the content, and then the symmetric key is encrypted using public key cryptography. Both the encrypted content and encrypted symmetric key are then sent to the recipient. The cycle is as follows:

  • The sender:
    1. The sender gets a copy of the public key from the intended recipient; the latter holds the corresponding private key.
    2. The sender encrypts the required pieces of information in the XML document using a new symmetric key, and formats it per the syntax (using the <EncryptedData> element, and so on).
    3. The sender also encrypts the symmetric key itself using the public key of the recipient.
    4. The sender bundles this encrypted symmetric key with other elements in the document using the <EncryptedKey> element, and transmits the same.
  • The recipient:
    1. Upon receiving the document from the wire, the recipient unpacks the package to obtain the algorithm information, the encrypted symmetric key, and the encrypted content.
    2. The recipient decrypts the symmetric key in the <EncryptedKey> element with their private key.
    3. The recipient decrypts the encrypted content with the symmetric key obtained previously.

In short, we use one methodology to secure the document data and another to secure the keys! This shrewd combination of public key and symmetric key cryptography secures XML documents in the best possible manner. The only risk is the leakage of private keys from the recipient's hand, which needs to be taken care of.

SSL/TSL versus XML Encryption

Before we conclude, it is good to understand why we need exclusive standards and methodology for XML encryption when we already have established technologies like Secure Socket Layers (SSL) and Transport Security Layer (TSL), which also use cryptographic concepts to secure communications.

Although SSL and TSL are good for securing communications across two parties, they are not suitable for multiparty interactions, which is a typical characteristic of XML/Web service interactions. Also, SSL and TSL do not have the capacity to encrypt only specific parts of the document or to encrypt different portions of the document using different keys—which are critical to XML encryption.

Future of XML Encryption

Having designed the basic syntax and specifications, the challenge for industry lies in evolving language and platform-specific APIs for building XML encryption services within Web service applications. Products and toolkits have started appearing in the market: Take a look at IBM's XML security suite and Verisign's security toolkit.

From the Java side, JSR 106 is an exclusive community request for the XML Digital encryption API. It is expected to cover many of the aspects we need to deal with XML encryption inside Java Web service applications. The same API should also be useful for distributed J2EE applications.

In the Microsoft camp, the giant is involved in defining a much broader Web service security framework with its WS Security initiative with IBM. XML encryption will become a part of this bigger framework with native support in Microsoft's .Net framework as well. Explore http://msdn.microsoft.com/library/default.asp and select cryptography, if you are interested in looking at the cryptographic services currently available in .Net.

Conclusion

XML encryption secures documents exchanged between Web services. By making use of cryptographic methodologies, XML encryption enables the encryption of specific parts of an XML document. Keys are exchanged using a combination of public and symmetric key cryptography.

XML encryption specifications have established the standard syntax for representing various parts of an encrypted XML document. APIs and toolkits are in the process of evolving.



Previous Next vertical dots separating previous/next from contents/index/pdf Contents

  |   |