Getting Started with XML Security

Confidentiality: XML Encryption (XML Enc)

Purpose and Benefits

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.

The owner of content may encrypt it to make it confidential. This will make the content unintelligible until it is decrypted. Encryption is generally performed using symmetric key encryption, since this is an efficient technique even for large documents. Symmetric key encryption uses the same key for both encryption and decryption. 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.

To avoid this problem and make it easier to share confidential content with a number of people, asymmetric or public-key cryptography was designed. Public key cryptography uses a matched pair of keys, one for encryption and one for decryption. This allows the sender to encrypt using the recipient's public key, a key that can be shared widely. Decryption requires use of the recipient's private key, known only to them. This helps address the difficulty of establishing confidential communication. Because public key cryptography is less efficient than symmetric cryptography, they are typically used together. 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.

To summarize, the sender may send content confidentially using the following steps:

1. Encrypt the content using a symmetric key


2. Encrypt the symmetric key using the recipient's public key


3. Package the encrypted content, encrypted key and necessary algorithm information together


4. Send the package to the recipient

The recipient may obtain the original content using the following steps:

1. Unpack the package to obtain the algorithm information, the encrypted symmetric key and the encrypted content


2. Decrypt the symmetric key with their private key


3. Decrypt the content with the symmetric key

Features

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.

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.

An important issue in XML Security is the interaction of XML Digital Signatures and XML Encryption. Suppose you receive a document with an XML Signature and an <EncryptedData> element as in the following:

<PatientRecord    
 xmlns="http://www.medical.org/"    
 xmlns:lab="http://www.lab.org/">    
   <Name> John Doe </Name>    
   <Account> 123456 </Account>    
   <EncryptedData Type='element'>    
       ...      
   </EncryptedData>    
   <Signature>    
       <SignedInfo>    
           <Reference URI="">    
               ...    
           </Reference>    
       </SignedInfo>    
   </Signature>    
</PatientRecord>
Example 6 - Encrypted and Signed Document

In this case, the signature indicates that it applies to the entire <PatientRecord> document, since the <Reference> URI is "". This raises the question: did the signature or the encryption come first? This is important to know, since a signature can only be verified as correct if the content has not changed. If a portion of the document was encrypted after signing, the signature will not verify unless the encrypted portion is decrypted first. Knowing the order of encryption and decryption is essential in order to know how to verify the signature. The XML Encryption Transform recommendation [ XMLDecTrans ] defines a solution. When signing, the signer must identify which <EncryptedData> elements are present as part of the signature. This allows a signature verifier to explicitly know which <EncryptedData> elements must be decrypted before verifying a signature.

There are additional security issues raised by XML Encryption, particularly those of "known plaintext attacks". If it is known that particular text was encrypted, such as an element (such as <Visit>, for example) it can make it easier to break the encryption. Because XML is verbose, and the names of elements may be known from the schema definition of the XML vocabulary, it is more likely that plaintext attacks are possible. As a result, additional care must be taken in choosing the encryption algorithms and their parameters to prevent use of this information from removing confidentiality.

Examples

Use of both <EncryptedData> and <EncryptedKey> elements may be summarized using the previous example where the account information is encrypted for confidentiality. Additional information on the EncryptedData and EncryptedKey portions of this example are explained in the XML Encryption candidate recommendation [ XML Enc ]:

<PatientRecord    
 xmlns="http://www.medical.org/"    
 xmlns:lab="http://www.lab.org/tests">    
 <Name>John Doe</Name>      
 <EncryptedData    
Type='http://www.w3.org/2001/04/xmlenc#Element'    
xmlns='http://www.w3.org/2001/04/xmlenc#'>    
   <EncryptionMethod    
Algorithm='http://www.w3.org/2001/04/xmlenc#3des-cbc'/>      
   <ds:KeyInfo    
xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>      
     <EncryptedKey Id='EK'    
xmlns='http://www.w3.org/2001/04/xmlenc#'>    
       <EncryptionMethod    
Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" />      
       <ds:KeyInfo    
xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>      
         <ds:KeyName>    
           Dr Kutter's public key pair    
         </ds:KeyName>    
       </ds:KeyInfo>      
           
       <CipherData>    
         <CipherValue>xyzabc</CipherValue>    
       </CipherData>      
           
       <CarriedKeyName>    
         Dr Kutter's symmetric key    
       </CarriedKeyName>    
     </EncryptedKey>      
         
     <ds:KeyName>    
       Dr Kutter's symmetric key    
     </ds:KeyName>    
   </ds:KeyInfo>      
       
   <CipherData>    
     <CipherValue>a17xj2z</CipherValue>    
   </CipherData>    
 </EncryptedData>      
     
 <Visit date="10pm March 10, 2002">    
   <Diagnosis>    
     Broken second metacarpal    
   </Diagnosis>    
       
   <lab:Diagnosis>    
     <lab:Xray>xhzhez</lab:Xray>    
   </lab:Diagnosis>    
 </Visit>      
     
 <Signature xmlns='http://www.w3.org/2000/09/xmldsig#'>      
   <SignedInfo>      
     <SignatureMethod    
Algorithm="http://www.w3.org/2000/07/xmldsig#rsa-sha1" />      
         
     <!-- signature on entire PatientRecord    
          before encryption is default interpretation -->      
     <Reference URI="">    
       <Transforms    
Algorithm="http://www.w3.org/TR/2000/WD-xml-c14n-20000710" />      
       <DigestMethod    
Algorithm="http://www.w3.org/2000/07/xmldsig#sha1" />    
       <DigestValue>kjsdf</DigestValue>    
     </Reference>    
   </SignedInfo>    
       
   <SignatureValue>xjksdasd</SignatureValue>    
       
   <KeyInfo>    
     <KeyName>Sally Smith's Integrity Key</KeyName>      
   </KeyInfo>      
 </Signature>      
</PatientRecord>
Example 7 - Detailed XML Encryption Example