Thursday Jul 13, 2006

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...

Monday Jul 10, 2006

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...

About

superpat

Search

Archives
« April 2014
MonTueWedThuFriSatSun
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today