Superconductor

Voltage Crypto Toolkit

When you read the Voltage weblog, you will either know who most of
the contributors are, or you can read about them in the About Voltage
page. But there's a good chance you've never heard of me (Steve
Burnett).

For 9 years I worked at RSA Data Security (later acquired and
renamed RSA Security). The majority of my work was writing code for
the BSAFE product line (Crypto-C, Crypto-J, some BCERT and Cert-J).
Voltage hired me to build the Voltage toolkit.

My job here, then, is to build a software product that allows you to
add crypto, including IBE crypto, to your product. In one sense, my
product competes with BSAFE. We offer some of the same functionality
in a similar format (a C library with function calls to digest,
encrypt/decrypt, sign/verify, etc.). In another sense, we don't
compete, because BSAFE does not offer IBE (and the Voltage toolkit
does not offer some of the algorithms in BSAFE).

There are a lot of crypto APIs out there, from BSAFE to the JCA/JCE
in Java, from PKCS #11 to OpenSSL. So why the Voltage toolkit?
Because some toolkit needs to offer an IBE API, otherwise no one
will be able to add IBE capabilities to their apps.

There are all kinds of marketing answers to that question as well,
but for me, the toolkit is my chance to build a crypto API and
toolkit the way I think it should be done. I'm taking everything I
learned at RSA and applying it here. I take the good ideas from
BSAFE, PKCS #11, Palm OS 5 Crypto Provider Manager, OpenSSL, and
other crypto products I've seen, and apply them here. I also see
the mistakes made in those products (some of the mistakes I see are
my own and some of those embarass me to this day) and avoid them.

My goal is to build a toolkit that gives the correct answers,
handles errors gracefully, is portable and extensible. Plus, it is
to be relatively easy to use and well documented. In the future,
we'll be looking to make it faster or smaller, but for now, we're
getting a product out the door that gets the job done.

In the future, when I submit to the weblog, it will likely be to
describe elements of the toolkit and explain why we do the things
we do. So give me all the opinions and questions you have on the
Voltage toolkit and how to use it.

Archiving & Encryption

Archiving email has quickly become a big headache for enterprises. Banks and brokerages have been dealing with archiving requirements for a number of years, but by 2006, all public companies will fall under the Sarbanes-Oxley archiving requirements. Not complying can be expensive, as recent examples have demonstrated. But archiving large volumes of email introduces a new concern: how do you handle archiving of encrypted messages? In other words, how do you ensure either that messages always get archived in the clear (as, for example, SEC rule 17a4 mandates), or that archived encrypted messages can be accessed at some point in the future? The traditional solution to this problem with PKI is to use a special archving key (sometimes referred to as an Alternate Decryption Key, or ADK). Every email, in addition to being encrypted to the message recipients, is encrypted to the archiving key. If an encrypted message needs to be decrypted (either in order to be placed in a cleartext archived, or to be accessed at some point in the future), an approved administrator or machine can use the archiving key to get access to the plaintext. Unfortunately, special archiving keys introduce a number of issues:

• Giving a copy of the archiving key to a machine represents a major security risk. If you want an automated process to be able to decrypt messages (for example to place in a cleartext archive), the process must be given a copy of the archiving key. However, these archiving keys are generally long-lived (years), so if the process/machine is compromised, an attacker will gain access to every encrypted message in the system.
• Giving a copy of the archiving key to a person represents an even bigger risk. Once an individual is given a copy of the archiving key (for example to perform an audit), that user must be indefinitely trusted with the entire organization's email. If the individual were to leave the company, any existing encrypted messages are potentially vulnerable, and a new archiving key must be generated and distributed to all encrypting agents.
• Enforcing the use of the archiving key can be difficult. For messages to always be decryptable by the archiving agent, every encrypted message must be encrypted to the archiving key. If the archiving key is not included, for example because the encrypting agent was not aware of the requirement, the message will not be decryptable, potentially resulting in regulatory non-compliance.

