|< 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.
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:
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 >|