IBE Secure E-mail
Downloads
Description
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:
- Senders can send mail to recipients who have not yet setup
a public key,
- When sending email there is no need for an online lookup to obtain the recipient's certificate,
- Senders can send email that can only be read at some specified time in the future, and
- The system proactively refreshes the recipient's private key every short
time period.
More information is given below. The main
objective of this project is to encourage use of encrypted
email.
Publications
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 bob@hotmail.com she simply encrypts her message
using the public key string ``bob@hotmail.com''. 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:
bob@hotmail.com || 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 bob@hotmail.com || 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