One of the main problems, as I see it, with security research is the chicken and the egg. Let’s say you come up with a snazzy new protocol, but this protocol requires a smart client (or modification to a browser). Additionally, you have some identity providers that are not terribly difficult to develop, but are not deployed. Now, how do you justify deploying all these modifications or new service providers if there are no clients to take advantage of them? On the other hand, how do you justify upgrading all the clients to support a protocol that has no identity providers?

The real answer is that you compromise. Either you find some company whose business model can benefit directly from the technology and have them be a champion, and hope that you can get enough marketing (yes you heard me, marketing) and people interested that it creates some momentum and adoption.

One of the coolest protocols I’ve read about is SRP. It’s the bomb, really. Password based, strong cryptographic properties, mutual authentication—both the client AND the service provider are authenticated, phishing attacks to obtain your password are not an issue. I could go on, it’s got some serious coolness. Additionally, some work at BYU shows how it can be extended to make it solve a lot of problems that OpenID is aimed at, without the drawbacks. (Heck, it even allows you to delegate access to other users.)

Problem is, SRP and its extensions require a smart client, and modification of service providers. Chicken and the egg. Drat.

Thoughts:

I’m wondering if it can be adopted by compromise, by providing a signed java applet to perform the smart client responsibilities for wireless authentication.

Another thought, what if you could get one half of the problem solved, like getting widespread deployment of the smart client, the other side could very easily drop into place.

Early Adopters

Interesting tech is usually adopted by the geeks before it goes mainstream. Now, not all things the geeks embrace make it mainstream, but a lot of things mainstream were solidly in geek territory in the beginning. One way to get early adopters is to:

• make a polished smart client for the linux desktop (gnome/kde)
• on the server make your software as easy to use as an apache module etc.

The key is real solutions that at least the geeks can use today.

Ride Someone Else’s Coattails

OK. Everyone agrees that smart phones/smaller devices are going to be a key part of the foreseeable future. Why not use this trend to lift usable security mechanisms out of their academic tar pit? Just to be controversial I’m going to say Android is going to be huge. What if someone stepped up, and implemented this slick, efficient, just-what-the-doctor-ordered password smart client for the Android platform that happened to support SRP? Let’s say it took off like the iPhone, I think it is realistic to see broader adoption of SRP across the board if, in a year after launch there are 90 million installed clients with active users.

I first heard about the Linksys WRT54G from The Pulpit of Robert Cringely several years ago. I bought it knowing that I could replace the stock firmware with an open source firmware since the firmware was based on Linux. I chickened out. I was too worried that I would make a brick of my only router.

With a little encouragement from my wife I recently took the plunge. The happy ending: everything worked flawlessly and everything has been fantastic.

I chose Tomato and have found that it is freakin’ awesome.

Some features I like:

• Dynamic SVG graphs
• dnsmasq (your own lightweight DNS)
• very few (if any) changes in settings require a restart
• logs, so you can actually know what’s going on
• throughput performance has improved
• Quality of Service—I thought I’d need this to give my Vonage phone priority but I haven’t had any issues with the default settings
• I finally know how much bandwidth I’m using

Real time svg graphs of iChat video conference in Tomato.

The picture is of the real-time graph. You can see where the bandwidth was pushing 2 megabits for both upload/download in the video conference, and then where the other end decreased their bandwidth by sending junky low res picture. I am much more polite and vain and had to keep sending in high resolution.