Financial Cryptography

According to my wife's pal who is a bank manager at Lloyds, they've had this technology for managers for quite a while, now (2 years?).

Second point ... have a look at Loyal bank ... is their device an example of what you're writing about, iang?

Ha, sure. These tokens have been around for over 10 years... In America the market is dominated by RSADSI which sells SecureId. It is a curious observation that they were designed in a bygone age, almost lost as a product that was well before its time, and now that RSADSI has got this far, they've found their time. But the product is woefully out of date and not up to this challenge.

As to Loyal bank - the answer is "probably." There are ways of doing this properly, but the cost is not in the gbp2-5 range, more like the gbp25-100 range, which is not cosy or happy for banks. OTOH, there are ways to do this for free; but it requires the banks to lighten up a bit, and hell doth not freeze up so quickly.

There's a competing company in Ottawa, called CryptoCard, which produces compatible, non-expiring tokens (basically, enclosed block ciphers). Having had a glimpse of how they work and what they do, I feel sorry for their customers.
I think, there's a lot of room for decent security solutions in the two-factor market.
Most of the currently available products are not satisfactory in the face of contemporary threats.

If it's the Perfect Phish, then the URL *is* correct, but the phisher has subverted DNS in one of various known ways. If you want a particularly easy one, assume that the victim is sitting in a wireless coffeeshop, naively trusting that the security software on his laptop, combined with the security software running at his bank, are cooperating to protect him from any thieves who happen to be lurking in the area of the coffeeshop.

Zooko, well spotted! The DNS subversion techniques are also in place.

I've heard anecdotal reports of coffee shop phishing but I don't recall any actual hard evidence. I'm somewhat skeptical that it is sustainable economically as it involves a very traceable activity and very low number of victims; the guy has to be sitting close and has to be active on the network, and for all that he only picks up a few victims.

But as you suggest, it's easy enough to do this, and some mug is going to try it sometime.

Isn't it part of your doctrine, that MITM attacks never actually happen in practice, hence all that silly nonsense about SSL certificates was just a fraud designed to extract money from innocent web site operators?

Well, MITMs at the cryptoprotocol level "never happen" in practice, sure. That is, SSH is "notoriously vulnerable" to MITM but I've never heard of it being hacked like that. And there is good reason to believe that even if SSL was vulnerable to a protocol level MITM (with say SSCs or ADH) then it would still never be MITM'd at the protocol level and thus it would be a good economic choice.

Then there are application level MITMs like phishing. That is, tricking the security model at the browser level, which is kinda kiddie stuff given the laxadaisical approach the browsers have. That is happening, and in tanker loads; it is called phishing. But, phishing hasn't really snuck inside SSL's certificate checking as yet; mostly for economic reasons - it just wasn't worth the bother. Now what we are seeing is that the "inside PKI but outside SSL phish" is ready to happen.

Also then there is the delayed MITM versus the realtime MITM. Yahoo's attack indicates an active realtime MITM at the browser level.

Is it a doctrine? No, it's just observations borne out by the market, I think. Is it confusing? Yes - there are three different levels of MITM going on here, and then there is active realtime versus passive delayed time.

> "hence all that silly nonsense about SSL certificates was just a fraud designed to extract money from innocent web site operators?"

That's how many see it and they have a case. c.f., "search for the business model." I don't care as much about that as moving forward and encouraging people to address security.

These days my theory is this: the browsers are not going to change the model so the TLS part is more or less a system to protect passphrases from sniffing, which it does passably but not admirably (it will do better when ssl v2 is switched off). However the certificates can be a useful handle to do relationship tracking. Hence, access and manage the certs in a browser plugin and see what you can do. See Trustbar and Petname for that.

Others have other ideas. It is notable that companies prefer to go for the centralised database model, again delivered with a plugin. Netcraft were the first I think, but there is also a Comodo one and Microsoft have designs in that area. I personally don't think it will work, but at least these companies are thinking about the problem.

(You could say that this is further evidence that companies won't provide security unless they can see a way to extract more money from it, which matches what you say above. Commercially minded people won't understand that as a claim; what is a more interesting question is why companies provide crap security when given the money and why the good security tends to come from places that don't have the money?)

Oh, I see what you (cyphrpunk) are saying! No, that was never "the doctrine." Instead it was this: the MITM protection wasn't necessary, therefore it is possible to ease up and change the model to do relationship tracking using certs. But that was too hard to explain so I stopped.

Sorry for being dense.

I guess phishing is all about having a wide pool of prey, so doing it at a coffeeshop isn't such a profitable route, but it serves as a proof of concept.

There's an attack called "Evil Twin" where you MITM wireless at a coffeeshop. Large scale DNS poisoning is called "pharming", apparently. I'm not really up on all the hip terminology...

I didn't follow Evil Twin, and the superficial thing there that appeared to me was more that it was a successful FUD campaign rather than a spotted-in-the-wild attack. I could be wrong though, hopefully someone will point me to actual case losses where someone was definitively hit by a coffee shop wavelan mugging which will allow us to track the arisal of MITMs in other fashions than the basic phishing. The more evidence of MITMs we can present the more we can convince the browser manufacturers to re-work the security model.

Regarding Man in the Middle/Evil Twin Attacks -

I wonder if you have reviewed this software based Delayed Password Disclosure Protocol announced recently?

http://www.informatics.indiana.edu/markus/stealth-attacks.htm

A variety of computer networks are vulnerable to so-called stealth attacks. While there are many types of stealth attacks, they all have one thing in common (which is the very reason, of course, for their name) – the attackers are hard to detect. In some cases, it is even hard for a victim to determine that he was attacked – days or weeks may pass before this becomes evident. By then, it may be too late, as in the meantime, the attacker may collect and even modify information that was not intended for him. The attacks can be mounted against both wired and wireless networks, but the relative ease with which they can be used to attack users of wireless networks poses a particular threat within a variety of settings, including public hotspots. Moreover, stealth attacks pose a particular threat in the context of identity theft. A particular type of stealth attack we describe herein is the so-called “doppelganger window attack”. This can either be mounted in a similar fashion as the typical phishing attack is, but poses a greater threat than current phishing attacks. This is so since the doppelganger window attack defeats traditional methods for mutual authentication, which would otherwise have been a meaningful defense against phishing. We describe a new security technique, delayed password disclosure, that provides security against doppelganger window attacks. It can be based on any known method for mutual authentication, and its security can be proven to be the same as that of the underlying method – in addition to security against the doppelganger window attacks.