Boffins crack e-commerce encryption

German computer scientists have cracked components of an encryption system used to securely exchange data between e-commerce and banking systems. Boffins from the Ruhr University of Bochum (RUB) have devised a technique partly based on analysing error messages returned when carefully modified cipher text is submitted to a web …

[Anonymous Coward]

Links

English summary of RUB team announce: http://aktuell.ruhr-uni-bochum.de/pm2011/pm00330.html.en

Their paper: http://www.nds.rub.de/media/nds/veroeffentlichungen/2011/10/22/HowToBreakXMLenc.pdf

[Michael Wojcik]

Thanks to AC above for posting the link to the paper. I just skimmed it, but here are some comments on the article:

- The attack applies to XML Encryption with any block cipher running in CBC mode. The current XML Encryption standard permits AES and 3DES as block ciphers, and CBC is the only mode it allows. So this also applies to 3DES-CBC.

- "An RSA key and X.509 certificates" is of course a largely meaningless phrase in this context. (And yes, I saw this came from the H Security piece, which is equally rubbish.) RSA is an asymmetric algorithm, so its keys come in pairs; X.509 certificates can be used for many purposes. The paper doesn't mention asymmetric encryption (or stream ciphers, but XML Enc currently doesn't support any); it's only concerned with block ciphers. Encrypting a message of more than trivial length with an asymmetric algorithm is generally a pretty dumb thing to do, though XML Enc does allow this. In the real world, the only place you're likely to see RSA used with XML Enc is to transport session keys, using PKCS#1 or OAEP.

- Here's the essence of the attack, for non-crypto folks. CBC has a well-known weakness: if you tweak the ciphertext with XOR, and someone tells you whether it decrypts "correctly", you can derive some information about the plaintext. The authors of this paper have developed some clever new attacks using this weakness that apply specifically to XML Enc. The trick is getting the server to try to decrypt the tweaked ciphertext, and having it tell you whether there are improperly encoded characters in it - that's the side channel.

- The authors show that enabling XML Signature does NOT mitigate against the attack. You'll see from the previous point, though, that changing the server to not tell the client why it's rejecting a request disables the side channel and DOES mitigate the attack (again, as noted by the authors). So that's one short-term option. It makes things harder on legitimate users, but who cares about them, eh?

- But note that's "mitigates", not "prevents". The authors make some good suggestions for opening other side channels.

- The attack takes, on average, 14 queries by the attacker *per byte of cracked plaintext*. Now, a knowledgeable attacker won't need to decrypt all of the ciphertext - XML is hugely redundant - but it should be possible to detect a simplistic attack like this heuristically and block it. So work on those Snort rules.

But in the longer term, it does look like XML Encryption is broken and will have to be fixed in the standard by a significant change.