IBE Secure E-mail

Description Publications Technical Summary Project Staff



An Identity Base Encryption (IBE) scheme is a public-key cryptosystem where any string is a valid public key. In particular, email addresses and dates can be public keys. The IBE email system is based on the first practical Identity-Based Encryption scheme (IBE). The cryptosystem has chosen ciphertext security in the random oracle model assuming an elliptic curve variant of the computational Diffie-Hellman problem.

The IBE email system has some nice properties such as:

More information is given below. The main objective of this project is to encourage use of encrypted email.


Technical Summary

In 1984 Shamir asked for a public key encryption scheme in which the public key can be an arbitrary string. Encryption schemes of this type are called Identity Based Encryption (IBE). Shamir's original motivation for identity-based encryption was to simplify certificate management in e-mail systems. When Alice sends mail to Bob at she simply encrypts her message using the public key string ``''. There is no need for Alice to obtain Bob's public key certificate. When Bob receives the encrypted mail he contacts a third party, which we call the Private Key Generator (PKG). Bob authenticates himself to the PKG in the same way he would authenticate himself to a CA and obtains his private key from the PKG. Bob can then read his e-mail. Note that unlike the existing secure e-mail infrastructure, Alice can send encrypted mail to Bob even if Bob has not yet setup his public key certificate. However, in this scenario the IBE system provides key escrow since the PKG knows Bob's private key. Other applications (discussed below) do not require key escrow. In more detail, an IBE scheme consists of four algorithms: (1) Setup generates global system parameters and a master-key, (2) Extract uses the master-key to generate the private key corresponding to an arbitrary public key string ID, (3) Encrypt encrypts messages using the public key ID, and (4) Decrypt decrypts messages using the corresponding private key.

Since the problem was posed in 1984 there have been several proposals for IBE schemes. However, none of these are fully satisfactory. Some solutions require that users not collude. Other solutions require the PKG to spend a long time for each private key generation request. Some solutions require tamper resistant hardware. It is fair to say that, until now, constructing a usable IBE system was an open problem.

The IBE email system uses a new fully functional identity-based encryption scheme. The performance of the cryptosystem is comparable to the performance of ElGamal encryption. The security of the system is based on a natural analogue of the computational Diffie-Hellman assumption on elliptic curves. Based on this assumption we show that the new system has chosen ciphertext security in the random oracle model. Using standard techniques from threshold cryptography the PKG in the system can be distributed so that the master-key is never available in a single location. This enhances security of the master-key stored at the PKG.

Applications for Identity-Based Encryption

The original motivation for identity-based encryption is to help the deployment of a public key infrastructure. More generally, IBE can simplify systems that manage a large number of public keys. Rather than storing a big database of public keys the system can either derive these public keys from usernames, or simply use the integers {1, ... ,n} as distinct public keys. We discuss several specific applications below.

Revocation of Public Keys

Public key certificates contain a preset expiration date. In an IBE system key expiration can be done by having Alice encrypt e-mail sent to Bob using the public key: || current-year . In doing so Bob can use his private key during the current year only. Once a year Bob needs to obtain a new private key from the PKG. Hence, we get the effect of annual private key expiration. Note that unlike the existing PKI, Alice does not need to obtain a new certificate from Bob every time Bob refreshes his certificate.

One could potentially make this approach more granular by encrypting e-mail for Bob using || current-date . This forces Bob to obtain a new private key every day. This might be feasible in a corporate PKI where the PKG is maintained by the corporation. With this approach key revocation is quite simple: when Bob leaves the company and his key needs to be revoked, the corporate PKG is instructed to stop issuing private keys for Bob's e-mail address. The interesting property is that Alice does not need to communicate with any third party to obtain Bob's daily public key. This approach enables Alice to send messages into the future: Bob will only be able to decrypt the e-mail on the date specified by Alice.

Delegation of Decryption Keys

Another application for IBE systems is delegation of decryption capabilities. We give two example applications. In both applications the user Bob plays the role of the PKG. Bob runs the setup algorithm to generate his own IBE system parameters params and his own master-key. Here we view params as Bob's public key. Bob obtains a certificate from a CA for his public key params. When Alice wishes to send mail to Bob she first obtains Bob's public key params from Bob's public key certificate. Note that Bob is the only one who knows his master-key and hence there is no key-escrow with this setup.

Delegation to a laptop. Suppose Alice encrypts mail to Bob using the current date as the IBE encryption key (she uses Bob's params as the IBE system parameters). Since Bob has the master-key he can extract the private key corresponding to this IBE encryption key and then decrypt the message. Now, suppose Bob goes on a trip for seven days. Normally, Bob would put his private key on his laptop. If the laptop is stolen the private key is compromised. When using the IBE system Bob could simply install on his laptop the seven private keys corresponding to the seven days of the trip. If the laptop is stolen, only the private keys for those seven days are compromised. The master-key is unharmed.

Delegation of duties. Suppose Alice encrypts mail to Bob using the subject line as the IBE encryption key. Bob can decrypt mail using his master-key. Now, suppose Bob has several assistants each responsible for a different task (e.g. one is `purchasing', another is `human-resources', etc.). Bob gives one private key to each of his assistants corresponding to the assistant's responsibility. Each assistant can then decrypt messages whose subject line falls within its responsibilities, but it cannot decrypt messages intended for other assistants. Note that Alice only obtains a single public key from Bob (params) and she uses that public key to send mail with any subject line of her choice. The mail can only be read by the assistant responsible for that subject.

Project Staff

Applied crypto group

Last update: Mon Apr 8 03:58:58 PDT 2002 blynn