With IBE, mixing encryption and archiving becomes much easier. Because all private keys can be generated on-the-fly from a single master secret, no special archiving key is required. If an authorized administrator or machine needs to read a message encrypted to 'foo@bar.com', it simply downloads the corresponding private key and decrypts the message. There's no way to encrypt a message such that it can't be decrypted at some point in the future; an organization can never lose access to its messages. Also, because a decrypting agent needs to be given access only to an individual recipient's private key, IBE doesn't introduce new security risks. No long-lived key needs to be stored by the archiving engine; IBE private keys are generally short-lived (e.g. one week), and can be requested on-the-fly by the decrypting entity. If that entity is compromised or becomes untrusted, only a small subset of emails are potentially vulnerable. Currently, the percentage of encrypted emails within the enterprise is small enough that these archiving issues haven't fully reared their head. But as privacy regulations start to butt up against archiving requirements, a practical encryption/archiving architecture will become increasingly important.

Enterprise Security Panel

The MIT Club of Northern California is sponsoring a panel discussion on enterprise security on Wednesday, 5/25/05 at 6:30.  It looks to be an interesting, wide ranging discussion.  The panel includes B.V. Jagadeesh, CEO, Netscaler; Michele Dundas Macpherson, Vice President of Services & Operations, Encentuate; Mark Kadrich, Senior Scientist, Sygate; and myself.  The MIT Club site has complete details here.

Why Johnny Can't Encrypt

When we founded Voltage, one of our core principles was that good security had to be usable.  At the end of the day, no matter how secure a system may be, if no one uses it you haven't really gained much. 

If you've never read it before, or even if it's just been a while, definitely check out "Why Johnny Can't Encrypt". It's a great academic usability study of certificate-based encryption systems (the authors specifically looked at PGP 5.0), examining why such systems are fundamentally too complex for the average user, and in fact can often lead users to reveal private information:

"Our case study used a cognitive walkthrough analysis together with a laboratory user test to evaluate whether PGP 5.0 can be successfully used by cryptography novices to achieve effective electronic mail security. The analysis found a number of user interface design flaws that may contribute to security failures, and the user test demonstrated that when our test participants were given 90 minutes in which to sign and encrypt a message using PGP 5.0, the majority of them were unable to do so successfully."

Since this paper was written, there have been a number of attempts to eliminate the end-user headaches associated with certificates, through methods such as enroll-on-behalf (designed by none than Terence).  But all of these optimizations fail to address the underlying problem: certificates, which are required to bind identities to keys, are inherently confusing to users and administrators.

By eliminating the need for the certificate binding (by enabling an identity to be used directly as a key), IBE is able to remove much of the complexity associated with PKI.  It's precisely the reason Shamir posed IBE as an open problem in 1984, and offers the best mechanism for finally making security systems usable by everyone.

Confessions of a PKI Convert

For my first blog post here, I thought I'd introduce myself and explain why I'm so excited to be working at Voltage.  As you may have read from my bio on Voltage's management page, I'm a long-time Microsoft veteran with some experience at some startups in Seattle.  When I first talked to the founders of Voltage in 2002, it was immediately clear to me that if this new "IBE" thing was real, it was going to seriously change computer security, and I could either be involved or watch it happen from the sidelines.

The reason I'm so excited about IBE is that I (and I'm not alone here) have spent years trying to make conventional PKI systems work in the real world.  The first few parts of any PKI system get implemented fairly easily.  Getting computers to enroll for certificates, and getting some basic signature applications going are pretty doable, and are what most PKI systems (including the one embedded in Windows) spend their time doing.  The real problem arises when you start mixing people and certificates.  It's hard, maybe even impossible, to design a certificate system that captures all the complexity of people's identities and isn't infinitely complicated.  I tried, and failed, several times.  Anyone that's wrestled with the certificate dialogs in Internet Explorer, Netscape, or any S/MIME client has seen how these systems usually turn out. 

The really amazing thing about IBE is how naturally it irons out these kinds of problems.  A user changes names?  No problem!  You have groups with rapidly changing membership?  Easy!  You need to locally recover data encrypted by a user that's left the organization?  It's a cinch.  I realize this all sounds a bit overwrought, but years of experience fighting with the complex scaffolding and protocols needed to make these features work with certificate systems makes the simplicity of IBE systems quite refreshing.

In future posts, I'll try to explain how we've used IBE in our applications, and how IBE can be leveraged as a security tool in a variety of systems, including those that already use PKI for some applications.