Financial Cryptography

In January, the FreeBSD Foundation annonced that Sun had revoked its Java source code license. I really don't understand what Sun is up to. Even releasing the source code under a permissive free software license and charging for binary packages would make more sense at this point.

The root-access bug is badly misreported in the article, but that is partially the fault of the original bug reporter.
It sounds bad and scary, but in fact I would argue (along with quite a few people at bugzilla) that it is not even a security issue. No privilege elevation is actually happening. This is not a way of gaining root access unless you already have it.
If the root is running firefox (silly root, BTW) and the user does not have access to his keyboard and mouse, he is not able to gain root privileges this way. If he does, then THAT is the security problem.

I find that mozilla's approach to bugs is very well-thought-out and bugzilla IS the place to check for known bugs.

Of course, the article's conclusion that switching to Firefox is no panacea against browser-related security problems is true, but the fact that in general there is NO panacea, when it comes to security, makes it essentially a content-free truism.

Firefox's security advantages over IE (and the development model behind it) go beyond the protection offered by the single-digit market-share.

I would even go as far as saying that if you can't look under the hood -- don't trust it in security matters. Whatever "it" is.

The Sun announcement of a while back wasn't that FreeBSD had 'lost' its licence, but that the class of licences was being withdrawn. As they hadn't actually said what licence would replace them, it appeared that Sun were revoking the licences. But that wasn't the case, it was just a case of Sun not thinking again. Last week's announcement may belatedly close the loop on what they were trying to say.

Where Sun goes from here I don't know. Java as a language isn't bad and has big systems potential but without the spread on the OSs like the BSDs and Linux, it fails to draw in the programmers, which are the input to the corporate machine. Most people I know choose Python, Ruby, Perl, PHP, etc, simply because they can. It's just easier, and once they are in that circle, changing is pointless.

