Some notes on the recent XML Encryption attack
At last week's CCS'11 conference, Tibor Jager and Juraj Somorovsky from Ruhr-Universität Bochum in Germany published a paper "How to Break XML Encryption." This paper is good cryptography research: By generalizing the ideas behind previous padding-based attacks, they have found a class of effective attacks against XML Encryption, when used with a particular class of encryption algorithms.
XML Encryption provides a framework that can be put around encryption algorithms. Commonly used: AES-CBC, the US Advanced Encryption standard in a particular mode called Cipher Block Chaining mode. The Bochum attack exploits certain properties of CBC mode when it's used in a context where an attacker can send modified versions of a ciphertext, and (in simple terms) can observe error messages or other behaviors that let them infer whether the resulting cleartext is valid XML -- or not. Cryptographers will talk about a chosen-ciphertext attack that exploits an oracle.
XML Encryption, in particular when used in a Web Services context, has these properties, and that's the case that the Bochum attack is geared toward.
Several things are remarkable about this attack.
First, it is independent of the cryptograhpic algorithm that's used -- it relies on the properties of CBC mode alone. It doesn't rely on any specific property of either AES or triple-DES.
Second, the attack leverages a few very general properties that arise easily in a context in which XML is encrypted (and specifically when XML Encryption is used), and when it is used in a complex protocol (e.g. SOAP). These properties are not limited to XML processing.
I would not be surprised to see variants of this attack applied to other protocols, when CBC mode is used in similar context.
What does this attack mean for XML Encryption deployments, and for the XML Encryption standard?
XML Encryption deployments should defend against being used as an oracle. There are several valid methods for that.
One is to choose an encryption mode for AES (e.g., Galois/Counter Mode) that guarantees both confidentiality and integrity, and lets the recipient discard the ciphertext that was modified by the attacker. AES-GCM is supported by the specification. Whether it is available in a particular deployment will depend on the particular product that's used.
Another defense is to use other methods for integrity protection of the encrypted message. An obvious possibility would be to use XML Signature on the encrypted material. The efficacy of this approach depends on the attacker's inability to strip off the signature or otherwise cause the recipient to just attempt decrypting the data: If the attacker can force a product to decrypt and parse the XML payload before the signature over the ciphertext is validated, then it's very likely that the attack will still be effective. We understand from the Bochum researchers that this variant of the attack is possible for a number of currently-deployed products. We also understand that vendors are working to fix this class of attacks.
To the standard itself: The XML Security Working Group is currently considering to change the set of mandatory to implement algorithms in XML Encryption, and to include AES-GCM (AES in Galois/Counter Mode) in that list. As far as the specification is concerned, this is a small change, exactly because XML Encryption is designed to work with arbitrary cryptographic algorithms.
There are two conclusions, then: The first one is that we have to thank the Bochum researchers for a significant result about CBC mode. The second is the importance of algorithm agility in cryptographic specifications: the ability to swap cryptographic algorithms as we learn more about them, without having to change the frameworks that we put around them. XML Encryption got that right.
This note is rather shameful. The attack isn't remarkable because if works without AES - not authenticating at all was a well known desaster long before XML encryption was standardised. The attack is remarkable because it is even more efficient than previously known attacks.
Whats really remarkable is that this wreckage of a protocol was ever released, given the amount of criticism about exactly this weakness. Criticism well known before it was standardised.
Fixing this by optionally allowing authenticating does not even fix the underlying problem. It's an improvement, but the weakness itself remains unless insecure modes are ruled out, thereby breaking compatibility.