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: [email protected]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 [email protected]
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…
Comments
Terence Spies
I’m disappointed that a security thought leader like Radia is not as positive on IBE as some others. Admittedly, I’m quite biased here (I’m CTO of Voltage Security, which is more or less “The IBE Company.”)
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
Nico
IBE’s strength, and weakness, is key escrow. Either you require key escrow, in which case IBE may be a good fit, or you really don’t want key escrow, in which case IBE is a bad fit. Within corporations key escrow can be very good; between individuals, very bad. Radia’s second point, (b), was about the IBE equivalent of PKI trust path construction/validation. Both need this, but I’ve seen this aspect of IBE glossed over (“you need only know their e-mail address!”, well, yes, but then you need to securely find the domain’s PKG). Radia’s third point, (c), is not quite right: Bob and his PKG could be using Kerberos V between them, instead of PK; and so (d) (revocation of Bob’s credentials to authenticate against his PKG) is really orthogonal to IBE. Radia’s last point, (e), is equally applicable to CA certificate recovation in PKI. In both, PKI and IBE, CA/PKG key revocation is hard and has nothing to do with the number of users in that CA/PKG; key rollover is a bit different in that in a PKI users need to get new certs for their keys, but this is not all that different from IBE users having to change their credentials for authenticating to the PKG. The crucial matter, really, is key escrow. Do you want/need it, or not?
Superpat
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...
Robin Wilton
It also looks to me, from an admittedly cursory skim, that (relative to PKI) IBE would not provide a robust basis for non-repudiation… given that the PKG resides on a node outside the user’s control.
Leave a Comment
Your email address will not be published. Required fields are marked *