Sun's Java is very vulnerable. If Microsoft were to push its language into the FOSS world, I'd say it would be all over. (I gather you can already do C# on other platforms but there are no libraries?) It's a numbers game, which makes it an ease of development game, and Sun's obsession with platform independence resulted in the exact opposite, which also lead to J2EE and a whole other set of problems. But that's a rant for another day.

Daniel,

You are right in that Mozilla is a better program, and its bugzilla system seems comprehensive. But even though Mozilla has arguably put together a better program and development approach, it is still locked into a battle with the nemesis of the 90s. Right now, things have moved on, and the secure browser is being pillaged in the market place, but there is very little recognition of that in the Mozilla camp.

Microsoft have woken up. Microsoft are capable of switching to meet new threats. I've not seen any evidence that Mozilla as a community are even aware of the threats, and the Shmoo response indicated (to me at least) that security is limited to patch releases based on overblown press releases.

A good program and the occasional patch aren't good enough today. They may have been good enough back in the 90s when the biggest problem was bored students poking fun at Netscape. These days, there are factory level crooks looking to shake down users, and they are flush with success.

Ian,
While phishing is definitely the most dangerous attack on the average internet user as far as economic impact is concerned, it does not imply that the most important security enhancements in a web-browser should be phishing-related. Because I think that the root of the problem is not the browser, but the whole paradigm of secure communication, where the service provider authenticates itself by SSL and the user then authenticates himself by entering a password (or some other secret, like a credit card number) into a supposedly secure form. Thus, it is very likely that the effort spent on trying to prevent phishing by tweaking the browser will result in very little if any added protection against phishing or anything else.
I think, phishing should be addressed by a paradigmal change in the way users are authenticated over the network. Without going too deeply into the rationale behind it, I am convinced that there should be only one place where the user has to enter any password or passphrase (not necessarily the same one), which does not divulge it in the process of authentication.
One technology that I am experimenting with right now are passphrase-seeded public/private key-pair generators. Essentially, the idea is that you do not store the private key anywhere, but seed a PRNG with your passphrase and generate the keypair using that PRNG. You sign up by sending the resulting public key and authenticate by using the private key. You're free to use different passphrases/passwords for different services. But you still have only one place where you enter your passphrase and that's the only program that you need to trust.
As long as it does not divulge your passphrase or the resulting private key -- your identity is safe.
Another -- related -- idea that I have is doing away with the very notion of "logging in" altogether: Whenever you want something from a remote server, you send a signed request (e.g. a signed multipart/www-form-data or an application/x-www-form-urlencoded document). The signature is generated using your passphrase-induced private key. Of course, it must be unambiguously referring to the form it is responding to, including the signature of its origin so that a malicious site cannot make me sign a request to some other site. I haven't worked out the whole protocol yet, but you get the idea, I guess.

In short, IMHO fixing the browser while keeping the flawed paradigm of divulging a secret over SSL to some "trusted" site for authentication purposes is a futile undertaking. I'm glad the mozilla folks are not spending too much time on such a hopeless task.

Hi Daniel,

In terms of where the defences should be put - well, of course that's a decision to be made by the programmer, in the end. We can all cast our bets there, and I've cast my own bet on Ricardo (more on that later). Others like the capabilities crowd have cast a bet on replacing the URL structure with something more robust called YURLs. Banks are being sold solutions by the hundred, and there is a brisk business in two-factor authentication like RSADSI SecureId tokens. These are all bets in the marketplace, and in 10 years time, we'll all look back and say "well, that was obviously a fraud, wasn't it!"

The thing about the browser is that bets against it have historically been wrong. The browser is what it is, and half a billion users can't be so far out of touch. So while I agree with you that it won't support much of a security arangement, it is what's there. Anything that wants to realistically address phishing has to consider that fact (and it is for this reason, most of the "solutions" that are being sold to banks will only work in terms of diversifying them).

Worse, it is the case that nobody has managed to deploy widescale crypto outside the browser. In deployment terms, OpenPGP is a flop, SSH is a techies tool, and every other thing is so small it doesn't show on the radar. So, while I love the notions that you present, I don't for a moment think you have any chance in hell of deploying them on mass - unless you can solve the problems that 1000's of entrepreneurs and billions of dollars have failed to do so far!

(Oh, and just in case anyone here thinks I'm lauding SSL, forget it! SSL may be deployed within every browser, but it's rarely used. That's a bug guys.)

Which means - don't bother with phishing. In this I agree with you. Far better off to think of where this will make a difference and where you can deploy it in early stages. I'd suggest p2p like file sharing or chat. There, we are still in a game where new ideas can be incorporated.

PS: tell me if you agree with this one:
http://www.financialcryptography.com/mt/archives/000277.html

Daniel,

in the sense of your public key proposal. It sounds like a neat idea if you can make it work. I don't know, I'm nowhere near good enough at the actual maths level to know whether you can do that. I'd certainly encourage you to try though. I think I may have actually heard of this idea before - have you asked the cryptographer's group?

Also, in terms of turning HTTP requests into signed request-response mode, that is literally what the SOX protocol does. Create a key, register at the server, and then sign every request, read the response. If it fails do it again. And, to get info back to the client, the server maintains a mailbox which the client polls from time to time.

It's secure, it's aligned to the physical realities of the net, coded up and works. It's got as much chance of shifting the browser though of us flying to the moon, and indeed several "competitors" have broken on that rock: SHTTP, x.959, etc are basically nymous or request/response ideas. Still, it doesn't have any problem dealing with phishing :-)

Hi Ian,

I do agree with what you wrote about "trusted computing".

As far as placing bets, I am doing that too; I have recently applied for jobs to two companies in the identity business, because I think their approach has a chance of winning. ;-)

Moreover, I am not betting against the browser; I am fully aware of the fact that it is the primary user interface and communication tool for a huge number of people. What I am essentially saying that it is MORE than the browser that needs to be changed to effectively address phishing. Tweaking the browser while keeping SSL-tunneled secret-transfer as a means of authentication is a waste of time and effort.

I maintain, that there needs to be a single place where the user is required to enter passwords (which may be a pop-up dialog of the browser replacing the usual click-ok before posting anything). It is far more realistic to educate the users not to enter their password anywhere else than the whole SSL-certificate-and-padlock misery.
As long as it never divulges the password and the user trusts his/her own computer (which one can, in many cases), it is safe.

As far as SOX is concerned, I have been reading your documentation with much interest for the past few weeks, but it's still to early for me to comment on it.

SHTTP is closest to what I envision, but it is too flexible, making it too easy to cook up a flawed solution while still following the protocol. I would like a much lighter and simpler thing to ride on top of to HTTP. Maybe just using a few additional content types nicked from PGP/MIME and/or S/MIME.

PS: I have just received a neat phishing email, while typing this message. My email client (mutt+links) did a perfect job of revealing its malicious nature.