Identity-Based Encryption revisited

After my earlier post on Identity-Based Encryption, I promised James McGovern that I’d ping our security folks for their take on IBE. I did so and Radia Perlman was kind enough to reply and gave me permission to quote her in full:

Identity based encryption.
Sigh.

This is something that some people in the research community have gotten all excited about, and I really think there’s nothing there. It might be cute math, and even a cute concept. The hype is that it makes “all the problems of PKI go away”.

The basic idea is that you can use your name as your public key. The private key is derived from the public key based on a domain secret, known to a special node called the PKG (private key generator), which is like a KDC, or an NT domain controller.

Some of the problems I see with it:

a) public key stuff is so nice because nobody needs to know your secret, and the trusted party (the CA) need not be online. The PKG obviously needs to be online, and knows everyone’s secrets

b) If Alice is in a different trust domain than Bob, she has to somehow securely find out Bob’s PKG’s public parameters (which enable her to turn Bob’s name into a public key IN THAT DOMAIN).

c) Bob has to somehow authenticate to the PKG to get his own private key

d) There is no good answer to revocation, in case someone steals Bob’s private key

e) There is no good answer to revocation, in case someone steals the PKG’s domain secret.

I’ve seen hype slides about identity based encryption saying “which identity is easier to remember?

In PKI: 237490798271278094178034612638947182748901728394078971890468193707
In IBE: radia.perlman@sun.com

This is such ill-conceived hype. In PKI no human needs to see an RSA key. The RSA key is not your identity. Your identity is still something like radia.perlman@sun.com

So, it looks like IBE gives with one hand (sender can create a public key without the recipient’s involvement) but takes much more away with the other (key secrecy, PKG has to be online, revocation issues). I guess there is no such thing as a free lunch…

Getting the VPN to work on NetworkManager/Dapper Drake

UPDATE – September 15 – thanks to ‘Ed’, I have it all working. Please see the comments for the answer…

UPDATE – August 14 – the VPN package linked below doesn’t seem to update resolv.conf, so I stopped using it and went back to vpnc from the command line. Please do leave a comment if you’re able to get all this working properly!

As I’ve previously mentioned, I’m running Ubuntu Dapper Drake on my laptop. Everything has been working just dandy since I recovered from my hard disk crash, except for one minor annoyance: the version of NetworkManager in Dapper Drake doesn’t do VPN.

I’ve been using the command line vpnc to connect, which works ok, except that, when the DHCP lease expires, NetworkManager overwrites the VPN’s version of /etc/resolv.conf, so I have to either keep a backup /etc/resolv.conf to copy back, or just restart the vpn.

I finally got round to googling for an answer tonight and (on this page) found a VPN package for NetworkManager on Dapper. It seems to work fine. The one niggle was that, after configuring the VPN connection in nm-applet, I had to restart NetworkManager, but that’s a one-time thing.

Roll on Edgy Eft!

fish4 a reference?

Rohan pointed me to this story about UK site Fish4 having problems with their E6900. I guess we’ll take that one on the chin (wonder what the first person plural of ‘mea culpa’ is?), but it set me wondering… If Fish4 are happy to point the finger when things go wrong, they should really give us some acknowledgement when things are going well. Perhaps someone in UK sales can email them a little ‘Powered by Sun’ graphic. Just like the one at eBay.

UPDATE – See Rohan’s take here – in response to Rohan: it’s quite possible that Fish4 have Linux on the web tier backing onto an E6900.

Identity-Based Encryption

Catching up with the rest of the world after Sun’s summer holiday, I see a posting from James McGovern mentioning ‘Identity-Based Encryption‘. I can totally see the utility of IBE in the context of, say, corporate email: there is a mechanism for Alice to easily tranforming an arbitrary string (say, Bob’s email address) to a public key and use the latter to encrypt a message for Bob. At this point, Bob needn’t have a private key at all. On receiving the message, Bob can go to the Private Key Generator (PKG), the equivalent of a certificate authority, I guess, prove that he ‘owns’ the email address in question and obtain a private key. (I haven’t read up on this in the necessary detail to discover whether there is an implicit key escrow here – presumably the key issuer could generate Bob’s private key for itself, if it really wanted to?).

Thinking aloud on the application to identity in the sense of SSO, federation and such… As far as I can see, the ‘Identity’ in IBE’s name could just as well be ‘arbitrary string’, but in an email context, the use of an email address (one possible identifier) has obvious benefits. For authentication, though, I’m not so sure. I can’t see strong non-repudiation here, since the PKG can always mint a private key for any given public key.

Still, there might be applications for encrypting attributes in a loosely-coupled authentication domain. At the request of the principal, an identity provider could encrypt attributes to be sent to a given relying party without a prior relationship with that relying party, using, say, a URL as public key. If that URL located an appropriate web service, the relying party could automatically request a private key from the PKG, which would send the private key to that web service, using message and/or transport encryption for privacy. Interesting…