Slashdot Mirror
XML Encryption Broken, Need To Fix W3C Standard
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."
XML is like violence: if it doesn't solve the problem, use more!
Please correct me if I got my facts wrong.
Use encryption algorithms to encrypt data.
Use document formats to contain data.
But don't go creating specific encryption algorithms for specific document formats. That's just reinventing the wheel.
http://dl.acm.org/citation.cfm?id=2046756
"..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!
I was thinking the exact same thing. W.T.F....
XML is used in my projects all the time to transfer data around between processes but security is typically provided by SSL via HTTPS. Some of the extra security we have added is by encrypting specific fields, and we do that with AES 256.
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?
My biggest question is why was the standard even developed in the first place and who actually uses it?
Feature creep...
Depending on only encryption in this case proves to be weak. Using more layers, like IP firewalls and authorization will help mitigate this. The attacker needs to inject XML into the server to get error responses. If that's not possible due to a firewall, or replies will not be generated due to lack of authorization, it will be a lot harder to get data required to crack the encryption.
I was promised a flying car. Where is my flying car?
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.
"Little does he know, but there is no 'I' in 'Idiot'!"
The details are here --> http://dx.doi.org/10.1145/2046707.2046756 (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.
Colorless green Cthulhu waits dreaming furiously.
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.
For those without access to the ACM paywall, this is an extension of Rizzo-Duong practical padding oracle attack published last year (citation needed in the ACM paper?)
This, like many W3C specs from the early to mid 2000s, has nothing to do with the web and everything to do with enterprise backend stuff.
Some one corret this! :
Okay: Someone correct this:
Crumb's Corollary: Never bring a knife to a bun fight.