Forgot your password?
typodupeerror
Security Bug Encryption IT

XML Encryption Broken, Need To Fix W3C Standard 80

Posted by timothy
from the let's-keep-this-in-the-open dept.
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."
This discussion has been archived. No new comments can be posted.

XML Encryption Broken, Need To Fix W3C Standard

Comments Filter:
  • 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.

    • by Haedrian (1676506)

      Apparently its a standard.

      http://en.wikipedia.org/wiki/Xml_encryption [wikipedia.org]

      Yes its a stub article. Nobody really cares.

      • 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.

        • by nzac (1822298)

          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:....What??? (Score:5, Interesting)

      by EdIII (1114411) on Saturday October 22, 2011 @03:43AM (#37802354)

      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)

        by dkf (304284) <donal.k.fellows@manchester.ac.uk> on Saturday October 22, 2011 @04:07AM (#37802420) Homepage

        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.

      • 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 :-)

    • by Darinbob (1142669)

      Feature creep...

    • by bytesex (112972)

      Well, you could ROT13 all the tag- and attribute names - that would be XML-encryption, no ?

      • by Anonymous Coward

        Or do it twice to be really secure!

    • Re: (Score:3, Informative)

      by gzipped_tar (1151931)

      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)

      by Anonymous Coward

      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.

    • by Anonymous Coward

      XHTML is a type of XML. Regular HTML though is a type of SGML (generic markup languages) and shares this parent with XML.

    • by Dwonis (52652) *
      XML security is stupid. Peter Gutmann explained why [auckland.ac.nz] way back in 2004.
    • by Dishwasha (125561)

      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.

  • by inglorion_on_the_net (1965514) on Saturday October 22, 2011 @03:11AM (#37802260) Homepage

    XML is like violence: if it doesn't solve the problem, use more!

    • 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)

        by Anonymous Coward

        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.

    • by Darinbob (1142669) on Saturday October 22, 2011 @03:45AM (#37802358)

      No, it's more like alcohol in that sense. The more you use the less you worry about the underlying problems.

  • by SpazmodeusG (1334705) on Saturday October 22, 2011 @03:17AM (#37802282)

    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.

    • by Anonymous Coward

      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

    • by jd (1658)

      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

      • by Schmorgluck (1293264) on Saturday October 22, 2011 @07:31AM (#37802990)

        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.

        • 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].

    • by mysidia (191772) *

      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

    • by Anonymous Coward

      XML-Enc does NOT create any new algorithms.

  • by fgrieu (596228) on Saturday October 22, 2011 @03:42AM (#37802352)

    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!

  • by dutchwhizzman (817898) on Saturday October 22, 2011 @03:47AM (#37802364)
    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.
    • by mysidia (191772) *

      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)

    by cachimaster (127194) on Saturday October 22, 2011 @05:45AM (#37802640)

    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?)

  • For variable length data.

  • I mean, see here [thedailywtf.com]...

  • 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
  • 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

    • by bk2204 (310841)

      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.

      • by dentin (2175)

        Understood. This is one of those 'minor technical' reasons I was talking about.

  • 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

    • by Tacvek (948259)

      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

  • 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.

All this wheeling and dealing around, why, it isn't for money, it's for fun. Money's just the way we keep score. -- Henry Tyroon

Working...