XML Encryption Broken, Need To Fix W3C Standard 80
gzipped_tar writes "Researchers from Ruhr University Bochum demonstrated the insecurity of XML encryption standard at ACM Conference on Computer and Communications Security in Chicago this week. 'Everything is insecure,' is the uncomfortable message from Bochum. As pointed out by the Ars Technica article, XML Encryption is used widely as part of server-to-server Web services connections to transmit secure information mixed with non-sensitive data, based on cipher-block chaining. But it is apparently too weak, as demonstrated by Juraj Somorovsky and Tibor Jager. They were able to decrypt data by sending modified ciphertexts to the server by gathering information from the received error messages. The attack was tested against a popular open source implementation of XML Encryption, and against the implementations of companies that responded to the responsible disclosure — in all cases the result was the same: the attack worked. Fixing the vulnerability will require a revision of the W3C XML encryption standard, Somorovsky said. The researchers informed all possibly affected companies through the mailing list of W3C, following a clear responsible disclosure process."
The abstract of the article is here (Score:5, Informative)
http://dl.acm.org/citation.cfm?id=2046756 [acm.org]
"..we describe a practical attack on XML Encryption, which allows to decrypt a ciphertext by sending related ciphertexts to a Web Service and evaluating the server response. We show that an adversary can decrypt a ciphertext by performing only 14 requests per plaintext byte on average."
Impressive!
Re:....What??? (Score:5, Informative)
Till today I did not even know there *was* an encryption standard for XML docs and I still don't know *where* to use it. Is it built in to PHP? Is it part of the standard parsers out there?
It's certainly not in a majority of them.
My biggest question is why was the standard even developed in the first place and who actually uses it?
It was developed to allow a document to be handed round with parts of it shrouded so that only one individual (or service) can read it while still allowing other parts of the document to be read by anyone. AIUI, it's relevant in complex uses of SOAP where you've got a complex message bus in use and where the endpoints don't particularly trust the conveying services. Some of the B2B stuff is a bit that way inclined. I've never needed it myself though (unlike XML Signature, which is closely related and much more relevant since guaranteeing document integrity makes a lot of sense for things like invoices).
I bet IBM has a full implementation of this. It's exactly the heavyweight thing that's right up their street.
Re:....What??? (Score:3, Informative)
The details are here --> http://dx.doi.org/10.1145/2046707.2046756 [doi.org] (as posted by a commenter below) Subscription is required to read the full paper, I suppose.
I'm not a security expert, just an enthusiastic, so what scarce bits I understood from the article may be wrong but they're here. The attack is a side-channel exploit. It doesn't matter what underlying encryption algorithm one actually use as long as it's a block cipher. The exploit relies on two things, i.e. the cipher-blocking chaining (CBC) and the error messages returned by the server. The CBC has weakness, i.e. a recursion relation between the ciphertext and the plaintext that allows the latter to be figured out by the attacker. The error messages returned by the server are usually too informative so that the attacker can use the information to find the initial values required to break CBC. I guess both CBC and this smart behavior of the error handling are mandated by the standard, and that's why they're calling for a rewrite of the standard itself.
Re:....What??? (Score:2, Informative)
The attack isn't waged against a specific cypher. Rather, it's waged against how partially filled data blocks (at the end of the encrypted stream) are handled.
Also, HTML is not a type of XML (although XHTML is) but a dented subset of SGML.
Padding Oracle (Score:5, Informative)
For those without access to the ACM paywall, this is an extension of Rizzo-Duong practical padding oracle attack [usenix.org] published last year (citation needed in the ACM paper?)