XML Encryption

XML Encryption,[4] like XML Signature, is a W3C recommended standard for protecting digital content. It specifies the processing steps to encrypt data bytes, syntax to represent the encrypted bytes as an XML element, and the processing steps to retrieve the original content from XML representation of the encrypted data. The input data bytes themselves could be in any format, including XML format. With XML, you get the additional capability to encrypt an element (and all its children) or element content. The element content includes its text data and children, excluding the start and end tags and the attributes and namespace declarations within the start tag.

[4] The complete name of the recommendation is XML Encryption Syntax and Processing, and its latest version can be found at http://www.w3.org/TR/xmlenc-core. It was granted recommendation status on 10 December 2002.

An Example

Let us follow the same pattern we used for learning about XML Signature—begin with an XML file, apply encryption to an element, replace the original element with the element representing the encrypted element and look at the resultant file. For this purpose, we use the same file as input that we used for XML Signature, the one shown in Listing 7-1. Let us pick the element bookinfo, identified by ID attribute value "book_info", for encryption.

The resulting file is shown in Listing 7-10.

Listing 7-10. XML file with EncryptedData element for book_info element
<?xml version="1.0" encoding="UTF-8"?>
<bk:book id="j2ee_sec" xmlns:bk="http://www.pankaj-k.net/schemas/book">
  <title id="book_title" subject="bk:programming">J2EE Security</title>
  <author id="book_author">Pankaj Kumar</author>
  <publisher id="book_publisher">Prentice Hall</publisher>
  <xenc:EncryptedData
      Type="http://www.w3.org/2001/04/xmlenc#Element"
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
    <xenc:EncryptionMethod
        Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
    <xenc:CipherData>
      <xenc:CipherValue>
dOJ/6LQvetILoYHDgkbuPh6TEM5YIu+r9HVhjIOlCj1ekwsiKCTRWqt3fLLeh7Jj+bJ6gVRF
... intermediate lines skipped ...
N/C4ArCJ33mX7mIuzmiroDuflvHJOHzx1N8CJ9NUAgGqXmoyttxypw==
 </xenc:CipherValue>
    </xenc:CipherData>
  </xenc:EncryptedData>
</bk:book>

Let us analyze this file:

  • The element bookinfo of the original document has been replaced by the element EnryptedData. This element is associated with the namespace URI "http://www.w3.org/2001/04/xmlenc#". The attribute Type has the value “http://www.w3.org/2001/04/xmlenc#Element”, indicating that the encryption has been applied over an element, and not over the element content.

  • The element EncryptedData contains the elements EncryptionMethod and CipherData as its immediate children. The attribute Algorithm of the element EncryptionMethod identifies the encryption algorithm, which happens to be TripleDES with mode CBC (Cipher Block Chaining), identified by URI "http://www.w3.org/2001/04/xmlenc#tripledes-cbc". The element CipherData has the element ChipherValue, whose text value is the base64 encoding of the octet sequence representing the encrypted data.

How would the resulting file look if we wanted to encrypt only the content of the element bookinfo, and not the complete element? You can view the result of encrypting only the element content in Listing 7-11.

Listing 7-11. XML file with EncryptedData element for element content
<?xml version="1.0" encoding="UTF-8"?>
<bk:book id="j2ee_sec" xmlns:bk="http://www.pankaj-k.net/schemas/book">
  <title id="book_title" subject="bk:programming">J2EE Security</title>
  <author id="book_author">Pankaj Kumar</author>
  <publisher id="book_publisher">Prentice Hall</publisher>
  <bookinfo id="book_info"
      xmlns:bi="http://www.pankaj-k.net/schemas/bookinfo"
      xmlns:book="http://www.pankaj-k.net/schemas/book">
    <xenc:EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Content"
        xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
      <xenc:EncryptionMethod
          Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
      <xenc:CipherData>
        <xenc:CipherValue>
+iQIyT1sjUVsXvnqf6UmAY/IsVg06uAO7LEBkr5WQWatib3Xc7BlFBULgmwcqs+g1uvcuZWV
... intermediate lines skipped ...
vP4udJljYCbi0qtSbU209pQG
        </xenc:CipherValue>
      </xenc:CipherData>
    </xenc:EncryptedData>
  </bookinfo>
</bk:book>

As expected, start and end tags, attributes and namespace declarations are left intact; and the Type attribute value "http://www.w3.org/2001/04/xmlenc#Content" indicates that the element EncryptedData corresponds to the element content.

Given that the encryption method is TripleDES, a symmetric encryption algorithm, it is easy to figure out that a secret key has been used to perform the encryption, and it would not make sense to include the key information in the document, for including the secret key would mean that anyone who gets the message can decrypt it.

What about asymmetric encryption? As noted earlier, XML Encryption syntax supports asymmetric encryption as well. Recall that asymmetric encryption uses a public key for encryption and the corresponding private key for decryption. This is reverse of the digital signature, where a private key is used for signing and a public key for verification. As we know, asymmetric encryption is usually much slower than symmetric encryption. So, the standard practice is to use symmetric encryption for the data and asymmetric encryption for the secret key used for encrypting the data.

