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."
....What??? (Score:2)
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.
Re: (Score:2)
Apparently its a standard.
http://en.wikipedia.org/wiki/Xml_encryption [wikipedia.org]
Yes its a stub article. Nobody really cares.
Re: (Score:2)
But that doesnt explain why the article would be relevant for all of XML-enc: It mentions weaknesses in CBC, while everything Ive read leads me to believe that CBC is not necessary.
Re: (Score:2)
From my very limited self taught cryptography knowledge it appears to be some form of Chosen ciphertext attack [wikipedia.org] or at least involves the idea. I think a poor CBC implementation or using it inappropriately would make this possible.
Some one corret this! : i think if you can intercept the encrypted message you can modify it (so that it could still conform to some parts of the protocol at the other end (the CBC problem)) and resend a different modification a number of times and from the replies be able to dete
Re: (Score:3, Funny)
Some one corret this! :
Okay: Someone correct this:
Re:....What??? (Score:5, Interesting)
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?
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: (Score:3)
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.
Re: (Score:2)
It's a really bad idea to have encryption at such a high level, especially when it's optional and inefficient. Encryption is one of those things that, if it is to work at all, it has to be absolutely right. Mistakes aren't optional.
It also complicates certification. Encrypting at a single point means only that one point needs to be FIPS-certified for US Govt work, for example. Other certification programs are going to be similar - the more potential points of failure, the more that has to be checked, the mo
Re: (Score:1)
It can be a very good idea to have encryption within data, depending on whether or not you trust the transport infrastructure, etc.. SSL is great, but it's a point-to-point protocol. When you send plain-text data over SSL, you know that the first jump in the network is secured (for some meaning of the word 'secured'), but have no control after that. If the data layer is encrypted, then you retain the ability to ensure the integrity of the data from application to application regardless of the transport, mid
Re: (Score:2)
What sort of SSL are you using that's not end-to-end (i.e. application to application, as you say)? Because mine sure doesn't work that way.
It's also not clear why, given a composite document, each of the component providers couldn't provide separate signatures for their pieces without any particular support at the composite level -- it's pretty trivial to embed a signatures in a JPEG, for example, and then you'd continue to get the signature with the image even if it was copied outside of the composite doc
SAML (Score:1)
SAML [wikipedia.org], which is widely used for federated identity [wikipedia.org] (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 :-)
Re: (Score:3)
Feature creep...
Re: (Score:2)
Well, you could ROT13 all the tag- and attribute names - that would be XML-encryption, no ?
Re: (Score:1)
Or do it twice to be really secure!
Re: (Score:2)
Re: (Score:2)
I never saw that movie. Was it good?
Re: (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)
Re: (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.
Re: (Score:1)
XHTML is a type of XML. Regular HTML though is a type of SGML (generic markup languages) and shares this parent with XML.
Re: (Score:2)
Re: (Score:2)
It's typically used in conjunction with ebXML http://en.wikipedia.org/wiki/EbXML [wikipedia.org] in the healthcare and other market segments that are heavily regulated.
Never was a good idea (Score:4, Funny)
XML is like violence: if it doesn't solve the problem, use more!
Re: (Score:2)
XML is like violence: if it doesn't solve the problem, use more!
Is it just me, or did this saying lose its pithiness about 6 months ago?
Re: (Score:2, Insightful)
XML is like violence: if it doesn't solve the problem, use more!
Is it just me, or did this saying lose its pithiness about 6 months ago?
I'm afraid it's just you. For the rest of us, it lost its pithiness 6 years ago.
Re:Never was a good idea (Score:5, Funny)
No, it's more like alcohol in that sense. The more you use the less you worry about the underlying problems.
Why is there such a thing as XML encryption? (Score:5, Insightful)
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.
Re: (Score:1)
It was part of all the enterprise-style, middleware-friendly WS-* standards being juggled by IBM and Microsoft in the past decade, to allow message-level security (encryption and/or signatures) on selective parts of the XML payload inside of SOAP while still allowing message routers to muck around with the SOAP message traffic.
Rather than sending plain SOAP over HTTPS, they'd send SOAP with XML security over arbitrary transports, persist messages, etc. Proxying/intermediation is as much an obsession with t
Re: (Score:2)
XML has all kinds of extras - XML-RPC, for example. A list of XML markup languages [wikipedia.org] at Wikipedia suggests there are waaaaaaay too many. There are even two different competing standards for marking up web pages for search engines (besides the archaic metatags) - Schema [schema.org], a Google/Microsoft invention, and DublinCore [dublincore.org], invented by everyone else and a kitchen sink. Of course, XML isn't the only meta-language these days. RDF is the basis for SparQL - the W3C's answer to Cold Fusion.
The entire point of HTML was that
Re:Why is there such a thing as XML encryption? (Score:5, Insightful)
XML is very useful as an unified markup language. I'm fond of its versatility, relative legibility, and yeah, the various applications that are made to apply to itself especially Schema and XSLT. But it's not relevant to everything, and theres a fad to use it even where it's stupid.
Some times ago, in GNU/Linux Magazine France, someone who signed "Jean-Pierre Troll" wrote an article to protest against the tendancy to put XML everywhere. He for example rightfully shot down XML as a programming language, and as a way to carry binary data. Even for the transmission of structured text data, JSON is a better solution in most cases.
Said Jean-Pierre Troll wrote that the best reason to use XML is to be able to transform the data with XSLT. I tend to agree. If this possibility is not to be considered, then XML may not be the best solution.
Re: (Score:2)
It can only be used as such as a funny intellectual exercise. It really isn't convenient for anything else than transforming XML documents into something else (including, but not limited to, other XML documents).
Or rather, to make it fulfill its purpose, you have sometimes to consider XSLT as a functional language. It rarely happens, but I had once to convert a DBDesigner [fabforce.net] file into a set of HTML entity documentations, and if I hadn't been taught in CAML and functional programming fifteen years ago, I'd like
Re: (Score:1)
Re: (Score:2)
There's actually a quite remarkable web server [pugo.org] written in postscript.
Re: (Score:2)
Some times ago, in GNU/Linux Magazine France, someone who signed "Jean-Pierre Troll" wrote an article to protest against the tendancy to put XML everywhere. He for example rightfully shot down XML as a programming language, and as a way to carry binary data. Even for the transmission of structured text data, JSON is a better solution in most cases.
You can find it here [blogspot.com].
Re: (Score:3)
But don't go creating specific encryption algorithms for specific document formats. That's just reinventing the wheel.
XML-Enc does not create specific encryption algorithms for specific document formats.
It sounds to me like a server-side application of some sort is using XML-Enc and CBC mode in a poor way.
Don't pick one shared key which you reuse every time and give the user error messages based on the ciphertext.
Use public key crypto and a different shared key every time you encrypt a document.
P
Re: (Score:1)
XML-Enc does NOT create any new algorithms.
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: (Score:2)
If you're interested, here's a summary of the attack:
http://practicalcrypto.blogspot.com/2011/10/attack-of-week-xml-encryption.html [blogspot.com]
More layers required (Score:4, Insightful)
Re: (Score:1)
XML is like onions.
"If it doesn't work, use more?"
Re: (Score:2)
Using more layers, like IP firewalls and authorization will help mitigate this.
If network security is an adequate bolt-on fix for the situation, then why would you be using XML encryption in the first place?
If you are transferring data over a public network, IP firewalls and authorization are not sufficient. The source/destination of traffic can be determined by a Man-in-the-Middle for the purposes of IP spoofing just as easily as the encrypted ciphertext can be illicitly acquired in that manner.
On th
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?)
Re: (Score:1)
Never mind, just found like three citations to Rizzo-Duong paper in this paper.
Don't use block ciphers (Score:2)
For variable length data.
XML encryption is insecure. (Score:2)
I mean, see here [thedailywtf.com]...
Use two-pass PKI? (Score:2)
<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
Why do standards use chaining modes? (Score:2)
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 ch
Re: (Score:2)
CBC, the most common chaining mode, has been around for a long time and has been studied a lot. So people use it a lot in protocols and specifications, and so people think it's a good idea to use it more, and so on. This is the same reason RSA has been used a lot. The problem with counter mode is that without a MAC or MIC, it is trivial to modify the plaintext without detection.
Re: (Score:2)
Understood. This is one of those 'minor technical' reasons I was talking about.
Only from timothy (Score:2)
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 on
Re: (Score:2)
Many of these are software stacks that handle the decryption, but then pass the plaintext on to custom code to use. That custom code will almost invariably leak information, and there is nothing the stack manufacture can do to stop it.
It is not feasible to require the custom code return only success or failure, and to always take constant time for all messages of a specified size. If the time was non-constant then that would almost certainly leak the necessary information. If the response for invalid encodi
CBC is weak no matter how you analyze it (Score:1)
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.