Encryption Scenarios | Web Services Security

XML Encryption may be applied in three broad cases:

Encryption of an XML element and its contents
Encryption of the contents of an XML element
Encryption of arbitrary data (which may be XML)

We will examine each of these three cases, using this example piece of XML as plaintext:.

<?xml version='1.0'?>   <PaymentInfo xmlns='http://foo.org/details'>     <Name>Joe User</Name>     <CreditCard Limit='12,000' Currency='EUR'>       <Number>1234 5678 9012 3456</Number>       <Issuer>Local Bank</Issuer>       <Expiration>12/06</Expiration>     </CreditCard>   </PaymentInfo>

Note that this example is not a SOAP message. We will see in the WS-Security chapter how XML Encryption is applied to a SOAP message using WS-Security. WS-Security defines a SOAP binding for XML Encryption that identifies encrypted information through a new Confidentiality element.However, the syntax and concepts from this chapter are as relevant for XML Encryption in SOAP as for any other context.

Encrypting an XML Element and Its Contents

Consider the scenario where only the credit card number must be encrypted. The following example illustrates this case:

<?xml version='1.0'?>   <PaymentInfo xmlns='http://foo.org/details'>     <Name>Joe User</Name>     <EncryptedData Type='http://www.w3.org/2001/04/xmlenc#Element'      xmlns='http://www.w3.org/2001/04/xmlenc#'>       <CipherData>         <CipherValue>A23B45C56</CipherValue>       </CipherData>     </EncryptedData>   </PaymentInfo>

Notice that the CreditCard element and its contents are gone, and are replaced by an EncrypedData block. The elements below the CreditCard element (that is, Number. ExpirationDate, and so forth) and their contents are encrypted also. The actual encrypted data is contained in the CipherValue element.

The “Element” Type

In the preceding example, we saw that EncryptedData contains an attribute called Type, which is a value of http://www.w3.org/2001/04/xmlenc#Element. This value indicates that an XML element, including its content and subelements and attributes, was encrypted. If the data type was not specified, the encrypted XML element could be decrypted and treated as plaintext that just happens to include angle brackets and look like XML. The use of this type identifier ensures that this doesn’t happen.

Encrypting the Content of an XML Element

This scenario involves the CreditCard element being left unencrypted, while the contents are encrypted and contained in the CipherValue element:

<?xml version='1.0'?>    < PaymentInfo xmlns='http://foo.org/details'>     <Name>Joe User</Name>     <CreditCard Limit='12,000' Currency='EUR'>       <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#'        Type='http://www.w3.org/2001/04/xmlenc#Content'>         <CipherData>           <CipherValue>A23B45C56</CipherValue>         </CipherData>       </EncryptedData>     </CreditCard>   </PaymentInfo>

The Content Type

Another type defined by the XML Encryption specification, and which we see in the example above, is http://www.w3.org/2001/04/xmlenc#Content. This indicates that the contents of an XML element—not the element itself—were encrypted. The contents include all child nodes whether they be elements, text, or comments.

Encrypting Arbitrary Data (Including XML)

Remember we learned that the IANA data identifiers may be used to identify the format of the plaintext. These are particularly useful when arbitrary data is encrypted. An example of an encrypted JPEG file is shown here:

<?xml version='1.0' ?>  <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#'        Type='http://www.isi.edu/in-notes/iana/assignments/media-types/jpeg'>       <CipherData>             <CipherValue>GEwsRe234f</CipherValue>        </CipherData> </EncryptedData>

Type Information for Arbitrary Data

Apart from the Element and Content data types, XML Encryption does not denote any particular way to define other data types. This is not a problem, though, because there are already standardized names for data types. For example, the official type definitions supplied by the Internet Assigned Numbers Authority (IANA) may be used. These cover an enormous variety of data types, including familiar types such as PDF and JPEG. The IANA definitions are available at the following URL: http://www.isi.edu/in-notes/iana/assignments/media-types/media-types. The IANA data type for XML is the following: http://www.isi.edu/innotes/iana/assignments/media-types/text/xml. In addition to IANA, any proprietary or vertical industry-specific data type can be used. These may be specified using a DTD or an XML schema definition.

The EncryptedData element also contains optional attributes of MimeType (for the MIME-type—for example, image/png) and Encoding (for example, base64).

If no Type, MimeType, or Encoding are provided in the EncryptedData element, this does not mean that the data cannot be decrypted. The data format may be understood at the application context—that is, the decrypting application knows what type of data to expect, and requires no information in the XML Encryption block to tell it what the data type is.

CipherValue and CipherReference

In the three examples cited previously, the ciphertext was included in the CipherValue element. What if one wanted to encrypt a very large data source such as an MPEG file? In this scenario, where the encrypted data is large, it may be preferable to put it into a file of its own. The CipherReference element can be used to point to the encrypted data. The CipherReference location is expressed in the form of a URI, which should be dereferenced (that is, followed so as to pull down the data) in order to obtain the data for decryption.

It is optional to include transforms under the CipherReference element. In the following example, a transform is used to base64-decode the data:

<CipherReference URI="http://www.example.com/MyEncryptedData.xml">     <Transforms>       <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#base64"/>     </Transforms>   </CipherReference>

XML Encryption Uses Transforms Differently than XML Signature

You might notice that the URI and transforms are similar to elements used in XML Signature, but there are differences in the way they are used. In XML Signature, the transforms are applied in the same order by both the signature generator and validator. In XML Encryption, the transforms specified are solely intended for the decryptor and are often the reverse of what the encryptor did. For example, an encryptor might encrypt an MP3 file, base64 the octets, and store the ciphertext in a database. On the decryption side, the decryptor will retrieve the ciphertext from the database, de-base64 it, and then decrypt it.