It would be instructive to look at the XML file resulting from asymmetric encryption of the bookinfo element. This file is shown in Listing 7-12.

Listing 7-12. XML file with EncryptedData using asymmetric encryption
<?xml version="1.0" encoding="UTF-8"?>
<bk:book id="j2ee_sec" xmlns:bk="http://www.pankaj-k.net/schemas/book">
  <title id="book_title" subject="bk:programming">J2EE Security</title>
  <author id="book_author">Pankaj Kumar</author>
  <publisher id="book_publisher">Prentice Hall</publisher>
  <xenc:EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element"
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
    <xenc:EncryptionMethod
        Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
    <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
      <xenc:EncryptedKey>
        <xenc:EncryptionMethod
            Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
        <xenc:CipherData>
          <xenc:CipherValue>
YvlSc4F4ey/CWVl2baqRAg4m3qJFcPU645omxNftauu7cha2n4jX19ms176ELUMXDIHVT4AN
+G3yNVtCcJfHDA==
          </xenc:CipherValue>
        </xenc:CipherData>
      </xenc:EncryptedKey>
    </ds:KeyInfo>
    <xenc:CipherData>
      <xenc:CipherValue>
DCX2lWh1H03TAir6sbEEHrLZr/aHCKL4Mw/yYbQhcaqzcHV0W30+xSEKVeXyIzjMcWRT/WtG
... intermediate lines skipped ...
TgwqGvzbo3hpFY7g1ECweB3AdWPS2z7Z1pRE6l3T0NYtd5aMxM2Xkg==
      </xenc:CipherValue>
    </xenc:CipherData>
  </xenc:EncryptedData>
</bk:book>

Note that the EncryptedData element in Listing 7-12 includes the element ds:KeyInfo. This element is in the XML Signature namespace. However, the child of ds:KeyInfo is element EncryptedKey, an element belonging to the XML Encryption namespace "http://www.w3.org/2001/04/xmlenc#". This element is defined within the XML Encryption specification and makes use of the extension mechanism of ds:KeyInfo schema to be part of ds:KeyInfo. As you can see, this element represents a secret key, encrypted with the asymmetric algorithm RSA1_5. This secret key is used for encrypting the bookinfo element with the symmetric algorithm TripleDES.

Structure of the EncryptedData Element

In the same way we examined the structure of the Signature element, let us look at the structure of the EncryptedData element.

<EncryptedData ID? Type? MimeType? Encoding?>
  <EncryptionMethod Algorithm>algo. Specific elems
</EncryptionMethod>?
 (<ds:KeyInfo>
    <EncryptedKey>?
    <AgreementMethod>?
    <ds:KeyName>?
    <ds:RetrievalMethod>
    <ds:*>?
  </ds:KeyInfo>)?
 (<CipherData>
   (<CipherValue>base64 encoded ciphertext</CipherValue>)|
   (<CipherReference URI>
     (<Transforms>
       (<ds:Transform>)+
      <Transforms>)*
    </CipherReference>)
  </CipherData>)
  <EncryptionProperties>?
</EncryptedData>

All elements without a local prefix belong to XML Encryption namespace "http://www.w3.org/2001/04/xmlenc#" and those with prefix ds belong to XML Signature namespace “http://www.w3.org/2000/09/xmldsig#”.

As you can see, the EncryptedData element consists of an optional EncryptionMethod element, an optional KeyInfo element and a CipherData element. The element EncryptionMethod, when present, must specify the algorithm through a URI and algorithm-specific parameters, if any. The element KeyInfo is defined by the XML Signature and is augmented by the XML Encryption with the elements EncryptedKey and AgreementMethod. We have already seen use of the EncryptedKey element to hold the encrypted value of a secret key used for encrypting the data. A complete description of these elements is beyond the scope of our current discussion.

This syntax allows cipher text to be either included as the content of CipherValue in base64 encoded form, within the EncryptedData element or stored at a separate location specified through the CipherReference element. The separate location could be a file, an element within the same XML document, or an element within another XML document. This is illustrated in Figure 7-3.

Figure 7-3. EncryptedData element and the cipher text.


With the CipherReference element, you can get the cipher text by dereferencing the URI value and applying the specified transformations. These transformations are the same as in the XML Signature. However, the processing steps are slightly different. In the XML Signature, the same transformations are applied, in the order they occur, during both the signing and the verification process. This makes sense, as the signing doesn't modify the original data and the verification must obtain the same byte sequence used for signing, starting with the original data. In the case of XML Encryption, though, the transformations need to be applied only during decryption to get the sequence of octets representing the cipher text from its transformed value. No transformation is needed if the cipher text is stored in its original, binary form in a separate file.

To emphasize this difference in semantics, a new Transformations element is defined in the XML Encryption namespace, and the one in the XML Signature namespace is not reused.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.149.254.7