|
|
|
09 Dec 2003
Identity-based encryption is a relatively new encryption scheme
that can produce a public/private key pair from any string. This
approach has an important advantage: it makes it easier for mere
mortals to know the public key.
Traditional public key cryptographic schemes use numbers that
are hundreds of digits long--not something a human being can
remember easily. Even elliptic curve cryptographic keys are several
tens of digits long. Cryptographic systems put these keys into a
data structure called a certificate that includes a text string
humans can use to identify the certificate. In identity-based
encryption, the actual key is a function of a text string itself.
Identity-based encryption has two interesting properties:
1. You can give someone a key based on a string such an
email address. Because any string specifies a key, even strings
such as "President and CEO" are thus a public
key.
2. You can encrypt data to someone who does not yet have a key--or
more precisely, someone who doesn't yet know what his/her
key is because any string is a key. Thus, you could encrypt a
message to "alice@doman.tld" and email it to
Alice. Alice then merely has to get the private key associated with
her email address to decrypt the message.
However, like most things in life, this simple concept has some
complications and limitations:
-
There are details hidden in merely getting a private key
associated with a string. Obviously, the private key
can't be computed by just anyone, or it wouldn't
be a very good encryption scheme. The key pair is created not
just with the string, but with some secret that is kept on a
server. When Alice gets her private key, she gets it from a
server. She must also prove to the server that she's the
person who deserves that key. In other words, she must
authenticate herself to that server.
If Alice has no prior relationship with that server, this task
is difficult. There are any number of ways Alice could
authenticate herself; for example, she could use a certificate
that the server trusts. However, if she has a certificate the
server trusts, the server probably could have encrypted the
message to a public key associated with her in the first place.
(X.509 certificates were originally invented as a way to strongly
authenticate a user to a directory so the user could update
his/her personal information.) The server could mail Alice a
message that contains a password, but that's relatively
weak--and the server could always have encrypted the message to a
symmetric key derived from that password.
Although it's clever to be able to encrypt
opportunistically, figuring out a way for the recipient to
securely retrieve his/her private key is a hard problem.
Moreover, the solutions to this problem do away with the
advantages of an identity-based scheme.
-
Because all strings are keys, all typos are keys, too.
This is the dark, frustrating side of identity-based encryption.
Suppose the person who encrypted the message to Alice
accidentally encrypted it to "Alicia." Alice
will not be able to decrypt her message and won't know
why. Even worse: Suppose Alice knows the message was encrypted to
"Alicia." How is she going to prove to the
server that she's entitled to the
"Alicia" key when she is not Alicia,
she's Alice? This is an even harder problem if Alice is
actually "Alys."
- Those of you with relatively common, easily spelled names may
think I'm picking nits here. However, I have a relatively
unusual name, "Jon." I can't tell you
how many times it becomes "John." I find it
most amusing when someone gets my email address right,
jon@pgp.com, but then starts the message with a salutation of
"John." Even if I use my full name,
"Jonathan," that often gets mangled as
"Johnathan,""Jonathon," and
so on.
- These are important human factors issues. Cryptographic
systems are subject to many subtle attacks based on semantics and
human factors. Identity-based systems have vulnerabilities in
ways traditional systems do not because all possible strings are
keys. They aren't insurmountable problems, but they
require additional infrastructure.
-
Although identity-based systems eliminate part of the
certificate problem, they don't completely get rid of
it. It is true that the most important part of a certificate
is the name, but certificates are not merely names. They also
contain other attributes, such as validity dates, declarations of
what a certificate can and cannot be used for, and so on. An
identity-based scheme either has to have a certificate to hold
these attributes, or it must put them in the string that codes
the key. If you have a certificate anyway, then why bother with
an identity-based cryptographic system? If you code it into the
name, then you lose the whole reason for having it: that it can
be easily remembered. If my certificate is the string,
"<jon@pgp.com> good from 1/1/03 to
12/31/04, valid for document signatures only, not for purchase
orders," and any typo of that string is an equally valid
certificate, then perhaps I'd be better off with the old
fashioned type.
-
Because the system requires a server to hold secrets used to
create the keys, it is thus an escrowed system. Traditional
PKIs can be escrowed or unescrowed--it's an option, not a
requirement. Identity-based systems are
only escrowed systems.
-
The trusted server is a vulnerability. If it is
compromised or the secrets that generate the keys are lost, all
the keys are lost because anyone can then compute all possible
identity-based keys.
-
It makes key revocation a significant problem. Revocation
is a problem in any public key system, and a particularly
difficult problem in identity-based encryption. What happens if
someone loses his/her laptop? Does that mean he/she needs to get
a new email address as well as a new public key? And what happens
to role-based keys when the person in the role changes? In either
case, a traditional PKI lets users just create a new key. That
solution is not an option in an identity-based encryption system.
One way to handle this problem would be to have different sets of
secrets in the server: one for those people who have never lost
their keys, one for people who have lost them once, and so on.
Creating this type of solution merely requires some degree of
database expertise.
-
It multiplies the number of keys users have to juggle.
Today, it's common for people to have more than one email
address: for example, I am jon@pgp.com, jcallas@pgp.com, and
jon.callas@pgp.com. In a role-based authentication system, I
would probably also end up with keys for "CTO,"
"CSO," "Chief Technical
Officer," "CTO/CSO," and so on. With a
public key system like the one used in PGP solutions,
it's easy to have one key that responds to all those
names. With an identity-based encryption system, users will have
as many keys as they have email addresses and roles-each needing
correct spellings and suitable proofs of ownership.
-
It is not based on widely accepted standards. This is a
new public key system that does not interoperate with PGP
solutions, with X.509, or with anything else. And because
it's patented, there won't be standards for it
anytime soon. Anyone who buys this system can use it
only with other people who have also bought it. Note that
elliptic curve systems also have advantages over traditional
public key systems, having smaller keys and faster execution. But
they are also incompatible with existing standard systems and
encumbered by patents. These practical considerations nullify any
advantages that they have, and they have not spread.
These same issues are likely to put
friction on identity-based encryption adoption.
-
It requires all the same software as other systems.
Everything users need for a traditional PKI--including email
plugins, authentication, servers, and so on-is also needed for an
identity-based encryption system. Ironically, this list even
includes a directory server because there has to be some way to
know what types of key requests are valid. Although the system
does not require a Certificate Authority (CA)
per se, users still need something akin to a CA: the
"authoritative server" from which they get
their keys.
Summary
Identity-based encryption has interesting mathematical
properties, such as being able to create a public/private key pair
from a string. Although this system has some advantages over a
traditional PKI, it also has a number of disadvantages as well.
Identity-based encryption's advantages make sense for
offline systems. However, in a world with pervasive networking, the
advantages of identity-based encryption can be built into an
existing PKI with intelligent servers to manage the keys for the
users. This is what we at PGP Corporation have done with PGP
Universal. PGP Universal Server gives users all the advantages of
identity-based encryption while maintaining compatibility with
existing PKIs and cryptographic systems.
Identity-based encryption is an interesting new technology, and
had it been invented in 1984, or even 1994, it might be the
dominant form of public key cryptography today. Instead, the spread
of pervasive networking means that the mathematical advantages of
identity-based encryption are delivered with good old fashioned
software engineering and systems design. However innovative it is,
identity-based encryption is simply not needed in the twenty-first
century.
Background reading
Boneh, D. and M. Franklin,
"Identity-Based Encryption from the Weil
Pairing" [PDF], 2001
Boyen, Xavier,
"Multipurpose Identity-Based Signcryption:
A Swiss Army Knife for Identity-Based Cryptography"
[PDF], International Association for Cryptologic Research, 2003
Chromatic,
"Terence Spies on Identity-Based
Encryption," July 17, 2003
IBE
Secure E-Mail
|
