A secret is only as good as the people keeping it. While it's hard to find a reputable web site that doesn't use secure connections for receiving credit card data, there's a wealth of other data that passes through the wires in the clear for anyone to see. When was the last time you sent or received sensitive email? When was the last time you were really sure that the purported sender was who she claimed to be?
The problem of widespread cryptography is not the math. Certainly it's valuable to explore new algorithms and to find weaknesses in the popular cipher systems of the day. What good is it to encrypt your email if a bored teenager can rip through possible payload permutations in a few seconds?
Of course, the world's most secure algorithm is useless if no one uses it. While various schemes have been devised to make cryptosystems easier to use, the most popular fall down at the same place: asymmetric cryptosystems (as well as their symmetric brethren) require sharing some sort of key beforehand.
One popular approach is PKI,
where individual users generate their own key pairs. They keep their
private keys private and upload their public keys to a public key server.
Suppose Alice has generated a public key, identified with her email
firstname.lastname@example.org. If Bob wishes to send her an
encrypted email, he must contact the correct keyserver (or otherwise
obtain her public key), encrypt the message, and send it to her. If Alice
has not generated a key pair, uploaded it to a key server, or if Bob
cannot find her public key, he will be unable to encrypt the message.
While tools and email client plug-ins have come onto the scene to make it easier to generate and to juggle myriad keys and identities, they're not yet widespread to the general public. Perhaps it's time for a different approach.
The biggest drawback of PKI, aside from simply getting people to use it, is the rigmarole of generating and distributing public keys. One potential solution was proposed nearly 20 years ago. It's called Identity-Based Encryption.
The insight behind IBE is that public keys don't have to be large prime numbers. They could be email addresses, phone numbers, or even subject lines. Bob can send Alice an encrypted email before she's even generated her private key, before she's even heard of private keys.
That's the idea behind Voltage Security, a new company that hopes to make encryption more useful and usable. Terence Spies, vice president of engineering, recently agreed to an interview.
O'Reilly Network: How would you describe IBE? It's called IBE, right?
TS: Yes, it's IBE. IBE is a fundamentally new way of encrypting. The usual way of looking at IBE is that you want to secure something to send to me. What you do is compose a string, either an identity or an access policy.
ORN: Like the subject line of an email?
TS: The string you compose for access is closer to a
To: line than a subject line, but the idea that the access
control policy is described by a string is right on.
It's encoded to an XML schema, which is really an access policy for the
encoded document. Going by the
To: line, the simplest method
would essentially say "this document is accessible by
email@example.com". When you want to decrypt this message, you'd give
the keyserver your string. Based on a normal authentication method, such
as Kerberos or domain authentication, the keyserver decides that you are
you. Then it generates a private key, the cryptographic inverse you can
use to decode your message.
ORN: So IBE uses a normal keypair as with PKI?
TS: Yes. The key is not message-dependent, nor a one time thing. The private key you've received once is sufficient. There's no need to go back to the server. Everything works a lot like a normal RSA key pair; there's no big difference in implementation and no per-message cost to return to the server.
ORN: How does it work for the sender? How do I select the appropriate authentication type? How do I choose which key to send?
TS: There's a schema to choose from. It supports things like validity dates and putting the proper addressee name into the key. That's reduced to a canonical XML form. As a user, you'd just write an email and hit a "send secure" button. The email plug-in encodes the email address, encrypts the message, and sends it. We use as much standard technology as possible.
The encrypted message looks like S/MIME. There's a funny key exchange block, so it does look a little different. We use triple DES, AES, SHA-1, whatever's appropriate. We're trying to invent as little as possible.
ORN: What does it look like to receive a message, if I haven't used this before?
TS: It'll automatically display the message if you have the client installed. The plug-in authenticates to the keyserver in the background. Just download and decrypt. There's a little button that lets you view encryption properties if you want.
ORN: If I don't have the client installed, what will I see?
TS: You'll see a Base-64 encrypted message with a special header that says, more or less, "Voltage encrypted". The message will appear encrypted, with a plain-text header that indicates how to install the client. There may be a link to install for you--that depends on the configuration. Some system administrators may choose to filter these messages in situations where desktops are locked down. Installation may be tricky in those cases.
ORN: You personally have a history in this area. Is this a labor of love for you and your company?
TS: Personally, I started doing PKI when studying at CMU in 1989 or 1990. I saw the promise of the ability to make security a default. I wanted to create a sensible form of security.
When I was at Microsoft, I did multimedia, but got sucked into the public key world and shortly started doing PK in earnest. That's where I designed CryptoAPI, a standard for using PK services. CryptoAPI evolved into the design of MS certificate server.
I really want a nice, decentralized way of securing things, something a little more scalable that works offline and lets you control your own keys. PKI looks good in theory, but has problems that you run into in practice. The main problem is time. To use PKI, someone has to have prepared in advance. You'll always have that question in mind.
Our company and personal dream is to cross the chasm, providing a default mode of securing things.
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.
chromatic manages Onyx Neon Press, an independent publisher.
Return to the O'Reilly Network.
Copyright © 2009 O'Reilly Media, Inc.