Identity-Based Encryption revisited

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

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?

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

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.