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."
...
RFC4880 FTW!
A standard nobody has ever heard of is horribly broken. News at 11.
Seriously, WTF? Hands who ever heard of "XML encryption." I haven't, but this just filled two spots on my slashdot buzzword bingo drinking card.
As far as I know, XML is a class of languages which use tags and elements. HTML is, AFAIK, a type of XML. I have never heard of "XML encryption", except that a google search shows w3c recommendations and documentation for how to store encrypted data. The data itself, however, appears to use whatever cipher you want-- you could use AES CBC 128, for example, or Threefish if you desired.
Or am I missing something here? The article is quite scant on details.
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!
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?
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?)
For variable length data.
Take off every 'sig' !!
I mean, see here...
Non impediti ratione cogitationus.
I have never used XML Encryption, however, why does is it using a SHARED key??? Sure, it might be heavier on the transaction, but this is about security first of all or no? Then we find:
<CreditCard Limit='5,000' Currency='USD'>
<Number>4019 2445 0277 5567</Number>
<Issuer>Example Bank</Issuer>
<Expiration>04/02</Expiration>
</CreditCard>
Is in the Example encrypted as
<EncryptedData Type='http://www.w3.org/2001/04/xmlenc#Element'
xmlns='http://www.w3.org/2001/04/xmlenc#'>
<CipherData>
<CipherValue>A23B45C56</CipherValue>
</CipherData>
</EncryptedData>
(The ChiperValue appear to be an example only as the same text appear in other examples with other data). But more than 50% of the text is tags, and you know the location of those tags... It seems obvious this is a problem.</p>
<p>It can appear that PKI would greatly improve this situation as it is TWO PASS - first encrypted with the servers private key, then the result encrypted with the recipient's public cert. In other words, the end and start tags would be gibberish between the passes.
Another method is to implement compression in the spec as well, however that would be a can of worms in it self as you would need some way to specify what compression algorithm was used, which likely would require even more clear text XML tags...
Something that has always confused me about crypto implementations is why chained block modes and ciphers with an actual 'inverse' operation (like AES) are used. I understand the technical arguments and I know that in some cases, chained modes really are the optimal solution; but they aren't "so optimal" that they're far and away the best choice. Usually they're only optimal in some minor technical fashion.
However, most of the attacks I've seen against ciphers involve these modes. For some reason, the chained construction is simply harder to implement and design around. The few systems I've designed used counter mode, because it's just easier to think about and design against, and can use a cipher without an inverse. It does have more overhead, but if you're encrypting for provable security you'd think that some overhead would be expected.
However, as I understand it, counter mode wouldn't really have helped here unless some kind of replay prevention and MIC checks were also used, which I believe is infeasible due to the XML design space. The spec itself simply leaks the data due to data formatting stupidity and server responses; no amount of crypto will help if your server basically tells you the data bits.
Alter Aeon Multiclass MUD - http://www.alteraeon.com
This is an example of people talking about security that don't actually understand it.
The servers error messages divulging information via ERROR MESSAGES is a implementation mistake, not a design error of the protocol.
Its like probing websites to determine if an account exists by trying to login and looking at the difference between 'bad password' responses. A good implementation always says the same thing regardless of why authentication fails 'invalid user name or password'. It doesn't tell you which one is wrong. On the other hand, what this article is about is a particular server/parser implementation that instead responds and says 'your password is 8 characters, you only gave us 3, try again!'
Not hard to resolve.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
With AES256 being a government standard for 10 years, why would anyone recommend CBC (which was considered weak long before AES was denoted the standard) as an encryption method?
You could use Diffie-Hellman key exchanges (http://en.wikipedia.org/wiki/Key_exchange#Diffie.E2.80.93Hellman_key_exchange) to strengthen this, but that wouldn't necessarily prevent the attack that was used in the demonstration.
You should find a pdf of the paper here: http://www.nds.rub.de/research/publications/breaking-xml-encryption/
SAML, which is widely used for federated identity (to be concise, OpenID+Oauth on steroids), uses it. There is some sense to encrypt parts of the SAML assertion, since different information may be of interest to different parties.
I am not sure if SAML is affected by the attack. And most of the time it is used over HTTP/SSL, which would probably reduce attacks opportuntities
Come on, make me "score: 5 Informative", I am worth it :-)
Here's the actual paper: http://www.nds.rub.de/research/publications/breaking-xml-encryption/