Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

XML Encryption Broken, Need To Fix W3C Standard

timothy posted more than 2 years ago | from the let's-keep-this-in-the-open dept.

Security 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."

cancel ×

80 comments

Who uses that? (0)

Anonymous Coward | more than 2 years ago | (#37802214)

...

Re:Who uses that? (0)

Anonymous Coward | more than 2 years ago | (#37802380)

They were able to decrypt data by sending modified ciphertexts to the serve by gathering information from the received error messages.

They were able to decrypt data by sending modified ciphertexts to the serve by gathering information from

sending modified ciphertexts to the serve

A H A H A H A WH A T A L O S ER T I M O THY I S ! H E C AN 'T EVE N SP E L L !

Re:Who uses that? (-1)

Anonymous Coward | more than 2 years ago | (#37802438)

Nice catch. Timothy confirmed for a fat retard.

Re:Who uses that? (-1)

Anonymous Coward | more than 2 years ago | (#37802668)

Nice catch. Timothy confirmed for a fat retard.

if he is american of course he is fat. aren't all americans fat? i mean if you're stupid and oblivious and have no situation awareness and no comprehension that other cultures do things differently then you might as well be fat too. they go together nicely.

the whole "don't eat more calories than you use" thing takes a real rocket scientist to grasp doesn't it, america? or how about the whole "when it's just a little flab, that's the time to do something about it before you balloon into a 300-lb behemoth" thing? yeah that's real tough too.

Re:Who uses that? (-1, Troll)

Anonymous Coward | more than 2 years ago | (#37802788)

Can it, buttmunch. I'm only fat because the niggers gave me a glandular disorder so I couldn't overthrow their jewish masters.

Just use OpenPGP (0)

Anonymous Coward | more than 2 years ago | (#37802220)

RFC4880 FTW!

Shocking (0)

Anonymous Coward | more than 2 years ago | (#37802230)

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.

....What??? (1)

LordLimecat (1103839) | more than 2 years ago | (#37802240)

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:....What??? (1)

Haedrian (1676506) | more than 2 years ago | (#37802256)

Apparently its a standard.

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

Yes its a stub article. Nobody really cares.

Re:....What??? (1)

LordLimecat (1103839) | more than 2 years ago | (#37802280)

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:....What??? (1)

nzac (1822298) | more than 2 years ago | (#37802754)

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 determine a key from it. Having a protocol that can't determine that the message is not authentic and sends back a reply is another part of the weakness.

Re:....What??? (2, Funny)

grcumb (781340) | more than 2 years ago | (#37805076)

Some one corret this! :

Okay: Someone correct this:

Re:....What??? (5, Interesting)

EdIII (1114411) | more than 2 years ago | (#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??? (4, Informative)

dkf (304284) | more than 2 years ago | (#37802420)

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

2fuf (993808) | more than 2 years ago | (#37803114)

Ah, part of SOAP... That's why nobody knows wtf it is.

Re:....What??? (0)

Anonymous Coward | more than 2 years ago | (#37803300)

It's mostly used as part of WS-* (aka WS-Deathstar).

Re:....What??? (0)

justforgetme (1814588) | more than 2 years ago | (#37803708)

Hmm... I really struggle to get its application though.
In my limited web dev experience when you end up with a response that could benefit from being partially encrypted you usually are just doing it wrong. I mean, it's responses anyway so why not have two of them?
Anyway, I have only used XML only very very rarely if you don't count HTML so I'm not qualified to judge.

Re:....What??? (2)

BZ (40346) | more than 2 years ago | (#37803846)

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:....What??? (0)

Anonymous Coward | more than 2 years ago | (#37802636)

SSL is transport level encryption. XML encryption standards focus on encrypting the whole XML message before the transport level, so it can retransmitted all the time as encrypted. The message can also be stored as encrypted.

The idea is (for example), SOAP messages can be transmitted using e-mail or other transport, without the message being compromised. Don't ask me if that makes any sense though :D

Having said that from my experience, XML encryption fails because it is VERY inefficient in large quantities of messages.

Re:....What??? (1)

jd (1658) | more than 2 years ago | (#37802710)

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 more expensive it'll be and the more likely it'll be slipped under the radar rather than scrutinized properly. That's Bad.

Re:....What??? (1)

Anonymous Coward | more than 2 years ago | (#37802958)

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, middleware, ISP, etc.. You can also sign fragments of the data in a composite message. A medical record could be signed by one authority, whilst an attached image can be signed by a second authority, and the entire message can be signed by yet another authority. Sometimes the trust chain for data fragments are important.

XML encryption is only optional in the sense that someone decides whether to use/require/tolerate it or not. Whether or not it's inefficient is a matter of implementation, and requirements. There are a lot of industry standards based around XML data representations. Including much of the finance industry. The WS-Security family of specifications build on XML encryption for SOAP based messaging. SOAP may be a heavy weight protocol, but it is used.

XML based encryption is often (usually?) used in combination with SSL. That gives a best-of-both worlds messaging option. But XML encryption is about more than just XML based messaging - it can (at least in theory) be used anywhere that XML is used. In my experience it's mostly about signing data fragments, but it can be about privacy.

Re:....What??? (1)

profplump (309017) | more than 2 years ago | (#37807332)

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 document, which seems much more useful for trust-chain usage.

Re:....What??? (0)

Anonymous Coward | more than 2 years ago | (#37808628)

It is indeed pretty trivial to sign component parts of a message. And the XML encryption standard is how that's simple mechanism is implemented for XML. Separately signed XML fragments can be composed together into a compound document. There's no rocket science involved, just a specification to ensure that everyone knows the protocol. XML doesn't have to represent a document of course, it could be an identity token (such as a SAML assertion), a transaction token, personal credit card details, or whatever. The standard applies to all XML data representations.

It's not hard to imagine a software system involving more that 2 endpoints, where the data gets forwarded from one business partner to another business partner. Even within your a single business it's reasonable to require certain data fragments to remain independently secured from the moment they enter the system to the moment they're persisted to the database. If the data is signed (whether the data is XML or anything else) then that requirement can be achieved.

Re:....What??? (0)

Anonymous Coward | more than 2 years ago | (#37805368)

Wow. The attack vector used by Manning was exploited in part because InfoPath, by default, does not use any encryption for the form/report data which is stored as a plain-text xml file. XML-encryption can be extended to other/multiple encryption types. Just because the xml files were on SIPRnet does not mean the xml/data should not have been encrypted. There are better ways to encrypt an xml file, or InfoPath data files and form files, but that requires thinking outside of OOTB.

Just for fun, I wonder if this article names someone that was allegedly helping Manning.

SAML (1)

manu0601 (2221348) | more than 2 years ago | (#37807578)

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:....What??? (2)

Darinbob (1142669) | more than 2 years ago | (#37802356)

Feature creep...

Re:....What??? (1)

bytesex (112972) | more than 2 years ago | (#37802390)

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

Re:....What??? (1)

Anonymous Coward | more than 2 years ago | (#37802546)

Or do it twice to be really secure!

Re:....What??? (1)

Belial6 (794905) | more than 2 years ago | (#37802616)

I like to be REALLY secure, so I ROT26 my data. For the really sensitive stuff, I'll even go so far as to ROT52 it.

Re:....What??? (1)

BisexualPuppy (914772) | more than 2 years ago | (#37802654)

That was very funny in 1992, so please shut up.

Re:....What??? (1)

JustOK (667959) | more than 2 years ago | (#37803200)

I never saw that movie. Was it good?

Re:....What??? (3, Informative)

gzipped_tar (1151931) | more than 2 years ago | (#37802430)

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??? (2, Informative)

Anonymous Coward | more than 2 years ago | (#37802440)

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:....What??? (1)

Anonymous Coward | more than 2 years ago | (#37802650)

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

Re:....What??? (1)

jsprenkle (2009592) | more than 2 years ago | (#37803342)

Yeah, really! WTF?

XML was designed to be readable by humans. The opposite of encryption. There are lots of good encryption methods available already.

Slashdot really needs an editor to weed out stupid stories

Re:....What??? (1)

Dwonis (52652) | more than 2 years ago | (#37804226)

XML security is stupid. Peter Gutmann explained why [auckland.ac.nz] way back in 2004.

Re:....What??? (1)

Dishwasha (125561) | more than 2 years ago | (#37805238)

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 (3, Funny)

inglorion_on_the_net (1965514) | more than 2 years ago | (#37802260)

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

Re:Never was a good idea (0)

Anonymous Coward | more than 2 years ago | (#37802288)

XML is the duct tape of the IT world.

Re:Never was a good idea (0)

Anonymous Coward | more than 2 years ago | (#37802512)

Duct tape is sometimes useful. XML never is.

Re:Never was a good idea (1)

FrootLoops (1817694) | more than 2 years ago | (#37802304)

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:Never was a good idea (2, Insightful)

Anonymous Coward | more than 2 years ago | (#37802320)

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 (4, Funny)

Darinbob (1142669) | more than 2 years ago | (#37802358)

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

Re:Never was a good idea (0)

Anonymous Coward | more than 2 years ago | (#37802792)

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

I thought that was supposed to be tax cuts.

Why is there such a thing as XML encryption? (4, Insightful)

SpazmodeusG (1334705) | more than 2 years ago | (#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.

Re:Why is there such a thing as XML encryption? (1)

Anonymous Coward | more than 2 years ago | (#37802336)

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 these guys as XML itself.

Re:Why is there such a thing as XML encryption? (0)

Anonymous Coward | more than 2 years ago | (#37802348)

At the time this spec was created at the W3C, everything had to have an XML angle to it.

Re:Why is there such a thing as XML encryption? (0)

Anonymous Coward | more than 2 years ago | (#37802372)

The xml encryption and signing specs deal with the fact the that xml has very loose whitespace and order rules and so needs tightening when it comes to signing and encryption.

Re:Why is there such a thing as XML encryption? (1)

jd (1658) | more than 2 years ago | (#37802658)

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 it was simple. A billion custom standards, many of which require some sort of library or other handler specifically for them, isn't simple. I'm not clear that any of them provide anything that cannot be provided more efficiently, more effectively and in a more distributed/cloud-friendly manner using servers and utilities that have been around longer, been tested more thoroughly and are genuinely "enterprise-ready" (which I'll take to mean Mr Spock wouldn't object to installing it).

Re:Why is there such a thing as XML encryption? (4, Insightful)

Schmorgluck (1293264) | more than 2 years ago | (#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.

Re:Why is there such a thing as XML encryption? (0)

Anonymous Coward | more than 2 years ago | (#37803228)

If you are against using XML as a programming language, you should consider that XSLT is a Turing-complete programming language.

Re:Why is there such a thing as XML encryption? (1)

Schmorgluck (1293264) | more than 2 years ago | (#37803780)

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 likely have been stumped on that problem.

But devicing an XML syntax to be considered a full-blown programming language that isn't specifically designed to handle XML structures? Unless it's toying around with theories, it sounds like a waste of time to me.

Re:Why is there such a thing as XML encryption? (1)

m50d (797211) | more than 2 years ago | (#37805778)

Postscript is also turing-complete. It's still a) a good format for some things and b) a terrible general-purpose programming language

Re:Why is there such a thing as XML encryption? (1)

jd (1658) | more than 2 years ago | (#37806718)

There's actually a quite remarkable web server [pugo.org] written in postscript.

Re:Why is there such a thing as XML encryption? (0)

Anonymous Coward | more than 2 years ago | (#37805700)

the best use of XML is so you don't have to invent your own ad-hoc text file format and introduce your own conventions about all the corner cases.

Re:Why is there such a thing as XML encryption? (1)

arglebargle_xiv (2212710) | more than 2 years ago | (#37811956)

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:Why is there such a thing as XML encryption? (2)

mysidia (191772) | more than 2 years ago | (#37803076)

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.

Personally... I think the XML-Enc folks ought to have piggy backed on a proven cryptosystem such as OpenPGP as the basis on which ciphertext and signature XML elements are to be built.

Re:Why is there such a thing as XML encryption? (1)

Anonymous Coward | more than 2 years ago | (#37806030)

XML-Enc does NOT create any new algorithms.

The abstract of the article is here (5, Informative)

fgrieu (596228) | more than 2 years ago | (#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!

Re:The abstract of the article is here (0)

Anonymous Coward | about 2 years ago | (#37830686)

So, to decrypt a 512 byte message you'd need to send 7168 requests? It seems like this attack could be detected and blocked.

More layers required (3, Insightful)

dutchwhizzman (817898) | more than 2 years ago | (#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.

Re:More layers required (0, Troll)

Anonymous Coward | more than 2 years ago | (#37802986)

A- XML is like onions.
B- It has layers?
A- No, it smells.

Re:More layers required (1)

WWWWolf (2428) | more than 2 years ago | (#37803098)

XML is like onions.

"If it doesn't work, use more?"

Re:More layers required (0)

Anonymous Coward | more than 2 years ago | (#37803314)

No, that's brute force.

Onions are "the more you work with them, the harder you weep".

Re:More layers required (1)

mysidia (191772) | more than 2 years ago | (#37803096)

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 the other hand, if you are emitting XML encrypted over a VPN, then you are doing the encryption work twice, and one of those times isn't adding useful protection...

Padding Oracle (5, Informative)

cachimaster (127194) | more than 2 years ago | (#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?)

Re:Padding Oracle (1)

cachimaster (127194) | more than 2 years ago | (#37802660)

Never mind, just found like three citations to Rizzo-Duong paper in this paper.

Don't use block ciphers (1)

FormOfActionBanana (966779) | more than 2 years ago | (#37802930)

For variable length data.

Re:Don't use block ciphers (0)

Anonymous Coward | more than 2 years ago | (#37803768)

Block ciphers are fine. That's what counter mode is for.

XML encryption is insecure. (1)

RyuuzakiTetsuya (195424) | more than 2 years ago | (#37803258)

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

Use two-pass PKI? (1)

kandresen (712861) | more than 2 years ago | (#37803558)

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

Why do standards use chaining modes? (1)

dentin (2175) | more than 2 years ago | (#37804230)

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.

Re:Why do standards use chaining modes? (1)

bk2204 (310841) | more than 2 years ago | (#37804494)

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:Why do standards use chaining modes? (1)

dentin (2175) | more than 2 years ago | (#37806180)

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

Only from timothy (1)

BitZtream (692029) | more than 2 years ago | (#37804498)

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.

Re:Only from timothy (1)

Tacvek (948259) | more than 2 years ago | (#37811648)

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 encoding were allowed to differ from the response for successful decoding but invalid message that would also leak the necessary information.

If the standard had said AES-EAX or AES-OCB as the required cypher, then if the stack is well implemented the only information that might be leaked to an attacker is that the modified message was rejected for being modified (which is information the attacker already knew and which leaks no information about the original message itself).

CBC is weak no matter how you analyze it (1)

Foolomon (855512) | more than 2 years ago | (#37805422)

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.

Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...