15.3 Encryption Examples | Secure XML: The New Syntax for Signatures and Encryption

The following examples are based on a hypothetical medical patient record:

 <MedInfo xmlns='http://x.example/medinfo'>   <Identification>     <Name>John Q. Doe, Jr<Name/>     <Address>...</Address><SSN>000-00-0000</SSN>   </Identification>   <Medical>...</Medical>   <Financial>     <Insurance>...</Insurance>     <Billing>...History...</Billing>     <Payment>       <Type>CreditCard</Type>       <Number>0000 1111 2222 3333</Number>       <Expires>04/02</Expires>     </Payment>   </Financial> </MedInfo>

This XML contains information characterized by different levels of sensitivity and to which different people probably have different access permissions. For example, a person's name and address is usually considered less sensitive than his or her financial information, which in turn is usually considered less sensitive than information about the individual's medical problems and the prognosis for any chronic conditions. Some medical personnel, however, may have access to that medical information but not to the generally less sensitive financial information.

15.3.1 Encrypting XML Elements

The medical history and credit card number of our hypothetical patient John are sensitive information that should be controlled. To keep them confidential, you can encrypt them as shown in Example 15-1.

Example 15-1 XML element encryption

 <MedInfo xmlns='http://x.example/medinfo'          xmlns:xenc='http://www.w3.org/2001/04/xmlenc#'          xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>   <Identification>     <Name>John Q. Doe, Jr<Name/>     <Address>...</Address><SSN>000-00-0000</SSN>   </Identification>   <xenc:EncryptedData     Type='http://www.w3.org/2001/04/xmlenc#Element'>     <ds:KeyInfo><ds:KeyName>Medical</ds:KeyName></ds:KeyValue>     <xenc:CipherData><xenc:CipherValue>...     </xenc:CipherValue></encx:CipherData>   </xenc:EncryptedData>   <Financial>     <Insurance>...</Insurance>     <Billing>...History...</Billing>     <xenc:EncryptedData       Type='http://www.w3.org/2001/04/xmlenc#Element'>       <ds:KeyInfo><ds:KeyName>Pay</ds:KeyName></ds:KeyValue>       <xenc:CipherData><xenc:CipherValue>...       </xenc:CipherValue></xenc:CipherData>     </xenc:EncryptedData>   </Financial> </MedInfo>

By encrypting the entire Payment and Medical elements from their start to end tags, you hide the identities of the elements (although this hiding would be of little importance if the schema is publicly known, for example). The CipherData elements contain the encrypted serialization of the Medical and Payment elements.

15.3.2 Encrypting XML Element Content

The mere fact that someone has a credit card or medical information probably isn't very sensitive, just as everyone in the file might have a Social Security number. On the other hand, the actual credit card number, medical records content, and Social Security number might be more sensitive. As an alternative strategy, you could use element content encryption, as shown in Example 15-2.

Example 15-2 XML element content encryption

 <MedInfo xmlns='http://x.example/medinfo'          xmlns:xenc='http://www.w3.org/2001/04/xmlenc#'          xmlns:s='http://www.w3.org/2000/09/xmldsig#'>   <Identification>     <Name>John Q. Doe, Jr<Name/>     <Address>...</Address>     <SSN><xenc:EncryptedData           Type='http://www.w3.org/2001/04/xmlenc#Content'>       <ds:KeyInfo><ds:KeyName>SSN</ds:KeyName></ds:Keyinfo>       <xenc:CipherValue><xenc:CipherData>...       </xenc:CipherData></xencenc:CipherValue>     </xenc:EncryptedData></SSN>   </Identification>   <Medical><xenc:EncryptedData             Type='http://www.w3.org/2001/04/xmlenc#Content'>     <ds:KeyInfo><ds:KeyName>Medical</ds:KeyName></ds:KeyValue>     <xenc:CipherData><xenc:CipherValue>...     </xenc:CipherValue></xenc:CipherData>   </xenc:EncryptedData></Medical>   <Financial>     <Insurance>...</Insurance>     <Billing>...History...</Billing>     <Payment>       <Type>CreditCard</Type>       <Number><xenc:EncryptedData                Type='http://www.w3.org/2001/04/xmlenc#Content'>         <ds:KeyInfo><ds:KeyName>Pay</ds:KeyName></ds:KeyValue>         <xenc:CipherData><xenc:CipherValue>...         </xenc:CipherValue></xenc:CipherData>       </xenc:EncryptedData></Number>       <Expires>04/02</Expires>     </Payment>   </Financial> </MedInfo>

In Example 15-2, the element names SSN, Medical, and Number are in the clear, but their character content is encrypted. Although Examples 15-1 and 15-2 each use a single strategy, there is no reason that you could not mix them, keeping some elements and some element contents encrypted. In both cases, a different key is shown for each field so that processes authorized for some, but not all, data can receive keys for just those data.

15.3.3 Encrypting Arbitrary Data

