ISTR 0803.
qxd 13/11/2003 15:41 Page 57
A comparison between traditional
public key infrastructures and
identity-based cryptography
Abstract
With the recent acceleration in research
into identity-based public key cryptography
(ID-PKC), we consider this to be an
opportune moment to compare and contrast
ID-PKC with more traditional public key
infrastructures (PKI). Because of the
similarity in the nature of both approaches,
we aim to identify the distinguishing features
of each approach. In doing so, we highlight
the important questions to be asked when
weighing up the benefits and drawbacks of
the two technologies.
Keywords: public key infrastructure;
identity-based cryptography; asymmetric
cryptography; digital signatures;
certificates; non-repudiation
1 Introduction
With the recent increase in research
focused on identity-based (or identifier-
based) public key cryptography (ID-PKC),
we set out to compare these systems to
more traditional public key infrastructure
(PKI) systems using certificates. Our work
is focused on architectural, key management
and associated issues; we do not consider
implementation details in any great depth.
The main goal of this article is to ask the
question ‘What are the differences between
these systems from a practical viewpoint?’.
The main technical difference between
the two systems is in the binding between
the public and private keys and the means
of verifying those keys. In a traditional PKI,
this is achieved through the use of a
certificate. In an ID-PKC system, the
binding between the private key and the
authenticity data is managed by a trusted
authority (TA) at the point of request, while
the binding between the public key and that
data can be done by anyone at any point.
We identify the technology behind
ID-PKC as being a useful addition to the
security practitioner’s armoury. However, Kenneth G. Paterson1
we wish to tackle the notion that is Geraint Price
prevalent in many existing discussions Information Security
about the extent to which ID-PKC avoids Group, Mathematics
trust problems encountered in certificate- Department, Royal
based PKIs. While ID-PKC certainly does Holloway, University of
provide a new technological means of London, Egham, Surrey,
managing trust, it does not avoid the TW20 0EX.
problems that are inherent in this difficult
task. kenny.paterson@rhul.ac.uk
geraint.price@rhul.ac.uk
The remainder of this paper is organised
as follows. In Section 2 we provide an
overview of the two technologies. In Section
3 we discuss some of the issues that are
relevant to the design of a security
architecture using either mechanism. The
main focus of this paper is on how the keys
and the associated rights are managed
under these mechanisms; these are covered
in Sections 4 and 5, respectively. In Section 6
we discuss emergent hybrid mechanisms
that have the potential to overcome some of
the drawbacks of ID-PKC in certain
scenarios. We conclude in Section 7 with a
discussion of the main issues raised
throughout the paper.
2 Technological overview
In this section we provide a brief
technical overview of traditional PKIs and
ID-PKC.
Both technologies are variants of
asymmetric cryptography, a concept
introduced by Diffie and Hellman [1] in the
mid-1970s. Until their groundbreaking
paper, all cryptosystems had relied on
symmetric cryptography, where both
communicating parties shared a copy of the
same key. In the model of [1], a related pair
of keys is generated. The user retains one
half of the key for private use, while
allowing the other half to be made public.
The private key can then be used to either
decrypt a document that has been 1 Supported by the Nuffield
encrypted under the corresponding public Foundation NUF-NAL02.
1363-4127/03/© 2003, Elsevier Ltd 57
ISTR 0803.qxd 13/11/2003 15:41 Page 58
PKI re-visited – current issues and future trends
key or to sign a message which can then be
verified with the public key.
The main difference between the two
variants of asymmetric cryptography that
we focus on here is in the generation of the
keys. In traditional asymmetric
mechanisms, which underpin most PKI
products on the market today, the key pair
is generated from random information that
is unrelated to the method identifying that
key pair within the system. As such, there is
a requirement for a certificate to bind the
public key to its particular use.
In contrast, the key pair in an ID-PKC
environment is generated explicitly from
data that is of relevance to the usage of the
key. For example, a user’s encryption and
decryption keys may be derived from their
identity within the system in which they are
to be used.
We expand our review of PKI and ID-
PKC in Subsections 2.1 and 2.2, respectively.
We conclude our technological overview in
Subsection 2.3 with a discussion of how the
security policies that make use of these keys
can reflect the underlying technology.
2.1. Public key infrastructures
Public key infrastructures (PKIs) are
currently the primary means of deploying
asymmetric cryptography. In this paper,
when discussing PKIs we are referring to
infrastructures that support the deployment
of traditional asymmetric cryptographic
algorithms, such as RSA [2]. Because of the
inherent public nature of the encryption or
verification keys, the integrity of the public
keys is usually protected with a certificate.
The PKI is the infrastructure that supports
the management of keys and certificates.
As well as the keys and certificates, the
core components of a PKI are:
Certificate authority (CA): The CA is the
entity that generates the certificates. It is
58 Information Security Technical Report. Vol. 8, No. 3
responsible for ensuring that the correct key
is bound to the certificate, as well as
ensuring the certificate content.
Registration authority (RA): The RA is
responsible for ensuring that the user who
receives the certificate is a legitimate user
within the system. The functionality of the
CA and RA is sometimes carried out by a
single entity.
Certificate storage: In most systems,
certificates (as well as update information
such as certificate revocation lists) are
stored in a CA-managed database.
Software: For the certificates to be of
use, the software that is going to use the
certificates needs to be aware of what the
certificate content represents within the
scope of the system security policy.
Policies and procedures: Although the
core of a PKI is mainly technical, there is,
by necessity, a strong requirement for
ensuring that the mechanisms are used
correctly. The certificate policy (CP) and
certification practice statements (CPS)
define the how the certificates are generated
and managed. They also define the role of
the certificates within the broader security
architecture.
In a traditional PKI, one can choose
where the key pair is generated. The keys
can either be generated by the CA for the
client or the client can generate the keys for
itself and provide a copy of the public key
to the CA to certify. The choice of
mechanism will largely be dictated by the
security policy of the system. It will also be
influenced by the key usage. If a signature
key is likely to be used to support non-
repudiation, then it is better that the key is
generated by the client. In the case of a
decryption key that is used to keep
company information confidential, it might
be prudent to have the CA generate (or have
access to) the key so that there is always a
means of recovering encrypted information.
ISTR 0803.qxd 13/11/2003 15:41 Page 59
Kenneth G. Paterson & Geraint Price A comparison between traditional PKIs and identity-based cryptography
2.2. Identity/identifier-based public
key cryptography
One of the difficulties inherent in
running a PKI is in the management of the
certificate and associated key. Identity, and
subsequently identifier–based,
cryptography was created as a means to
overcome this problem. Shamir [3] was the
first to propose such a scheme in which the
key itself is generated from some publicly
identifiable information, such as a person’s
e-mail address. His original scheme
provided a signature algorithm, but could
not be used for encryption. It is only
recently that an efficient identity-based
encryption system was proposed by Boneh
and Franklin [4].
The core difference between an ID-PKC
and a traditional asymmetric algorithm is
the means of generating the keys. The
difference is manifested in two ways:
• As mentioned above, in both the
signature and encryption variants, the
public keys are generated from publicly
identifiable information. This allows a
client A to generate the public key of
another client B without having to do a
search in a directory or ask B for a copy of
their key.
• Because of the mathematics that
underpin the algorithms, the creation of the
private key requires the knowledge of a
master secret that is held by the trusted
authority (TA), which is the analogue of the
CA in a PKI.
Recently, it has been recognised that an
identity does not need to be the only
determinant of a client’s public key. For
example, information such as the client’s
position within an organisation and the
validity period for the keys etc can be
included in the data that is used to derive
the key pair. This results in the broader
concept of identifier-based public key
cryptography.
Information Security Technical Report. Vol. 8, No. 3
Because the TA is directly responsible for
the generation of the private key in an ID-
PKC mechanism, there is an inherent escrow
facility in the system. This may or may not
be desirable. This forces a change in the role
of the trusted third party within the system.
In a PKI, the CA is concerned with
validating the authenticity of the
information that is present in the certificate,
whereas in an ID-PKC the TA is directly
responsible for generating and distributing
all keying material within the system.
There is also the requirement that the TA
and client are able to set up an independent
secure channel for the distribution of
private key material. This channel needs to
protect both the authenticity and
confidentiality of the private key.
Although the idea of using a client’s
identity as the base for their key pair is very
appealing, it does not come without
consequences. The two main issues that will
influence the discussion in the remainder of
this paper are as follows:
• Coping with the practicalities of
implementation are not insignificant. If we
take revocation as an example, because we
cannot revoke a person’s identity there is a
requirement for additional input to the key
generation process. If we include validity
dates, key usage etc, then a push toward
broader use of identifying information leads
naturally to identifier-based cryptography.
We will return to revocation issues in
Subsection 4.3.
• The authenticity of the information
that is used as the identity or identifier is
now crucial to the security of the system. In
a PKI, the certificate is supposed to
demonstrate the authenticity of identifying
information. In ID-PKC, because a private
key may be generated after the public key,
the TA may not have validated the
authenticity of the information relating to
59
ISTR 0803.qxd 13/11/2003 15:41 Page 60
PKI re-visited – current issues and future trends
the key pair prior to the public key’s use.
For example, A might use information it
thinks is valid to generate a public key for
B, but the information A uses could either
relate to the wrong B or be completely
invalid in the eyes of the TA.
2.3. Policy interaction
In closing the discussion in this section
we will outline what we see as one of the
main questions to be answered when
deciding whether a system should use PKI
or ID-PKC as its cryptographic mechanism.
This is: how do the security policies of the
communicating parties interact with those
of either the CA or the TA?
As mentioned previously, because the
TA is explicitly in charge of the generation
of the private keys in an ID-PKC system, it
can verify its security policy each time it
hands out a new private key to a client. In
the case of the CA in a PKI, the policy is
verified at the time of certification, but it
is generally left up to the client encrypting
the information to verify the certificate
content in the light of its own security
policy.
While neither of these design principles
is strict — we could, for example, mimic
the requirement to always fetch a new key
from a TA within a PKI — the way in which
the information flows through the system is
an important consideration when deciding
which mechanism to use.
Expanding on the example given above, it
would seem more natural to implement an
ID-PKC for short-term keys where the
policy at the TA might change regularly.
Conversely, it would seem sensible to use a
PKI either in a widely distributed
environment or in an environment where
the individual policy of each client plays a
significant role in the policy of the system
as a whole.
60 Information Security Technical Report. Vol. 8, No. 3
3 Architectural issues
ID-PKC was introduced as a means of
circumventing the difficulties associated
with certificate management within PKIs.
This has led to a difference in the way the
two proposed mechanisms are architected.
In this section we briefly look at the way in
which this might affect the choices that are
made when deciding between the two as a
security architecture.
In the following list, we outline the
architectural issues as we see them:
• On first inspection, there appears to be
a potential for ID-PKC to develop more
lightweight implementations at the client
end. This is due to the lack of a
requirement for storing separate
certification, identification and keying
information. Provided that the authenticity
of such information could be verified, this
could be useful for scenarios such as mobile
systems, where knowing the identity of the
other contact point in an interaction could
be enough to generate keying information
on the fly.
• It would appear that a PKI would be
the implementation of choice in a widely
distributed system. The ability of clients to
generate their own key pairs to be certified
by a CA that need not be directly in their
security domains could provide benefits in
some scenarios. For example, the use of
third-party CAs to certify SSL server keys
would be difficult to replace using ID-PKC.
The key escrow facility inherent in ID-PKC
would probably not sit well with a
corporation that wishes to secure its
Internet gateway using an SSL-enabled
server.
• Within systems where the security is
heavily centralised (i.e. where all users must
trust the CA/TA explicitly anyway), there
doesn’t seem to be a great deal of difference
between PKI and ID-PKC. The choice of
which mechanism to implement is likely to
ISTR 0803.qxd 13/11/2003 15:41 Page 61
Kenneth G. Paterson & Geraint Price A comparison between traditional PKIs and identity-based cryptography
come down to how the protocols that use
those mechanisms fit in the wider
architecture of the system. This is similar to
the situation where there is often little to
choose between a symmetric and an
asymmetric system in applications where
non-repudiation is not a concern.
• In distributed systems where it is
difficult to manage a revocation mechanism
(e.g. mobile systems), one way in which
PKIs aim to deal with the problem is to use
short-lived certificates. This might be
addressed more efficiently using ID-PKC, as
the system would only require partial
synchrony for the sender to generate a
currently valid key for the recipient.
• One of the proposed benefits of PKIs is
that they can be organised into hierarchies
that reflect the internal structure of a large
organisation or group of organisations.
While this might seem to provide an
advantage for PKIs, recent work by Gentry
and Silverberg [5] develops mechanisms for
implementing similar hierarchies in an ID-
PKC context.
• An area where PKI seems to have a
distinct advantage over ID-PKC is in the
consequences of the compromise of the
CA/TA. While the compromise of a CA is
disastrous to the future secure running of the
system, if the system has been designed
carefully then all past encrypted traffic is still
secure. If the TA within an ID-PKC system is
compromised and the master secret revealed,
by the very fact that the attacker now knows
the secret from which all keys are derived,
the attacker can now decrypt all previously
encrypted information. The same would be
true of signature keys. As a result, any
signature on a document that had not been
independently time-stamped could be called
into question.
4 Key management
In this section, we analyse the differences
between PKI and ID-PKC by examining the
Information Security Technical Report. Vol. 8, No. 3
way in which they manage keys. We
separate our discussion into three topics:
generation of public keys, generation of
private keys, and revocation of keys.
When discussing the generation of keys
we concentrate on the following four
questions: Who generates the keys? When
are the keys generated? Where are the keys
generated? and How are the keys generated?
4.1. Generation of public keys
In this section we look at the generation
of the public halves of the key pairs and
how that might affect the design of a
security service built on top of them.
In terms of the questions that we ask
with regard to key generation, here are the
differences between public key generation in
the two schemes:
• Within a PKI, the public key is
generated at the same time as the private
key. This limits the creation of the public
key to either the CA or the client. Within an
ID-PKC, the public key can be generated by
any client within the system. Moreover, the
public key can be chosen by any client in
the system. It is then incumbent on the
other party to obtain the matching private
key from the TA; this is the essence of
identifier-based PKC.
• Within a PKI, the keys are generated
prior to the issuance of a certificate. The
validity of the binding between the public
and private keys should be checked by the
CA before issuing the certificate. Within an
ID-PKC, because of the separation between
generation of private and public keys, a
public key can be generated at a different
time to the private key, and hence also at a
different time to the validation of the
issuance of the private key.
• Within a PKI, the public key is either
generated at the CA or by a process which
the client deems to be trustworthy. In an ID-
PKC, the public key is generated at the site
61
ISTR 0803.qxd 13/11/2003 15:41 Page 62
PKI re-visited – current issues and future trends
of the client that wishes to use the public
key.
• Within a PKI, the public key usually
results from a process that makes use of a
random secret input to generate both public
and private keys. In an ID-PKC, the public
key is generated from public information.
The ability within an ID-PKC to
generate a public key from public
information at a time that is different
from the generation of the private key
provides us with perhaps the biggest
difference between ID-PKC and PKI. Chen
et al [6] use this feature of ID-PKC to
enable the control of work-flow within a
system. In brief, their proposal allows the
client to encode a policy that specifies
conditions under which decryption can
take place. The client that wishes to
decrypt the message must then
demonstrate compliance with the policy to
the TA before it is issued with the
corresponding private key.
We now examine how these differences
manifest themselves in terms of keys for
encryption and signature verification.
Encryption
For ID-PKC, the client that generates the
ciphertext can generate the encryption key
without having to know the identity of the
client that will decrypt the message. This
has the potential benefit of allowing the
policy compliance to be encoded directly
into the encryption key. For PKI, in order to
decrypt the message in advance, the client
would need to know the public key that was
related to the private key to be used —
usually the decryption key bound to the
recipient’s identity. This would seem to
make it less flexible than ID-PKC. However,
we can mimic this ID-PKC functionality in
a PKI by encrypting the message directly for
the CA and attaching the decryption policy
to the ciphertext.
62 Information Security Technical Report. Vol. 8, No. 3
Signature verification
For ID-PKC, the verification key is
generated from the signer’s identity. This
can be carried out either by the signer, who
then attaches the verification key to the
signed message, or by the verifier, who
calculates it at the time of verification. In a
PKI, the verification key is created at the
same time as the signing key, and the
certificate that contains the verification key
often accompanies the signature. Within a
signature scheme, a public key is only of
any use when verifying a signature, which
implicitly requires the prior generation of a
private key. Because a PKI allows the signer
to attach a certificate to the signature, it
seems that ID-PKC’s advantage of being
able to generate keys independently holds
little advantage in this scenario.
Because of the close relationship between
the generation of both public keys and
private keys, we combine some of the issues
raised here with the discussion at the end of
Subsection 4.2.
4.2. Generation of private keys
In this section we analyse how the way in
which private keys are generated in each
approach can potentially affect their usage.
In terms of the generation of the private
key, the main difference between the two
approaches is that, with ID-PKC, the key
must be generated by the TA. On the other
hand, in a PKI there is a choice of having
the private key generated by the CA or the
client.
This enforcement of the private key
generation by the TA within ID-PKC raises
concerns of escrow and/or privacy
surrounding the management of private
keys. This might be of benefit to an
encryption scheme in a business
environment where the company owns the
data, but is a drawback in an
ISTR 0803.qxd 13/11/2003 15:41 Page 63
Kenneth G. Paterson & Geraint Price A comparison between traditional PKIs and identity-based cryptography
implementation for digital signatures that
might want to offer non-repudiation. Boneh
and Franklin [4] have proposed a means of
circumventing the escrow problem by using
multiple TAs and threshold cryptography.
Collusion between independent TAs would
then be required for a copy of the private
key to be generated.
While the notion of who generates and
controls the key is of interest to those in the
academic community, it is also becoming an
important issue for those running signature
applications. The EU Directive on
Electronic Signatures [7] states that a key
that is used as an Advanced Electronic
Signature should be under the sole control
of the individual named in the qualified
certificate.
Before entering further into the
discussion of the relative merits between
PKI and ID-PKC in this area, we note that
our discussion in Section 6 outlines recent
research that could potentially be used to
overcome the drawbacks of private key
generation in ID-PKC schemes.
We now analyse the differences in private
key generation for ID-PKC and PKI. We do
this by separately considering encryption
and signatures.
Encryption
For ID-PKC, the private key needs to be
provided to the decrypting party by the TA.
Whether this key will be fresh for this
particular session/message depends on
whether the client generating the ciphertext
used a long-term or a short-term public key.
This is a policy decision that is influenced
by the system security policy in conjunction
with the policy of the client carrying out
the encryption. For PKI, the public
encryption key that is used is usually the
client’s long-term key bound to their
certificate, although a short-term key could
Information Security Technical Report. Vol. 8, No. 3
also be used. If a long-term key is used,
there seems to be little difference between
the two schemes. The main difference
comes to light when we consider the
creation of session-oriented private keys
whose release is managed by the TA, as in
the work of Chen et al [6].
Signature
For ID-PKC, the private key is generated
by the TA and given to the client. Because
signature schemes should normally uniquely
identify the creator of the signature, the
inherent key escrow in ID-PKC makes it a
less attractive choice. For PKI, the key is
generated by either the CA or the client.
This ability to choose who generates the
private key offers PKI an advantage in terms
of flexibility over ID-PKC. A proposed
benefit of ID-PKC over PKI — the
separation between the public and private
key generation — does not immediately
appear to be of use here, as we discussed in
Subsection 4.1.
We now discuss some of the issues raised
when analysing the differences between the
management of keys in ID-PKC and PKI:
• It would appear that, in an ID-PKC
implementation, the TA needs to retain a
database of every ID to which a key has
been issued under the current system
parameters. Otherwise, there is potential
for the following scenario to arise. A key
could be generated, used, and either
revoked or removed at the end of its natural
life-cycle. At some point in the future,
another client could request a key with the
same ID, perhaps with a legitimate reason
(e.g. the users share a common name). The
two users will now share the same
public/private key pair. At first glance it
would appear that a similar problem was
inherent in PKI, in that the same ID could
be certified, but there is a difference. In ID-
PKC, because of the inherent link between
63
ISTR 0803.qxd 13/11/2003 15:41 Page 64
PKI re-visited – current issues and future trends
ID and public key, the keys will actually be
the same. In a PKI implementation, the keys
are generated separately and usually using
some client-controlled randomness. This
means that the keys will almost certainly be
different, even if the identities are the same.
• A related issue is raised if we consider
the standard ID-PKC solution to the above
problem. This is to include, as part of the
identity, additional detail such as date of
birth, position in the organisation etc. The
more worried one is about duplication
within the system, the more the content of
the identity starts to mirror the content of
the certificate in a PKI. Where does this
leave us? The client must now contend
with two issues when generating another
client’s public key. What is the correct form
in which the identity should be created?
What is the content of each field type, such
that the TA will give the corresponding
private key to the correct recipient? By
going down this path, we end up with a
similar set of standards problems that are
faced by the implementors of PKIs. How
does a client know what each field in an
identifier is meant to represent? There
must be agreement between
communicating parties and the TA. Thus,
we note that removing the certificate from
the system does not solve all the problems
that are of relevance to certificate
management.
• Both previous points are specific
problems that are encountered when we
realise that, in ID-PKC, the public keys and
the identity are inexorably linked. In a PKI
the separation is clear. Whether this is
considered a benefit or a drawback can only
be resolved when it is considered in the light
of a particular application.
• There is a potential safety issue when
considering the generation of public keys in
an ID-PKC scheme. Because it is the client
that chooses the identity to be used to
generate the public key, they could choose
64 Information Security Technical Report. Vol. 8, No. 3
an identity for which the TA will not release
the corresponding private key. This could
leave the intended recipient unable to read
vital information, or result in the need for
manual intervention and override. Such
intervention may not be convenient if, say,
the private key generation is done in a
hardware security module.
4.3. Revocation
Revocation is one of the main difficulties
faced by implementers of PKIs. While ID-
PKC does not have a certificate per se, the
issue of how to manage the
identity/identifier relevant to a particular
public key has so far received very little
attention. This problem is analogous to the
problem of certificate management in a
PKI. In this section we will argue that
revocation could potentially become as
great a concern for ID-PKC as it currently is
for PKI.
Here are the three main issues that we
see for revocation in ID-PKC:
• As mentioned in the previous section,
keeping track of identities that have been
issued within the system is a potential
problem for key management. Because of
the strong link between keys and identities
in ID-PKC, revoking a public key requires
the revocation of the associated identifier.
This problem is acute if the identifier is one
that could be inconvenient to change (such
as an e-mail address). But these are precisely
the identifiers that are easily predicted by
the entity that is attempting to
independently generate a valid key for an
intended recipient. This suggests that less
predictable identifiers would need to be
employed. For example, the inclusion of
issue numbers in identifiers is conceptually
simple, but leads to identifiers that are
difficult to predict. So, in actual
implementations, it is likely that more
complex identifiers, built on top of a
client’s identity, will provide the input to the
ISTR 0803.qxd 13/11/2003 15:41 Page 65
Kenneth G. Paterson & Geraint Price A comparison between traditional PKIs and identity-based cryptography
key generation function. This means that
there is likely to be a higher degree of
complexity in the part of the system that
manages those identifiers than might appear
at first sight. This is related to the issue
about form and content of identifiers that
was noted in Subsection 4.2.
• Because of the inherent binding
between identifier and key in ID-PKC, there
is a potential drawback in terms of re-
certification. At a recent PKI workshop, we
saw a demonstration for a product that
separated the storage of private key and
certificate. The private key was stored on a
smart-card, while the certificate was stored
on the hard drive. This allowed the
organisation to change the certificate
content through re-certification without
needing to go through the more expensive
procedure of issuing the clients with a new
private key. An exact replica would be
impossible to achieve in an ID-PKC system.
• When considering the issue of
revocation, Boneh and Franklin [4]
proposed merging the date with the client’s
identity to provide the identifier for the key
(e.g. the string ‘Alice,12MAR2003’ could
provide the input for the key generation
function). The argument provided is that
the re-issuance of keys on a per time basis
obviates the need for a revocation
mechanism. This mechanism raises a few
problems. If we force all legitimate users to
request fresh keys every day (or even every
hour, if a finer degree of control is needed),
then it forces the TA to be on-line for a
greater proportion of the time and may
significantly increase the TA workload. The
ability to remove the need for an on-line
server is one of the benefits of using
asymmetric cryptography in the first place.
It could be argued that having an OCSP or
CRL server in a PKI has the same
drawback. This is not necessarily true: a
CRL can be distributed by a server that is
not the root CA. Another problem with
Information Security Technical Report. Vol. 8, No. 3
Boneh and Franklin’s model of revocation is
that it requires an independent secure
channel between the channel and the TA for
the transportation of the fresh keying
material. In a traditional PKI, the
registration, key generation and
certification procedures should be among
the most heavily guarded. Applying this
same level of security daily in an ID-PKC
could make the process inherently difficult
to manage.
To put it more succinctly, revocation in a
PKI requires reliable and timely distribution
of authenticated information. Revocation in
an ID-PKC, using the methods discussed
here, requires the reliable and timely
distribution of confidential information.
5 Rights management
In this section we analyse the differences
in the manner in which rights are handled
in PKIs and ID-PKC systems. The term
rights in this discussion encompasses
anything that the possession of a key
and/or related certificate/identifier allows
the client to do. For example, a right could
be ‘The right to view confidential report
X’ or ‘A, being a purchase manager, can
sign orders up to a value of $10 000’. As
such, we use the term in as neutral a form
as possible, to highlight the fact that rights
represent any extension of the services that
encryption and signature algorithms
provide.
We separate our discussion here into the
issues surrounding the generation and
verification of these rights.
5.1. Rights generation
In this subsection we introduce the basic
means by which rights are represented in
each approach and how these
representations are generated. We split our
discussion into two parts: one concerning
rights implemented using signatures; the
65
ISTR 0803.qxd 13/11/2003 15:41 Page 66
PKI re-visited – current issues and future trends
other concerning rights implemented using
encryption.
Signature
PKI
In PKI, the signing key is usually bound
to an identity. Depending on the system
policy, the right to sign is either implicit in
the verifier knowing who the signing party
is, or it is explicit through a binding to an
authorisation mechanism. The
authorisation mechanism could be a more
traditional access control list, a separate
privilege management infrastructure (PMI),
or contained in the client’s identity
certificate. The right to sign for a particular
purpose is assessed either by the CA when
generating the identity certificate or by the
authority in charge of the separate
authorisation infrastructure.
ID-PKC
In an ID-based scheme, it would appear
that the same principles apply. The popular
choice for a signature creation key is likely
to be some variant of the signing party’s
identity. The right to sign is likely to be
either implicitly recognised between signer
and verifier or more explicitly contained in
an additional mechanism, similar to those
discussed above for PKIs. Again, the right to
sign will be assessed at the time of the
signature key’s creation or when the identity
is bound to the associated authentication
mechanism.
Encryption
PKI
Traditionally, PKIs have primarily been
associated with authentication rather than
authorisation (SPKI [8] being the notable
exception). In most commercial PKI
systems, the identity certificate is used to
authenticate the client to a separate
authorisation infrastructure. As in the above
discussion on signatures, the right to
66 Information Security Technical Report. Vol. 8, No. 3
decrypt can be either implicit or explicit.
For example, Alice may know Bob
personally and thus be willing to use the
encryption key in Bob’s certificate — this
may be the case when using e-mail security
software. Alternatively, Alice might want to
see Bob’s credentials as a line-manager
before passing on an encrypted version of
the payroll file. In both cases, the right to
decrypt is generated when the identity
certificate or authorisation token is
generated.
ID-PKC
As with PKIs, the right to decrypt can be
generated at the same time as the private key,
in advance of the decryption. One of the
proposed benefits of using ID-PKC is that
the public encryption key can be generated
by the party that is encrypting the data in
advance of the corresponding private key
having been generated. If used in this
manner, the right to decrypt is effectively
generated when the client that is encrypting
the message generates the public key. But the
subsequent verification of that right does not
happen until the TA generates the
corresponding private key, which may
happen at some point in the future.
5.2. Rights verification
We now turn our attention to how the
verification of rights might take place. Our
goal in this section is to understand how the
means by which these rights are verified
affects the design of the system. To achieve
this, we keep our discussion at a generic
level and develop our argument by the
analysis of the following three factors for
signatures and encryption:
Who: Who is capable of carrying out the
verification?
When: When is the verification carried
out in relation to the right generation?
Where: Is there a physical or logical
relationship between generation and
ISTR 0803.qxd 13/11/2003 15:41 Page 67
Kenneth G. Paterson & Geraint Price A comparison between traditional PKIs and identity-based cryptography
verification that might affect the security
policy?
We note that, in an attempt to keep our
analysis as broad as possible, we describe
the most logical means of implementing the
rights verification functions.
Signature
We separate the analysis of PKI and ID-
PKC systems.
PKI
Who: In the case of signature
verification, anyone who can use the public
key associated with the signature key can
verify the signature. This does not
necessarily mean that they will be able to
accurately verify the associated rights that
may be bound to the public key through a
certificate. One of the influencing factors
would be whether the verification of the
right to sign was implicit, in the sense that
A knows B, or explicit, through some other
mechanism.
When: The verification occurs when the
client verifying the signature carries out the
signature validation. In terms of time, this
could potentially be far removed from the
time that the signature was created. This
flexibility in separation is potentially both a
benefit and a drawback. If the signature is
created on a document that may need to be
verified multiple times by multiple parties,
then this is a benefit. If, on the other hand,
the signing party’s right to sign may be
brought into question in the future, then
there is an argument for re-validating the
right to sign as close as possible to the time
at which the signature is created. An
example where this might present a problem
would be a signature system that provided
non-repudiation. If a signature on a
particular document was generated at
roughly the same time that a revocation was
issued, then determining the true order of
events could be difficult.
Information Security Technical Report. Vol. 8, No. 3
Where: Because of the nature of a
traditional public key and its associated
certificate, the verification could be
conducted at a logically or physically
remote site to the signature. This is
considered to be one of the great strengths
of public key cryptography.
ID-PKC
Who: In a similar manner to PKI, anyone
with access to the public key corresponding
to the private key can verify the signature. As
mentioned previously, this does not
necessarily imply that they can accurately
verify the right associated with that
signature. This will depend on the security
policy of the system and the parties involved.
If the right is implicit, then it is the security
policy of the relying party that governs the
right. If the right is explicit, then the relying
party needs to be able to process the
associated authorisation structure.
When: The timing of the verification is
likely to be similar to a PKI. The
verification of the right to sign will happen
when the signature is checked by the relying
party.
Where: Once again, there is the potential
for the signature to be verified somewhere
that is logically and physically remote from
the signing party.
Encryption
Again, we analyse potential PKI and ID-
PKC systems separately.
PKI
Who: Who verifies the right to decrypt
will depend on how the system is built. If
the PKI is set up with an encryption key in
the certificate, then it is likely to be the
client encrypting the data. If the PKI is only
used as an authentication front-end to a
separate authorisation mechanism, then it is
likely to be the policy monitor for the
authorisation mechanism.
67
ISTR 0803.qxd 13/11/2003 15:41 Page 68
PKI re-visited – current issues and future trends
When: If the verification is carried out by
the client encrypting the message, then right
is likely to be verified when the encrypted
message is being generated. This might
happen at a time that could realistically be
far ahead of when the recipient decrypts the
message. There is a danger here that the
original right may have expired or have been
revoked in the meantime. If there is a
monitor controlling access to the data, then
the right should be checked as the data is
being released to the recipient.
Where: If the right is being checked —
implicitly or explicitly — by the encrypting
party, then this happens in a place that is
potentially logically remote from the
recipient. In the case of an access monitor,
then the location is likely to be carefully
chosen to be within the same logical or
physical security domain as the recipient.
ID-PKC
Who: In a similar manner to PKI, who
does the verification will depend on how
the system is implemented. If the
encryption key is generated from the user’s
long-term secret key, then it is likely to be
the client encrypting the message. If the
client is allowed to control the generation of
the public key according to their security
policy — as proposed by Chen et al [6] —
then the verification of the right to decrypt
is carried out by the TA that generates the
private key for the recipient.
When: If the client encrypting the
message uses a long-term key, then the right
to decrypt is verified at the point of
encryption. If the key is a sender-chosen key
generated specifically for that encryption,
then the rights verification should happen at
the point at which the TA hands out the
decryption key to the recipient.
Where: As in the case of the PKI, if the
encrypting party carries out the verification,
this could potentially be anywhere. If the
key is chosen by the sending client, then this
68 Information Security Technical Report. Vol. 8, No. 3
would happen at the TA, who is a trusted
server within the security domain.
We now discusses some of the main
issues raised by our analysis in this and the
previous sections.
• There is a relationship between the
management of rights and the revocation
issues as discussed in subsection 4.3. When
you use a right (e.g. to verify a signature,
encrypt a document to a colleague), then
you need to know at that point whether the
right has been revoked or not. It is this
verification of the right to carry out a task
that poses one of the problems in
implementing a PKI. With ID-PKC, the act
of rights verification can be bound closely
(both in terms of time and space) to point
at which the verification is carried out. This
is carried out through the use of client-
chosen short-term keys with the recipient
having to retrieve the associated private keys
from the TA. While discussing the future of
PKI, Gutmann [9] recommends a similar
binding when implementing a PKI. At first
glance, it would appear that such strong
binding between verification and CA/TA, if
required, can be carried out more cleanly in
an ID-PKC implementation.
• There are scenarios where the right to
decrypt, in a PKI system, is only generated
and assessed immediately prior to
decryption, rather than when encryption
takes place. This results in a mechanism
that is very similar to one that proponents
of ID-PKC claim to be a benefit of their
approach. An example of such a system
might be an encrypted file store on a server.
A client wishing to access the encrypted
material asks a monitor for read rights. The
right might then be generated on-the-fly as
part of the rights verification process.
These two points highlight the fact that
both PKI and ID-PKC systems ultimately
work in a similar manner. It would appear
that ID-PKC lends itself naturally to
ISTR 0803.qxd 13/11/2003 15:41 Page 69
Kenneth G. Paterson & Geraint Price A comparison between traditional PKIs and identity-based cryptography
situations where the TA should be given
governance over policy decisions. In a PKI,
the ability for any client to verify the
content of a certificate means that policies
set by the CA can potentially be
independently assessed by the client in
relation to client-oriented policy.
6 Beyond PKI and ID-PKC
The focus of this paper has been to make
a comparison between ID-PKC and PKI.
Here we cast a look at some recent
developments in research in the area of
models for infrastructures supporting the
use of public key cryptography [10,11].
6.1. Certificate-based encryption
In [10], Gentry introduced the concept of
certificate-based encryption (CBE), with a
view to simplifying revocation in traditional
PKIs.
In Gentry’s model, an entity B’s private
key consists of two components: a
component which that entity chooses for
itself and keeps private; and a component
which is time-dependent and issued to B on
a regular basis by a CA. This second
component can be transmitted over a public
channel from the CA to B.
Matching the two private key
components are two public key
components. The first of these matches B’s
own private component and is assumed to
be readily available to any entity A that
wishes to encrypt a message to B. The
second public component can be computed
by A using only some public parameters of
the scheme’s CA, together with the current
time value and the assumed value of A’s
public key.
In encrypting a message to B, A makes
use of both public components. Because of
the structure of the CBE scheme, A is then
assured that B can only decrypt messages
Information Security Technical Report. Vol. 8, No. 3
encrypted by A if B is in possession of both
private components. Thus, the second
private component acts as an implicit
certificate for relying parties: one that a
relying party can be assured is only
available to B provided that B’s certification
has been issued for the current time period
by the CA. The security of CBE depends
critically on the CA binding the correct
public key into B’s implicit certificate in
each time period. Thus (quite naturally) the
initial registration of users and their public
keys must take place over an authentic
channel and be boot-strapped from some
other basis for trust between B and the CA.
This approach can significantly simplify
revocation in PKIs: notice that there is no
need for A to make any status checks on B’s
public key before encrypting a message for
B. So, there are no CRLs and no
requirement for OCSP. Nor are any
certificates actually needed by A; rather A
needs to be in possession of what it assumes
is a copy of B’s public key and an authentic
version of the CA’s public parameters.
(Rather, an implicit certificate is needed by
B in order to decrypt — for this reason,
perhaps certificate-based decryption would
be a better name for the CBE concept.)
However, the basic CBE approach of [10]
does have a major drawback: the CA needs
to issue new implicit certificates to every
user in the scheme in every time period. A
granularity of one hour per time period is
suggested in [10]; this substantially adds to
the computation and communication that
takes place at the CA for a PKI with even a
small user base. The basic CBE approach
can be regarded as effectively trading
simplified revocation for an increased
workload at the CA. It can even be argued
that CBE loses the one key feature enjoyed
by a traditional PKI: that the certificates
issued by the CA allow the CA to distribute
trust in an almost off-line manner (the CA
69
ISTR 0803.qxd 13/11/2003 15:41 Page 70
PKI re-visited – current issues and future trends
needs only to be on-line to perform a
revocation function). A number of
enhancements to the basic CBE approach
are also presented in [10]. These reduce, but
do not completely eliminate, the work that
must be carried out by the CA.
The specific instantiation of CBE given
in [10] builds on ideas developed in Boneh
and Franklin’s identity-based public key
encryption scheme [4]. The details of
Gentry’s specific CBE scheme are beyond
the scope of this paper.
6.2. Certificateless public key
cryptography
Independently of Gentry’s work, Al-
Riyami and Paterson [11] proposed
another new model for supporting the use
of public key cryptography. The key
feature of their model is that it completely
eliminates the need for certificates, hence
the moniker certificateless public key
cryptography (CL-PKC). The technical
means by which it does so is actually
rather closely related to that used in [10]:
a user A’s private key is composed in two
stages. In the first stage, an identity-
dependent partial private key is received
over a confidential and authentic channel
from a trusted authority (called a key
generation centre, KGC). In the second
stage, the user produces his private key by
combining the partial private key with
some secret known only to the user.
The user also publishes a public key
that matches the private key. However,
this public key does not need to be
supported by a certificate. Instead, an
entity A that wishes to rely on B’s public
key is assured that, if the KGC has done
its job properly, then only B, who is in
possession of the correct partial private
key and user-generated secret, could
perform the decryption, generate the
signature etc.
70 Information Security Technical Report. Vol. 8, No. 3
In fact, CL-PKC allows A to use B’s
public key but to choose an identifier for B.
In order to decrypt A’s message, B must
then fetch the correct partial private key
from the KGC. Thus CL-PKC supports the
temporal re-ordering of public and private
key generation in the same way that ID-
PKC does.
CL-PKC combines elements from ID-
PKC and traditional PKI. The schemes are
no longer identity-based: they involve the
use of B’s public key, which is no longer
simply derived from B’s identity. However,
as we have already discussed, when using
ID-PKC in practice, it is rare that the public
keys will depend on identities alone. On the
other hand, CL-PKC avoids the key escrow
inherent in ID-PKC by having user-specific
private information involved in the key
generation process. Also, CL-PKC does not
need certificates to generate trust in public
keys; instead, this trust is produced in an
implicit way. This would appear to make
CL-PKC ideal for systems where escrow is
unacceptable, but where the full weight of
PKI is untenable. For example, it might be
well suited to a mobile e-commerce
application where signatures are needed to
ensure non-repudiation of payments.
Perhaps not surprisingly, it is possible to
convert a CL-PKC encryption (CL-PKE)
scheme into a CBE scheme à la Gentry: if
B’s identity in the CL-PKE scheme is
extended to include a time period along
with the public key, then the CL-PKE
scheme effectively becomes a CBE scheme.
On the other hand, if one omits certain
fields from the certificates in a CBE
scheme, one obtains an encryption scheme
that is functionally similar to a CL-PKE
scheme. Differences do remain: in the
strength and scope of the security models
developed in [10] and [11], as well as in
the technical details of the schemes’
realisations.
ISTR 0803.qxd 13/11/2003 15:41 Page 71
Kenneth G. Paterson & Geraint Price A comparison between traditional PKIs and identity-based cryptography
In closing this brief introduction to
recent work, it is worth re-iterating that
CBE, as presented in [10], is formulated
within the confines of a PKI setting and is
aimed at simplifying revocation, while CL-
PKC attempts to break free from the
‘mental straightjacket’ that is imposed by
ID-PKC and PKI. Time will tell as to what
extent these relatively new research ideas see
further development and eventual
deployment in applications.
7 Discussion and conclusions
We draw this paper to a close with an
overview and summary of what we consider
are the key points that we have raised
through our analysis, followed by some
conclusions.
7.1. Key points
Although we have discussed various
issues as they have arisen during each
section, the following list represents a
summary of what we consider to be the
most salient points that we have raised in
this paper:
• The strong binding between an identity
and a key in an ID-PKC could potentially
provide a benefit in systems where there is a
strong binding between the user and the
identifier of the communication end-point.
An example of this might be mobile
networks, where the encryption channel
might be set up through knowledge of the
recipient’s physical address.
• With ID-PKC, the verification of the
rights used in the system can be more
readily bound to the private key generation
process at the TA. However, as is often true
in security, the differences in what can be
achieved are not always restricted by the
‘how’ of the underlying mechanism. It is
possible to emulate much of what ID-PKC
has to offer within a PKI implementation by
having the client that generates the
Information Security Technical Report. Vol. 8, No. 3
encryption send an accompanying policy
statement to a monitor (Subsection 5.2).
• The message flow and interaction
between clients can become an issue. On the
face of it, a two-pass protocol is not much
worse than a one-pass protocol, but if the
link over which the messages flow can easily
become congested then the saving could be
important. If an ID-PKC implementation
could guarantee that a client generating a
public key generated it correctly, then it
could deliver the saving of not having to
perform a certificate look-up.
• How the policies of the communicating
parties interact is an important
consideration when choosing whether to
achieve security using a PKI or an ID-PKC
system. As we mentioned in Subsection 5.2,
it would appear that ID-PKC could provide
a more natural implementation in a
situation where a centralised security policy
should be checked regularly. By contrast, the
very nature of a certificate makes a PKI
more useful in a situation where the policy
should be controlled locally at the client
using a certificate.
• The liveness of the trusted authority
(CA or TA) is a potential issue. As
mentioned in our discussion on revocation
(Subsection 4.3), one of the ways in which
revocation might be handled in ID-PKC
would require the TA to be on-line
potentially more often than a CA in a PKI.
• The explicit dependence of the public
key on the identity/identifier in ID-PKC
could potentially become a hindrance in
applications that might require flexibility in
their certificate structure without having to
go through the associated distribution of
new keying material.
7.2. Conclusions
Although research interest in ID-PKC is
very strong at the moment, it is a relatively
new technology in comparison to PKI. In
our article, we have sought to explore what
71
ISTR 0803.qxd 13/11/2003 15:41 Page 72
PKI re-visited – current issues and future trends
separates ID-PKC from PKI. Our initial
judgement, admittedly made in the context
of little or no commercial deployment of
ID-PKC systems, is that there is very little to
separate the two. Perhaps the important
input when deciding whether to adopt PKI
or ID-PKC is the different way in which the
two technologies naturally generate and
verify rights and keys.
As with symmetric and asymmetric
cryptography, the deciding factors when
choosing between PKI and ID-PKC are
likely to be environmental. This influence of
the constraints surrounding the
implementations are likely to be greater,
given that there doesn’t seem to be such a
strong separating factor such as the ability
to provide non-repudiation is between
symmetric and asymmetric cryptography.
References
[1] W Diffie and M Hellman, 1976. New directions in
cryptography, IEEE Transactions on Information Theory,
IT-22(6):644-654.
[2] R L Rivest, A Shamir and L Adleman, February 1978.
A method for obtaining digital signatures and public-key
cryptosystems, Communications of the A.C.M.,
21(2):120-126.
[3] A Shamir, 1984. Identity-based cryptosystems and
signature schemes. Advances in Cryptology – CRYPTO
’84, volume 196 of LNCS, pages 47-53. Springer-Verlag.
72 Information Security Technical Report. Vol. 8, No. 3
[4] D Boneh and M Franklin, 2001. Identity-based
encryption from the Weil pairing, Advances in
Cryptology – CRYPTO 2001 (ed J Kilian), volume 2139
of LNCS, pages 213-229. Springer-Verlag.
[5] C Gentry and A Silverberg, 2002. Hierarchical ID-
based cryptography, Advances in Cryptology –
ASIACRYPT 2002 (ed Y Zheng), volume 2501 of LNCS,
pages 548-566. Springer-Verlag.
[6] L Chen, K Harrison, D Soldera and N P Smart, 2002.
Applications of multiple trust authorities in pairing based
cryptosystems, Infrastructure Security, International
Conference, InfraSec, (ed G I Davida, Y Frankel and O
Rees), volume 2437 of LNCS, pages 260-275. Springer-
Verlag.
[7] EU Directive 1999/93/EC of the European Parliament
and of the Council on a Community framework for
electronic signatures, December 1999:
http://europa.eu.int/eur-lex/pri/en/oj/dat/2000/l_013/
l_01320000119en00%120020.pdf
[8] C Ellison, September 1999. SPKI requirements, IETF
RFC 2692: http://www.ietf.org/rfc/rfc2692.txt
[9] P Gutmann, 2002. PKI: It’s not dead, just resting. IEEE
Computer 35(8):41-49.
[10] C Gentry, 2003. Certificate-based
encryption and the certificate revocation problem,
Advances in Cryptology – EUROCRYPT 2003 (ed E
Biham), volume 2656 of LNCS, pages 272-293.
Springer-Verlag.
[11] S S Al-Riyami and K G Paterson, 2003.
Certificateless public key cryptography, Proceedings of
Asiacrypt 2003, Lecture Notes in Computer Science (to
appear).