Terence Spies on Identity-Based Encryption
Pages: 1, 2
ORN: I hear you're supporting major mail clients. Can you give their names?
TS: Of course, we're supporting Outlook, OE, and webmail. We have beta versions for other clients, including Lotus Notes and BlackBerry. We're working on a Universal Reader, since it's impossible to write plug-ins for every client. Because the body of an encrypted message is encoded as attachment, with a MIME type, it uses a MIME handler that looks a little bit like Acrobat. At least you can read the message.
Other clients in the pipeline are Eudora and Evolution, the one from Ximian. This is really driven off of customer demand.
ORN: Who is your target market?
TS: Medium to larger enterprises. Also, the financial and health care industries, which are facing strict regulatory compliance issues about data security and privacy. They're considering security more energetically. We're moving into the small-to-medium business market too.
ORN: What about governments?
TS: We have several government customers in various branches.
ORN: I remember that export restrictions have been tricky in the recent past. Has that been ironed out?
TS: It seems to be OK now. Most people are happy. Most things can be shipped with a simple declaration, not necessarily a formal review.
ORN: It sounds like someone needs to run a server then. That's probably you. Can you tell me more about it?
TS: We're running a complete key server that will allow people to pilot the client without needing to run their own server for that trial. We expect that they'll then transition to running their own key server. The outsourced server will be a high assurance server run by a neutral third party.
Our model is that enterprises will run their own keyservers. This will give them control over their own destinies. They can set their own policies for keys and access and expiration.
Running your own keyserver, instead of being your own CA, is easier to install and administer. You can set up a secure policy server that follows the policies of your own directory. We don't try to authenticate or publish to it, we just consult it. There's no need to change your directory schema. The keyserver just follows as a tag-along to your existing directory policy management.
ORN: What will licensing look like? It sounds like if my company wants to do some testing, there's little to no charge?
TS: We'll offer proxied key management for a while. Our partners will offer a permanent outsourced keying solution.
ORN: And the SDK licensing?
TS: It's royalty free, available with source to any interested developer.
ORN: You mentioned key expiration earlier. Can you go into more detail?
TS: Key expiration is intended to ensure key freshness. Consider it like certificate revocation. You can force the use of another key, forcing the holder of that key to reauthenticate. When it's encrypting, the client specifies the current week in key and sends it on. Every time the week changes, the public key changes. This forces the private key to change and ensures that keys are turned over at least on a weekly basis.
You can put arbitrary information in public key, though. The next version will give the ability to send a critical message, where you insert random data into key and force a recipient to authenticate to get a fresh key for that message. There's the uniform idea of requiring authentication within a certain time window.
ORN: Is there a limit on the number of active private keys?
TS: It's only limited by storage. The key cache is optional. The key server can recompute a key, if necessary. You could go back to the server to get a key recomputed.
ORN: You mentioned a default expiration date of a week. Is this configurable?
TS: A future version will allow this. Many of our customers will want a longer or shorter period.
ORN: We've covered email pretty heavily. Do you have any other uses of IBE in mind?
TS: Sure! Think of instant messages. You can treat them the same as email messages. There's also VoIP, inter-domain messages, voice, or SMS. IBE is a generalized access control that lets you protect things between and within domains. We are also actively looking at the application of this technology to web service security protocols.
ORN: Suppose I want to update my DNS record with my registrar, would IBE be useful here?
TS: We think of email as an access control. There's no reason it has to be limited to email. You could set a crypto ACL on your domain record, saying these people have the ability to open this file. It could be done in addition to any ACLs the OS supports. If OS cannot protect a resource, say if it's in transit, the crypto ACL protects it.
ORN: So, in theory, you could write a new filesystem.
TS: Yes, or extend an existing file system that uses crypto. It's a big job but it's doable. You could write a file protector that allows desktop encryption of files. You could can specify the email names of people who can access a file.
ORN: It sounds like the current version is built around email address identity.
TS: That's true. We're working with partners who want to use different identities, including domain names, IP addresses, and phone numbers.
ORN: It seems really simple. Maybe that's the insight.
TS: I think you really nailed what we are about. The underlying mathematics that secure the system are quite complex; but from the user's perspective, it's a really transparent way of securing information. The ability to send secure messages to people that haven't generated keys yet is really powerful and makes the system much easier to use.
Shamir proposed IBE in a 1984 paper, but no one could implement it. It has one fundamental difficulty, a security requirement that a normal crypto system doesn't have. The big security question is, how hard is it to derive one private key if I have others? That's really hard to do right, and that's why it took so long.
ORN: How do you plan to work with other people?
TS: We have a developer toolkit that contains APIs and source code. It'll let you build applications based off of IBE. Just like RSA and other crypto breakthroughs enabled other apps, we expect the same thing to happen here. We want to enable people to build apps on top of it.
The SDK includes source and APIs from low level through "create messages in XML-built ways" levels. We really expect standards to grow out of it and intend to make our technology accessible to anybody.
Return to the O'Reilly Network.