If an application requires encrypting some arbitrary, possibly binary data or the entirety of an XML document, then it can just treat all data involved as an octet stream. The resulting EncryptedData can act as the top-level element of a new document or can be embedded in a larger document. For example, for an encrypted XML document, you might have the following:

 <?xml version='1.0'?> <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#'                xmlns:ds='http://www.w3.org/2000/09/xmldsig#'                MimeType='text/xml'>   <ds:KeyInfo><ds:KeyName>docKey123</s:KeyName></ds:Keyinfo>   <CipherData>     <CipherValue>...1sYyMjiAgEfe3urH...</CipherValue>   </CipherData> </EncryptedData>

For an encrypted JPEG with the cipher text stored remotely, you might have this code:

 ...   <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#'                  xmlns:ds='http://www.w3.org/2000/09/xmldsig#'                  MimeType='image/jpeg'                  Encoding='base64'>     <ds:KeyInfo><ds:KeyName>foo</ds:KeyName></ds:KeyInfo>     <CipherData>       <CipherReference URI='http://bar.example/file.jpg'/>     </CipherData>   </EncryptedData> ...

15.3.4 Super-Encryption

An XML document may contain zero or more EncryptedData elements. EncryptedData cannot be the parent or child of another EncryptedData element. However, the actual encrypted data can be anything, including EncryptedData and EncryptedKey elements.

Encrypting previously encrypted information is called super-encryption. During super-encryption of an EncryptedData or EncryptedKey element, you must encrypt the entire element. Encrypting only the content of these elements or encrypting selected child elements is an invalid instance under the XML Encryption schema.

As an example, consider the following:

 <Foo>   <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> </Foo>

A valid super-encryption of the subdocument that would be found by the XPath Expression

 //xenc:EncryptedData[@Id='ED1']

would be

 <Foo>   <EncryptedData Id='ED2'                  xmlns='http://www.w3.org/2001/04/xmlenc#'                  Type='http://www.w3.org/2001/04/xmlenc#Element'>     <CipherData>       <CipherValue>newLongerEncryptedData</CipherValue>     </CipherData>   </EncryptedData> </pay:PaymentInfo>

where newLongerEncryptedData is the base-64 encoding of the cipher text octets resulting from encrypting the EncryptedData element with Id='ED1'.

15.3.5 Referenced EncryptedKey

The following EncryptedData structure is very similar to some of those given previously. This time, however, the key is referenced using a ds:RetrievalMethod:

 [L01] <EncryptedData Id='ED'        xmlns='http://www.w3.org/2001/04/xmlenc#'        xmlns:ds='http://www.w3.org/2000/09/xmldsig#'> [L02]   <EncryptionMethod      Algorithm='http://www.w3.org/2001/04/xmlenc#aes128-cbc'/> [L03]   <ds:KeyInfo> [L04]     <ds:RetrievalMethod URI='#EK'           Type="http://www.w3.org/2001/04/xmlenc#EncryptedKey"/> [L05]     <ds:KeyName>FooKey</ds:KeyName> [L06]   </ds:KeyInfo> [L07]   <CipherData><CipherValue>DEADBEEF        </CipherValue></CipherData> [L08] </EncryptedData>

[L02] This "AES-128-CBC" is a symmetric key block cipher.

[L03] The "AES" key is located at "#EK".

[L04] ds:RetrievalMethod indicates the location of a key with type http://www.w3.org/2001/04/xmlenc#EncryptedKey.

[L05] ds:KeyName provides an alternative method of identifying the key to decrypt the CipherData. Both ds:KeyName and ds:KeyRetrievalMethod should identify the same key value, and they could identify the same key.

Within the same XML document, there exists an EncryptedKey element that is referenced from [L04]:

 [L09] <EncryptedKey Id='EK'                     xmlns='http://www.w3.org/2001/04/xmlenc#'                     xmlns:ds='http://www.w3.org/2000/09/xmldsig#'> [L10]   <EncryptionMethod          Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/> [L11]   <ds:KeyInfo > [L12]     <ds:KeyName>John Smith</ds:KeyName> [L13]   </ds:KeyInfo> [L14]   <CipherData><CipherValue>...          abf396q0tFyenuyEhL65uQ==</CipherValue></CipherData> [L15]   <ReferenceList> [L16]     <DataReference URI='#ED'/> [L17]   </ReferenceList> [L18]   <CarriedKeyName>FooKey</CarriedKeyName> [L19] </EncryptedKey>

[L09] The EncryptedKey element is similar to the EncryptedData element, except that the plain text is normally a key value.

[L10] The EncryptionMethod is a key transport algorithm based on the RSA public key algorithm.

[L12] The ds:KeyName of "John Smith" is a property of the key necessary for decrypting (using RSA) the CipherData of this EncryptedKey.

[L14] The CipherData's CipherValue is the base-64 encoding of an octet sequence that results from encrypting the plain text data for the EncryptedKey. You use the EncryptedKey's EncryptionMethod algorithm to encrypt these octets. The algorithm does not imply the type of the octets.

[L15 17] A ReferenceList identifies the objects (DataReference and KeyReference) encrypted with this key. The DataReference contains a list of references to data encrypted by the symmetric key carried within this EncryptedKey element.

[L18] You use the CarriedKeyName element to identify the encrypted key value. You can reference it by the KeyName element in ds:KeyInfo elsewhere. Because ID attribute values must be unique within a document, CarriedKeyName can be identical in several EncryptedKey structures containing the same key value that has been encrypted for different recipients.