Sitting in an airport right now, I’m about to transfer some pictures I took with my phone to my laptop, using Bluetooth. But this being an airport, there are many Bluetooth devices around. Which of those is mine?
The naive answer is: simply select the one device in the list that is named the same as my laptop is named. But how am I sure it is really mine? Couldn’t somebody else, accidentially or nefariously, have named their device the same as I named mine?
This problem is largely identical to the well-known e-mail phishing problem: how do I know that an e-mail claiming to come from support@bankofamerica.com indeed comes from there? Or, as I described some time ago in phriend phishing, how do I know that a post on a community site claiming to be from Johannes Ernst indeed is from me.
The technological answer of course is: look into the e-mail headers, do a reverse DNS lookup, or make sure you have your Bluetooth devices paired right (no such solution seems to exist for phriend phishing). But even where some technological solution exists, how many people know how to use it correctly? And of those who do (myself included), how many really want to do this after a long day sitting in an airport, for example?
To take this one step further: how can I know that a digital picture frame in the house of gramma really is the one to which I want to beam the pictures of my living room web cam? (not that I have one — but as more and more devices are network-enabled, whether they are picture frames or lawn irrigation devices or home security systems or my fridge: all of them are susceptible to phishing.)
It sounds like a more general-purpose anti-phishing solution is required, that:
- works for all of these kinds of devices and situations, not just e-mail/web;
- is more easily comprehensible to the average technology user than "have you paired your devices correctly?"
It appears to me that the crucial feature of any solution must be that entity A (i.e. user, website, phone, device, etc.) cannot be allowed to look indistinguishable from entity B to the average user. If the user cannot readily distinguish the two, then an attacker will be able to masquerade as entity A, fooling the user into believing he is dealing with entity B.
This disqualifies:
- e-mail addresses: anybody can claim to send e-mail from anybody’s account with basic knowledge of SMTP, the protocol to send e-mail. (Well, everybody knows that, that’s now why you are reading this blog…)
- Bluetooth device names: I can easily call my device the same as you call your’s.
- any form of graphical icon: what is to stop me from using the same icon as you do? (Not even a very impractical central image registry could really solve this problem as too many different images look remarkably similar.)
Website addresses are slightly different if used with https: through the magic of SSL certificates, web browsers (and other software) are able to adorn website addresses with different colors / dialogs etc. depending on whether those sites can or cannot prove that they are the rightful owner of the cryptographic key pair underlying the certificate. That way, the rightful website URL may appear with a green background, while somebody’s hijack attemption may have a white or red background. Given how browsers are constructed (or at least supposed to be constructed), attackers cannot fool with those colors. (e-mail sender certification works in a similar manner, but is weaker as commonly proposed schemes only authenticate the sender domain, not the sender itself, opening up the possibility of a man-in-the-middle attack by e-mail hosting providers, or successful attackers thereof)
I’m proposing the use the same approach — public key cryptography in conjunction with unambigous human-readable identifier — as a general-purpose approach against phishing, whether websites, e-mail messages, Bluetooth devices or anything else. (Note that I’m not proposing PKI with a centralized trust root; a PGP-like web of trust model works just as well for most use cases that I have in mind.)
For this to work, we also need an unambigous name space: nothing is gained if two entities could prove to be the rightful owner of handle Joe, for example, allocated to different name spaces.
Do you see where this is going, finally, after all these words that must be a result of waiting at an airport gate for too long? ;-)
URL-based identity (think OpenID) is a perfect candidate for solving the phising problem. Let’s look at the requirements:
- URLs are allocated in an unambiguos name space, called DNS. Check.
- URLs, as relatively short, human-readable character strings, can readily be distinguished. Yes, there are certain problems, like the possibilty of using funny unicode characters that look the same to many users. But even allowing for this, URLs are much more easily distinguishable than any other alternative that I can think of: graphical icons, for example, are much harder to tell apart if an attacker does a bit of work. So, check.
- Through URL-based identity technologies, we now have the technological ability to prove whether or not one is indeed communicating with the rightful owner of the identifier / the URL. Check.
That’s all we need to solve the phishing problem, regardless of device. Ergo demonstrandum as I learned in math class many years ago.
P.S. I’m skipping over some details here, but I don’t think they invalidate any of what I’m saying. Most notably, for the purpose of anti-phishing, I’d much rather prefer to put a PGP/GPG key pair behind each URL as we originally did in LID, instead of the shared secret as in the OpenID authentication specs. This would eliminate certain possible man-in-the-middle attacks, and also work much better in disconnected mode. This approach also works beautifully well as a solution for the phriend phishing problem: if I post a comment on a website, I can first sign the post with my PGP/GPG keys, and the website can display it with the digital signature (or hide the signature graphically, while allowing a piece of software to still access it.) That way, not even a hostile site can pretend that I posted some comment when I did not, and a browser could do the same trick as with the green/white/yellow etc. colors for the SSL certificates to indicate to a user what the truth is here. Note that through the power of Yadis, using both shared secret-based and public key-based authentication schemes simulaneously is not a problem at all.
P.P.S. Isn’t it great if that tiny little piece of technology one came up with one day, called URL-based identity, can solve so many problems? ;-) The far bigger problem is to educate the world that these technologies do exist, of course; but that is well under way as the rapid adoption of OpenID shows.
Time to board that plane … I hope there’s no "airplane phishing" going on here and I am going to some other place instead…