[ ibe radiaperlman ]
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.comThis 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...
![[Feed]](http://blogs.sun.com/roller/resources/superpat/feed-icon16x16.png)
![[This is a Roller site]](/themes/sotto/images/roller-logo.gif){kind=logo}
There has been a lot of hype about IBE, but outside of this, it does solve some substantial technical issues. In essence, it boils down to the fact that access decisions (like who can open a document, or what the policy is for accessing a document) can be made at decrypt time rather than encrypt time. This is sort of abstract, but the advantages are easy to see in the simple example of encrypting to a group. With conventional PKI, this problem is pretty hairy, and typically requires publishing group certificates, or having some kind of group "exploder" server that translates the group into individual identities. With IBE, none of that it required. You encrypt to the group, and the decision to grant a key is made at decrypt time.
I'd like to reply to Radia's objections in detail, but to keep this comment short, I'll limit myself to a few short remarks.
On (a), it's worth noting that for almost any enterprise encryption project, a central server NEEDS to know how to decrypt all messages. By SEC regulations, no bank can actually run a system where they can't decrypt messages. In most cases, it's now an argument about which system implements message recovery most efficiently.
On (b), there are simple SSL protocols to map users to key servers. Too complex for this reply, but we have working systems with 100k+ users that implement this.
On (c), in a PKI system, the user needs to authenticate to a CA to get a cert issued. That binding is typically much much more expensive than an IBE key bind.
On (d), there is a long standing protocol for handling revocation, that goes back to the first IBE paper. (We include time as part of the identity.)
On (e), we have protocols that tie in with user binding to handle rollover and revocation of the master secret. (Note that we have to handle revocation and rollover of ONE key, as opposed to one key PER USER in a PKI system.)
Outside of the hype, IBE is really very powerful. It solves a different set of problems than PKI, you might argue, but for enterprise security for email and documents, it's a great tool!
I look forward to continuing this discussion, and feel free to contact me for a demo or more in depth discussions
Terence Spies
Posted by Terence Spies on July 15, 2006 at 10:13 PM PDT #
Posted by Nico on July 27, 2006 at 03:57 PM PDT #
Yes - escrow is key. The other issue that I think is relevant for the world of federation is that we are generally concerned with signing rather than encryption. Key escrow isn't really useful here, since you can verify a signature 'forever' with the public key and you don't really want the ability for any party to generate signatures with an escrowed key.
Having said that, I did identify one possible use case for IBE in my previous post, where an attribute provider could encrypt data for consumption by a named, yet otherwise unknown, relying party. Maybe I'll bounce this off some of the Liberty gurus...
Posted by Superpat on July 27, 2006 at 04:50 PM PDT #
Posted by Robin Wilton on August 09, 2006 at 07:43 AM PDT #