Encryption Steps


After seeing the three broad scenarios in which XML Encryption can be applied, let’s look at exactly what steps are involved in encrypting data.

Step 1: Choose an Encryption Algorithm

In the XML Signature chapter, we learned that symmetric encryption is faster than asymmetric encryption. However, symmetric encryption uses a secret key, which must be conveyed to the recipient. We will see later in the chapter that this can be performed by encrypting the secret key and putting it into an EncryptedKey structure.

Two block-cipher algorithms, Triple-DES and AES, are explicitly supported by XML Encryption. Block ciphers encrypt data block by block, and can be compared with stream ciphers. DES (that is, “single” DES, not Triple-DES) is not supported by XML Encryption. For XML Encryption, AES and Triple-DES are mandated to use Cipher Block Chaining (CBC).

Before going further, we’ll look in depth at what some of the terms in the preceding two paragraphs mean.

Symmetric Encryption: Triple-DES

Triple DES is ANSI standard number X9.52. It specifies the use of three DES operations. It is a block encryption algorithm, meaning that the plaintext is encrypted in fixed-size blocks. Similarly, decryption takes the ciphertext in blocks. If the data is not conveniently divisible into the appropriately sized blocks, “padding” can be used to pad the data out into a multiple of the block size.

As the name suggests, three 64-bit keys are used for Triple-DES, along with a 64-bit initialization vector (IV). The first key encrypts the data to produce ciphertext. The second key is used to “decrypt” this ciphertext. The word decrypt is in inverted commas since the decryption operation doesn’t produce the plaintext, but rather produces more ciphertext. The third key is then used to further encrypt this ciphertext. Note that this is just one mode of Triple-DES encryption—the other modes use different ordering of the encryption and decryption steps.

Note that while the input key for DES is 64 bits long, the actual key used by DES is only 56 bits in length. The least significant (rightmost) bit in each byte is a parity bit, and for cryptographic reasons should be set so that there are always an odd number of 1s in every byte. These parity bits are ignored, so only the seven most significant bits of each byte are used, resulting in a key length of 56 bits. However, this does not mean that Triple-DES has a strength of 168 bits (56 multiplied by 3). The strengths of Triple- DES vary according to the mode; for example, its estimated strength is 112 bits when the first and last keys are equal. So, this means that although Triple-DES uses three times the key length, it isn’t three times the strength of DES.

Ciphertext produced using Triple DES is prefixed by the initialization vector. This ciphertext needs to be base64 encoded if it is to be enclosed in an XML Encryption <CipherValue> element.

Symmetric Encryption: Advanced Encryption Standard (AES)

In October 2000, following extensive analysis by cryptographers worldwide, the Rijndael algorithm was selected by the United States National Institute of Standards and Technology (NIST) to replace DES. Rijndael, which was submitted by two Belgian cryptographers, Joan Daemen and Vincent Rijmen, became the Advanced Encryption Standard (AES). Like DES, AES is a symmetric algorithm that uses block encryption (a block cipher)—that is, the plaintext and ciphertext are broken up into blocks to be sequentially fed into the algorithm. Padding is used to ensure that the data is filled out to be a multiple of the block size, which for AES is 128 bits.

Cipher Block Chaining (CBC) for Symmetric Encryption Block Ciphers

When a block cipher symmetric algorithm (such as Triple-DES or AES) is used in CBC mode, it has the property that the decryption of a block of ciphertext depends on the preceding ciphertext blocks. This means that if a change is made to one block of ciphertext, this affects the decryption not just of that block but of all blocks that follow it in the ciphertext. The dependency on previous blocks also means that if the blocks of ciphertext are rearranged, decryption with the appropriate key will not produce the plaintext. An initialization vector (IV) is used with CBC mode in order to ensure that the same plaintext encrypted with the same key will not produce the same ciphertext.

CBC is preferred to the other mode that can be used for block ciphers—Electronic Code Book (ECB) mode—since it makes attacks based on plaintext patterns less practical.

The Use of an Initialization Vector (IV)

The IV adds a “seed” to the encryption, which mitigates against the fact that characteristics of the plaintext may be known. However, one problem with an IV is that if it is changed, the decrypted plaintext changes also. But think about this for a moment in the context of the high-level security principles of confidentiality and integrity. XML Encryption is not supposed to be used for integrity of data. It is for confidentiality. If the plaintext can be changed by changing the IV, then this affects the integrity of the data. In such cases, the XML Encryption specification recommends “This attack can be avoided by securing the integrity of the plaintext data, for example by signing it.” The lesson is that signing, not encryption, should be used for integrity.

Step 2: Obtain and (Optionally) Represent the Encryption Key

Decryption, obviously enough, requires a decryption key. There are a number of ways to ensure that the entity performing the decryption has the appropriate key.

Rely on the Application Context and Include No Key with the Ciphertext

It is not mandatory to include a key, or any information about a key, into an XML Encryption block. If the choice of which key to use for decryption is already known by the decrypting entity, there is no need to include this information with the encrypted data.

Using KeyName

The next-simplest scenario is where the decrypter has a number of decryption keys to choose from. In this case, the keys can be referred to by name, providing that the same names are used by the encrypting party and the decrypting party. Let’s say that the name of the key is “Image decryption key.” The KeyName element, borrowed from the XML Signature specification, is used to convey this information.

<EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#'         Type='http://www.w3.org/2001/04/xmlenc#Element'/>    <EncryptionMethod           Algorithm='http://www.w3.org/2001/04/xmlenc#3des-cbc'/>    <ds:KeyInfo xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>      <ds:KeyName>Image decryption key</ds:KeyName>    </ds:KeyInfo>    <CipherData><CipherValue>ni320jas2</CipherValue></CipherData>  </EncryptedData>

The assumption is that the decryptor is able to use the name “Image decryption key” to choose the actual decryption key.

Key Transport: Sending a Symmetric Key, Encrypted, in an EncryptedKey Structure

“Key transport” is the name given to the process of encrypting the symmetric key in order to safely send it to the decrypting entity. It may seem like this just creates a new problem—how do you send the key that was used to encrypt the symmetric key? But remember how asymmetric encryption works. Effectively, the decryption key is the private key of the recipient. By using asymmetric encryption for confidentiality of the symmetric key, it means that only the holder of the private key can obtain the symmetric key and use it to decrypt the data. This may beg the question, “why not just use asymmetric encryption for all of the data?” The answer is that asymmetric encryption is much slower than asymmetric encryption, so it makes sense to only use symmetric encryption for the encrypted data. To recap, here are the steps:

  1. Generate a random symmetric key (for example, a Triple-DES key).

  2. Use the symmetric key to encrypt the plaintext.

  3. Encrypt the symmetric key using the public key of the recipient.

  4. Put the encrypted symmetric key into an EncryptedKey structure.

  5. Send the EncryptedKey data to the recipient, either in the same XML document as the EncryptedData block or separately.

The following example shows an EncryptedData structure that indicates that the data in the CipherValue element was encrypted using 128-bit AES encryption. Notice the KeyInfo section from the XML Signature is used.

<EncryptedData Id='EData'       xmlns='http://www.w3.org/2001/04/xmlenc#'>   <EncryptionMethod       Algorithm='http://www.w3.org/2001/04/xmlenc#aes128-cbc'/>      <ds:KeyInfo xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>         <ds:RetrievalMethod URI='#EKey'            Type="http://www.w3.org/2001/04/xmlenc#EncryptedKey">         <ds:KeyName>SymmetricKey</ds:KeyName> ]    </ds:KeyInfo>      <CipherData><CipherValue>fj4io2sa23fF</CipherValue></CipherData> </EncryptedData>

Notice that the RetrievalMethod for the key points to an element using the ID EKey and indicating in the Type attribute that the encrypted key is held in an EncryptedKey structure. The EKey structure is shown here:

<EncryptedKey Id='EKey' 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>Joe's Private Key</ds:KeyName>    </ds:KeyInfo>    <CipherData><CipherValue>j230fw</CipherValue></CipherData>    <ReferenceList>      <DataReference URI='#EData'/>    </ReferenceList>    <CarriedKeyName>TheEncryptedKey</CarriedKeyName>  </EncryptedKey> 

The EncryptedKey structure looks similar to the EncryptedData structure, with the important difference that the CipherValue includes an encrypted 128-bit AES key rather than encrypted plaintext. The algorithm that was used to encrypt the key is indicated by the Algorithm attribute of the EncryptionMethod element. The KeyName indicates which key is used to decrypt the AES key.

CarriedKeyName is used to provide information about the original symmetric key. It may be that encrypted data is being sent to a number of different recipients. In this case, the same symmetric key would be used, but each time it is encrypted using a different public key and put into a separate EncryptedKey block. By giving each AES key the same value for the CarriedKeyName, it conveys the fact that the key is the same. The ReferenceList refers to the data which was encrypted using the symmetric key.

Using Diffie-Hellman Key Agreement

Diffie-Hellman key agreement is used to create a shared secret random number that can then be used as a symmetric algorithm’s secret key. The XML Encryption specification defines how Diffie-Hellman parameters may be enclosed in an AgreementMethod element.

Step 3: Serialize the Data into UTF-8 Encoding

This step only applies to XML plaintext, which must be converted into UTF-8 prior to encryption. UTF-8 (UTF stands for a Unicode Transformation Format) maps Unicode characters (plaintext) into octets—that is, a sequence of bytes. Octets are what encryption algorithms expect as data input. If only a portion of an XML document is to be encrypted, identified using XPath, then this XPath step must be performed prior to the UTF-8 processing.

Step 4: Perform the Encryption

At this stage, we have the octets, we’ve chosen our algorithm, and we have our key. The encryption that is performed is not specific to XML Encryption. Indeed, one of the main purposes of XML Encryption is to marshall arbitrary data (including XML) into the octets that are required by encryption algorithms.

Step 5: Specify the Data Type

The data type is conveyed using the Type, MimeType, and Encoding attributes we encountered in the three examples at the start of this chapter. Specifying the data type is not mandatory, although it is important that the decrypting entity knows the data type.

Process the EncryptedData Structure

In the XML Encryption schema, EncryptedType is the abstract type from which both EncryptedData and EncryptedKey are derived. Think of it like an interface in Java or a virtual data type in C++. It is not used as an element itself, but it has properties that are implemented by elements that are actually used.

The EncryptedData structure includes information about the encrypted data as well as the CipherData element, which includes either the encrypted data itself in a CipherValue element or a pointer to the encrypted data (in a CipherReference element).

If the data to be encrypted is either an element or content (that is, the contents of an XML element), it should be placed into the original XML document, replacing the unencrypted element or content. If the encrypted data was not XML, return the resulting EncryptedData element to the application for further processing.




Web Services Security
Web Services Security
ISBN: 0072224711
EAN: 2147483647
Year: 2003
Pages: 105
Authors: Mark ONeill

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net