15.1 XML Encryption

 <  Day Day Up  >  

The World Wide Web Consortium (W3C) proposes XML Encryption (Xenc) as a standard for encrypting the XML data and tags within a document. Xenc allows you the flexibility of encrypting portions of a document. In other words, you can encrypt only the sensitive parts, leaving the rest in plain text. The data remains encrypted, but XML parsers can still process the rest of the file. In addition, by using different keys to encrypt different parts of the document, you can distribute the document to multiple recipients. Each recipient will be able to decrypt the portions relevant to him but unable to decipher the rest. This capability allows for wide distribution with a granular control of accessibility.

However, the W3C has raised some issues regarding the security of Xenc. For instance, using both encryption and digital signatures on parts of an XML document can complicate future decryption and signature verification. Specifically, you need to know whether the signature was computed over the encrypted or unencrypted forms of the elements when you are verifying a signature. Another security issue is potential plain-text guessing attacks. For example, encrypting digitally signed data while leaving the digital signature unencrypted may open a potential vulnerability. In addition, there is a potential security risk when combining digital signatures and encryption over a common XML element. However, you can reduce this risk by using secure hashes in the text being processed .

The W3C states that this is an "application" issue that is beyond the scope of their protocol specification. Thus, the burden is on developers to implement cryptographically robust systems. The W3C recommends that when you encrypt data, you make sure to also encrypt any digest or signature over that data. This step solves the issue of whether the signature was computed over the encrypted or unencrypted forms of the elements, since only those signatures that can be seen can be validated . This solution also reduces the threat of plain text guessing attacks, though it may not be possible to identify all the signatures over a given piece of data.

The W3C recommends that you also employ the "decrypt-except" signature transform (XML-DSIG-Decrypt). According to this specification, if you encounter a decrypt transform during signature-transform processing, you should decrypt all encrypted content in the document except for the content exempted by a numbered set of references. Consider the example from the W3C in the sidebar Decrypting All but an Exempted Section of Content.

Decrypting All but an Exempted Section of Content

Suppose the following XML document is to be signed. Note that part of this document (12) is already encrypted prior to signature. In addition, the signer anticipates that some parts of this document ”for example, the cardinfo element (07-11) ”will be encrypted after signing.

 [01] <order Id="order"> [02]   <item> [03]     <title>XML and Java</title> [04]     <price>100.0</price> [05]     <quantity>1</quantity> [06]   </item> [07]   <cardinfo> [08]     <name>Your Name</name> [09]     <expiration>04/2002</expiration> [10]     <number>5283 8304 6232 0010</number> [11]   </cardinfo> [12]   <EncryptedData Id="enc1" xmlns="http://www.w3.org/2001/04/xmlenc#">...          </EncryptedData> [13] </order> 

In order to let the recipient know the proper order of decryption and signature verification, the signer includes the decryption transform (06-08 below) in the signature. Assuming that an additional encryption is done on the cardinfo element, the recipient would see the following encrypt-sign-encrypt document:

 [01] <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> [02]   <SignedInfo> [03]     ... [04]     <Reference URI="#order"> [05]       <Transforms> [06]         <Transform                  Algorithm="http://www.w3.org/2001/04/xmlenc#decryption"> [07]           <DataReference URI="#enc1"                   xmlns="http://www.w3.org/2001/04/xmlenc#"/> [08]         </Transform> [09]         <Transform                  Algorithm="http://www.w3.org/TR/2000/CR-xml-c14n-20001026"/> [10]       </Transforms> [11]       ... [12]     </Reference> [13]   </SignedInfo> [14]   <SignatureValue>...</SignatureValue> [15]   <Object> [16]     <order Id="order"> [17]       <item> [18]         <title>XML and Java</title> [19]         <price>100.0</price> [20]         <quantity>1</quantity> [21]       </item> [22]       <EncryptedData Id="enc2"                xmlns="http://www.w3.org/2001/04/xmlenc#">...</EncryptedData> [23]       <EncryptedData Id="enc1"                xmlns="http://www.w3.org/2001/04/xmlenc#">...</EncryptedData> [24]     </order> [25]   </Object> [26] </Signature> 

The recipient should first look at the Signature element (01-26) for verification. It refers to the order element (16-24) with two transforms: decryption (06-08) and C14N (09). The decryption transform instructs the signature verifier to decrypt all the encrypted data except for the one specified in the DataRef element (07). After decrypting the EncryptedData in line 22, the order element is canonicalized and signature- verified .


Other attacks against Xenc besides this W3C example are theoretically possible. In certain encryption algorithms, when you encrypt the plain text with the same key, the resulting ciphertext is always the same. For example, XML encoding and tags are redundant; since an attacker may determine the data's structure, this can introduce potential vulnerabilities. Careful encryption implementation and testing mitigates this risk.

Another potential risk to Xenc is denial-of-service, since the specification permits recursive processing. The W3C gives the following example:

  1. EncryptedKey A requires EncryptedKey B to be decrypted.

  2. EncryptedKey B requires EncryptedKey A to be decrypted.

  3. EncryptedKey A...

In another DoS scenario, the hacker submits for decryption an EncryptedData that references very large or continually redirected network resources. To mitigate these risks, your implementation should allow limits on arbitrary recursion, processing power, and bandwidth.

 <  Day Day Up  >  


Security Warrior
Security Warrior
ISBN: 0596005458
EAN: 2147483647
Year: 2004
Pages: 211

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