Terence Spies on Identity-Based Encryptionby chromatic
Cryptography and the Average Person
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.
Pages: 1, 2