On Sun, Jul 17, 2005 at 11:30:31AM +0100, Bryan O'Donoghue wrote:
> > How is the AES assumption valid? And how do you then extrapolate a 2^128
> > keyspace? SSL and TLS (not TSL) support variable key sizes, as does the
> > AES algorithim.
>> 'Assuming' the AES algorithm as the method for encryption, the very
> _worst_ keyspace is 2^128. As you've already pointed out AES can have
> variable key sizes, with 128 bits, being the smallest.
And how is that assumption valid? There are other encryption algorithims
supported, with keysizes going as low as 40 bits. You seem to
acknowledge this lately, I'm just curious.
> > online banking are not your sessions being intercepted and deciphered,
> > but rather are to do with the security surrounding the endpoints.
>> Of course that is one of the obvious choices for obtaining ATM/Credit
> card details. Indeed, it would make much more sense, to attempt to
> compromise a bank's servers and circuitously obtain, Colm MacCartaigh's
> Credit Card number, at the server, then it would to attempt to brute
> force, captured SSL encrypted packets, even if we assume a pathetic 40
> bit key is in use, but really it's not a _likely_ delta for compromising
> online transactions.
This paragraph, like the rest of your response is mostly a mash of
contradictory, ill-judged, totally unjustified, transparent nonsense.
Luckily it serves as a good illustration of that, and allows to me to
avoid wasting time dealing with much of the nonsense item by item.
Within this paragraph, you;
1. Say that "of course" going for the server is "one of the
obvious choices"
2. Remark that "it would make much more sense"
3. But, then, for no reason I can see, say: "It's not a likely
delta"
Btw, you use words like delta and locus as if you think they impart some
meaning in the context that you use them. It's possible you're thinking
of vector.
Anyway, I'll deal with *some* of what you had to say, in the hopes of
maybe clearing things up for you. But this is almost certainly my last
mail, and I don't feel a need to defend anything I write against
whatever bizarre interpretations you come up with.
<snip>
> Indeed. I'll go out on a limb and claim that, my laptop, is reasonably
> secure.
I don't know what reasonably secure means. I certainly wouldn't make
such claims about my laptop.
> Moreover, from my point of view, as a security concerned user,
> my laptop has an inordinately high degree of verifiability, that an
> Automatic Teller Machine, which a recent thread on ILUG pointed out, is
> quite likely to be running a Windows permutation or an OS/2 permutation
> of some kind, and thus to me, as a user, is black box technology.
What you, yet again, appear to have completely missed is that in
any situation, be it online or otherwise, is that you have no visibility
behind the interface. Beyond the webserver, online banking is blackbox
technology, possibly involving the exact same Windows or OS/2
permutations.
However, which interface leaks more? 15 buttons and an ultra slow 30
year-old serial protocol or a markup language on top of a massive
request-liberal protocol on top of a massive and flexible crypto
standard on top of a TCP/IP stack?
<snip>
> Compare this to an ATM running OS/2. As has been reported in the news
> recently, it is quite possible that somebody has installed spy equipment
> on this ATM. I have no real way to verify that the ATM uses a secure or
> reasonably secure system, from itself, to the ATM's remote PSTN Server.
Firstly, you do. Or rather, persons capable infering making rational
conclusions from real-world information do. Some realworld facts; ATM
fraud costs banks money, Snooping/cracking/faking ATM <-> bank
communication is not common, and if it was, it would be reported. A
realworld conclusion; it's likely they expend some effort securing
themselves against such risks.
Secondly, forget even the above. You have no way of confirming that an
online system uses secure protocols to communicate with backend systems
either. So why does it matter when comparing them?
The spy attacks btw are a classic man in the middle. It's directly
comparable to the unicode DNS attacks for which SSL offers no
protection. Lets say I registered yourbank.net, but with a slightly
cryllic "a", and I constructed either a phishing attack or some ISP
cache poisoning (though likely with a HTTP 302 redirect) to get you
logging in to my domain, instead of the real yourbanknet. I just man in
the middle the session. It's pretty trivial, technologically, and very
practical.
In both this case, and the physical man in the middle (when fraudsters
put skimmers and cameras over physical ATM's) all that's happening is
that the real interface is being proxied. The only way of gaurding
against it is for users to be familiar with the real interface and know
how to verify it.
Online users should know how to verify it properly, and offline users
should give the cardslot a good tug before using it. Anyway, the point
is that SSL is no magic bullet, it offers zero protection here.
So, right there I've given you a direct way in which those kind of
attacks have a direct transpose (hey, if you're going to bandy about
mathsy words, I might aswell).
> As opposed to my Linux Laptop and a very well known publicly scrutinised
> security system (SSL). That, is in fact, the entire nexus of my
> argument. I patently think it's ludicrous and absurd to claim that an
> ATM brings better verifiability, when really, the only verifiability
> proffered is a claim by yourself and Mr Foster, that ATMs are /more/ secure.
I don't think I claimed that ATMs are more secure. I think I did explain
how it's a likely possibility though. I certainly didn't claim that
ATM's provide better verifiability, whatever it is you mean by that.
Either way, they have different risks, because they are in different
environments.
Neither ATM's nor Online banking provide you with any meaningful
verifiability of the transaction. The only thing SSL allows you to
verify is the communications channel between you and a webserver,
nothing else, it's not magic. As I've said, this is comparable to
verifying that your ATM session is not viewable by others.
ATM's can however provide a receipt, which is some small guard against
transaction loss.
> I wonder what, the banks would say ? I'm sure the banks would attest
> that /both/ systems are secure, but, I suggest that in the time that
> both ATMs and online banking have been in use, that it's far more likely
> that ATMs have been compromised then the online banking infrastructure.
That's hardly comparable, there are more ATM's for one thing. For
another, their failure modes are vastly different. If you compromise an
ATM with a skimmer, you might a few hundred accounts prior to detection,
with online banking it might be tens of thousands and it may not require
their participation.
> I'd really be interested in how you could explain how ATM->PSTN
> Server->Financial Mainframe [1] is less vulnerable then
> Firefox->Webserver->Financial Mainframe ?
I already have.
> In either case Colm, you have no visibility as to what the bank does
> with your data, once the remote entity has your critical data, it is
> quite simply the case that you must /trust/ the system involved, or not
> use it.
And yet you argue to the contrary above, and harp on about
verifiability.
> The only actual line of verifiability you have is that with online
> banking you can verify to a certain extent, that /your/ computer is safe
> and secured, from some sort of data graphing attack. You can verify to
> one level or another that /you/ are happy with SSL, /you/ can examine
> the certificate given out by the server, is who it claims to be.
>> None of that is true with ATM.
Pure nonsense. By applying sense, you can trivially verify the
authenticity of the ATM to at least the same extent as an SSL
certificate, especially if you know - it's physically attached to a
bank.
> > 1. ATM's have been around a lot longer, there is more study and
> > expertise around securing them and security ATM -> bank
> > communication.
>> That's a completely circular thing to say. cvs has been around for a
> long time too, and many people are expert in it's use and
> implementation. I'd hardly attempt to convince you that I thought it
> was a good idea to use it as an SCM, on that basis.
Well, security generally isn't the primary reason for choosing an SCM,
and the security provided by most SCM's is sufficient for their use. So
frankly, that's an idiotic comparison.
> > 2. ATM's generally have a much more limited range for input. The
> > ATM's themselves generally only have about 15 buttons, and the
> > communications protocols rarely have more than about a dozen or so
> > commands. Consider how much variability of input SSL/TLS, HTTP and
> > HTML combined have.
>> Linux operating systems are more complex then DOS. Again, *that's*
> hardly a reason, to use DOS in place of Linux is it? You'd hardly
> attempt to argue me around to believing that Linux is too /complex/
> and thus error-prone, would you ?
Linux is too complex and error-prone, but that's besides the point.
KISS.
> So you have stated. However since, one of my big issues with the ATM
> system versus Online banking is that, I have no idea how, ATMs
> communicate, or to what standards ATMs must meet, I can't reasonably
> state (as you seem to be able to do) that I have /any/ confidence
> whatsoever, in it's implementation.
Go learn.
> Quite clearly, Windows Operating systems are in use in the ATM world,
> and *that* fact alone really would give me pause. Professionally,
> speaking, if I had any choice in the deployment of a system, closed
> propiatery magic would not be my choice and certainly not for critical
> systems. An ATM, isn't an inflight computer, but, from an financial
> point of view, it *is* a critical system.
Sure, but it really doesn't give me cause for concern. Even if it's an
unpatched windows 95 box, I'm still not going to be worried. The risk is
strongly mitigated by the limited opportunity for malicious input.
> Do you actually, have any idea, *how* ATMs work at the encryption,
> protocol, failover level, that you can attest such systems to be a
> superior supplicant for online banking ?
I have an idea an understanding of how ATMs work, it's not a detailed
understanding, but I've seen the protocols, and read interesting
research and so on. But none of that understanding is all that relevant
to answering your question.
Online banking systems use the very same kind of protocols and
architectures to communicate with their backends, any vulnerabilities
there are common or comparable. The differences lie in the
user-interface.
1. At this level, it's *much* harder to compromise an ATM, because
the range of input is so small. How likely do you think it is
that some arrangement of keypresses will get you into an interface
where you can get away with something?
2. If an ATM is compromised, say with a skimmer, or even with a
successful attack along the lines I just mentioned, it's *much* easier
to tell. After all, a compromised webserver can look just like a clean
one. With a physical attack, there is always something physically
different. And for a magic keystroke attack, how likely is it
then that a successful attack can return right back to a normal-looking
fu;ly functional interface?
3. Take the busiest ATM in the country, I've no idea where that
is, but do you really think it gets more users per day than the
online banking website?
> If so, could you actually provide some data, so that others may
> verify, your claims, or is it simply now the case, that having made
> the claims, you will go to find the corroborating evidence ?
No. My claims are based on simple, rational, trusted principles,
which frankly it's your job to dismiss.
I'm *more* than comfortable allowing the few readers of this thread to
make their own judgements about which one of us is making a rational
argument that makes sense.
> From where I sit, it seems like an entirely, self righteous position
> to claim that Linux Machine + SSL Enabled Webserver is a /less/ secure
> delta then (Windows NT || OS/2) ATMs, with unknown/amorphous
> communications and encryption mechanisms.
Well, you must be sitting in bizarro upside-down world where someone
actually made such a claim, or where someone other than yourself
considered those systems in any way comparable.
--
Colm MacCárthaigh Public Key: colm+pgp at stdlib.net
Maintained by the ILUG website team. The aim of Linux.ie is to
support and help commercial and private users of Linux in Ireland. You can
display ILUG news in your own webpages, read backend
information to find out how. Networking services kindly provided by HEAnet, server kindly donated by
Dell. Linux is a trademark of Linus Torvalds,
used with permission. No penguins were harmed in the production or maintenance
of this highly praised website. Looking for the
Indian Linux Users' Group? Try here. If you've read all this and aren't a lawyer: you should be!
