A comparison between traditional Public Key Infrastructures and Identity-Based Cryptography

disturbeddeterminedΤεχνίτη Νοημοσύνη και Ρομποτική

21 Νοε 2013 (πριν από 3 χρόνια και 11 μήνες)

119 εμφανίσεις

A comparison between traditional

Public Key Infrastructures

and Identity
-
Based Cryptography




Kenneth G. Paterson
1

Geraint Price



Information Security Group, Mathematics Department,

Royal Holloway, University of London,

Egham, Surrey, TW20 0EX.


{kenny
.paterson,geraint.price}@rhul.ac.uk



Abstract


With the recent acceleration in research into Identity
-
based Public Key Cryptography
(ID
-
PKC), we consider this an opportune moment to
compare and contrast ID
-
PKC with
more traditional Public Key Infrastructure
s (PKI). Because of the similari
ty in the nature
of both approaches
, we aim to identify the distinguish features of each. In doing so, we
highlight the important questions to be asked when weighing up the benefits and
drawbacks of each.


Keywords
: Public Key
Infrastructure, Identity
-
Based Cryptography, Asymmetric
Cryptography, Digital Signatures, Certificates, Non
-
Repudiation.


1 Introduction


W
ith 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 certifica
tes. Our work is
focused on
architectural, key m
anagement and associated issues;

we do not consider
implementation details in any gr
eat depth. The main goal of this article is to ask the
question
“What are the d
ifferences between these systems

from a practical viewpoint?”
.

The main
technical
diffe
rence 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 mechanism, the binding
between the private key and the authenticity data is managed by a Trusted Authority (TA)
at the point of request, while t
he 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, we wish to tackle the notion prevalent in many
existing

discussions about the extent to which ID
-
PKC avoids trust problems encountered



1

Support
ed by the Nuffield Foundation NUF
-
NAL02

in certificate based PKIs. While ID
-
PKC certainly does provide a new technological
means of managing trust, it does not avoid the problems inherent in this difficult task.

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 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 manage
d under these mechanisms and is

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
cert
ain 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 both traditional PKIs and ID
-
PKC.

Both technologies are variants

of asymmetric cryptography, a concept introduced
by Diffie and Hellman [1] in the mid
-
70s. Until their groundbreaking paper, all crypto
-
systems had relied upon symmetric cryptography where both communicating parties
shared a copy of the same key. In the m
odel of [1] a related pair of keys are generated.
The user retains the 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
encrypted under the cor
responding public 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 unrelat
ed to the method identifyi
ng that

key pair within the system.
As such there is a requirement for a certificate to bind the public key to its par
ticular 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 whic
h it is to be
used.

We expand our review of PKI and ID
-
PKC in Sections 2.1 and 2.2 respectively.
We conclude our technological overview in
Section 2.3 with a discussion of

how the
security policies that make use of these keys can reflect the underlying tec
hnology.


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 tradi
tional 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 responsible for ensuring 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
that receives the certificate is a legitimate user within the system. The
functionality of the CA and RA is somet
imes 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 t
hat is going to use the
certificates need 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 req
uirement 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 broade
r 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 cer
tify. 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.


2.2 Identity/Ide
ntifier
-
Based Public Key Cryptography


One of the difficulties inherent in running a PKI is in the managing of the certificate and
associated key. Identity


and subsequently identifier


based cryptography was created
as a means of overcoming 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 encryptio
n. 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 in the
means of generating the keys. The difference is identifiab
le 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), who is the analogue of the CA in a

PKI.


Recently, it has been recognised that an identity need not be the only determinant of a
client's public key. For example, information such as the client's position within an
organisation, the validity period for the keys, etc. can be included in the

data used to
derive the key pair. This results in the broader concept of identifier
-
based public key
cryptography.

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 present
in the certificate, whereas, in an ID
-
PK
C the TA is directly responsible for generating and
distributing all keying material within the system.

There is also the requirement that TA and client are able to set up an independent
secure channel for the distribution of private key material. This cha
nnel 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
i
nfluence 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 ad
ditional input to the key generation process. If we include validity
dates, key usage, etc. then a push toward broader use of identifying information
results, leading naturally to identifier
-
based cryptography. We will return to
revocation issues in Sectio
n 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 priva
te
key may be generated after the public key, the TA may not have validated the
authenticity of the information relating to 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 may 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 gen
erally 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 are 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 on which mechanism to use.

Expanding on the example given above, it would seem more natural to implement
an ID
-
PKC for short t
erm keys where the policy at the TA might change regularly.
Conversely, it would seem sensible to use a PKI in a widely distributed environment, or
in one where the individual policy of each client took a significant role in the policy of
the system as a w
hole.


3 Architectural Issues


ID
-
PKC was introduced as a means of circumventing the difficulties associated with
certificate management within PKIs. This has lead 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 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 requirement
for storing separate certification, identification and keying information. Provided the
authenticity of such information could be verified, thi
s 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 generating keying information on the fly.



It would appear that a PKI would be the implementation of choice in

a widely
distributed system. The ability for clients to generate their own key pairs to be
certified by a CA which need not directly be 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 wishing to secure
it
s Internet gateway using an SSL
-
enabled server.



Within systems where the security is h
eavily centralised (i.e. where all users have to
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
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's difficult to manage a revocation mechanism (e.g.
mobile systems), one way 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 partia
l 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
which reflect the internal structure of a large organisation or group of organisations.
Whil
e this might seem 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 a PKI seems to have a distinct advantage over ID
-
PKC is in the
consequenc
es 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 compr
omised 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 si
gnature on a document that had not been independently
timestamped could be called into question.


4 Key Management


In this section, we analyse the differences between PKI and ID
-
PKC by examining the
way in which they manage keys. We separate our discuss
ion 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 k
eys
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 we ask with regards 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 eithe
r 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 chose
n by any client in the system. I
t is then incumbent upon 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. W
ithin 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
of the client who wishes to use the public key.



Within a PKI, the public key usually result
s 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 t
he client
to encode a policy specifying conditions under which decryption can take place. The
client wishing 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 generating the ciphertext can generate the
encryption key pair without having to know the identity of the clie
nt who will decrypt the
message. This has the potential benefit of having the policy compliance encoded directly
into the encryption key. For PKI, the client would need to know the public key that was
related to the private key to be used to decrypt the me
ssage in advance


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 d
ecryption policy

to the ciphertext
.


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 calculate
s 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 containing the verification key often accompanies the signature.
Within a signature scheme a public key is only of any use w
hen 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
Section 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 its usage.

The main difference between the two approaches, in terms of generation of

the
private k
ey, is that with

ID
-
PKC, the key has to be gener
ated 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 manag
ement of private keys. This
might be of benefit to an encryption scheme in a business environment where the
company owns the data, but is drawback in an implementation for digital signatures
which might want to offer non
-
repudiation. Boneh and Franklin [4]

propose 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 th
e 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
used as an Advanced Electronic Signature should be und
er the sole control of the
individual who is 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 discussi
on in Section 6

outlines rece
nt research that
could potentially be used to overcome the drawback
s 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 signature
s.


Decryption

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 short term
publ
ic key. This is a policy decision influenced by the system security policy in
conjunction with the policy of the client carrying out the encryption. For PKI the public
encryption key used is usually the client's long term key bound to their certificate,
al
though a short term key could 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 creation

For ID
-
PKC the private key is generated by the TA and given
to the client. Because signature schemes should uniquely identify the creator of the
signature, the inherent key escrow in ID
-
PKC ma
kes it a less attractive choice. For PKI,
the key is either generated by the CA or the client. This ability to chose 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 sepa
ration between the public and private key
generation


does not immediately appear to be of use here, as we discussed in Section
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
generate
d, 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, maybe
with a legitimate reason


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 ID and public key, the
keys will ac
tually 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 i
f 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 organisation etc. The more worried one is about duplication within
the system, the more the c
ontent of the
identity

starts to mirror the content of the
certificate in a PKI.

Where does this leave us?

The client now
has to 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 re
cipient?

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 pa
rties and the
TA
.

Thus
,
we n
ote 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 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 b
e resolved when
considered in 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 which chooses the identity which is used to
generate the public
key, they could chose an identity for which the TA will not
release the corresponding private key. This could leave the intended recipient unable
to rea
d vital information, or result in

the need for manual intervention and override.
Such intervention may no
t 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 implementors 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 large a concern for ID
-
PKC as it
currently is for PKI.

Here are the three main issu
es 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
which could
be inconvenient
to change (s
uch as an
e
-
mail address
). But these are
precisely the identifiers that are easily predicted by the entity 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
i
n actual implement
ations

it is likely that
more complex
identifiers, which are built on top of a client's identi
ty, will provide the input to the
key generation function. This means that there is likely to be a higher degree of
complexity in the part of the system which managers those identifiers than might

at
first sight
appear
.

This is related to the issue about form and content of identifiers
no
ted in Section 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 rec
ent PKI workshop, we saw a
demonstration for a product which 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 c
ertificate content through re
-
certification without needing to go through the more expensive procedure of issuing
the clients with a new privat
e key. An exact replica
woul
d be impossible to achieve in
an

ID
-
PKC system.



When considering the issue of revoca
tion, 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
-
issuan
ce of keys on a per time basis obviates the
need for a revocation mecha
nism. T
his 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 roo
t CA.
Another problem with Boneh and
Franklin's mode
l 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 mos
t heavily guarded. Applying this same level of security daily in an
ID
-
PKC could make the process i
nherently difficult to manage.


To put it more succinctly, revocation in a PKI requires reliable and timely distribution
of authenticated information. Revoca
tion in an ID
-
PKC, using the methods discussed
here, requires the reliable and timely distribution of confidential information.


5 Rights Management


In th
is 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 e
xtension of
the services which 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 section we introduce the basic means
by which rights are represented in each
mechanism and how these representations are genera
ted. We split our discussion in
to two
parts, one concerning rights implemented using signatures and the
other,
rights
implemented using encryption.


Signing


PKI

In PKI, th
e 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 mecha
nism could be a more traditional Access Control List, a separate
Privilege Management Infrastructure (PMI), or be contained in the client's identity
certificate. The right to sign for a particular purpose is assessed either by the CA when
generating the id
entity 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 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 creation
of the signature key or when the identity is bound to the associated authentication
mechanism.


Encryption


PKI

Traditionally PKIs have been primarily associated with authentication rather
than authorisation (SPKI [8] being the notabl
e exception). In most commercial PKI
systems, the identity certificate is used to authenticate the client to a separate
authorisation infrastructure. As in the discussion on signatures above, the right to decrypt
can either be implicit or explicit. For exa
mple, Alice may know Bob personally and thus
be willing to use the encryption key in Bob's certificate


this may be the case in when
using e
-
mail security software. Alternatively, Alice might want to see Bob's credential as
a line
-
manager before passing o
n 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 encrypting the data in
advance of the corresponding private key having been generated. If used in this manner,
the ri
ght to decrypt is effectively generated when the client 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
t
he 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 thi
s, we keep our discussion at a generic level and
develop our argument by 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

verification which might affect the security policy?


We note that in an attempt to keep our analysis as broad as possible, we describe
the most logical mea
ns of implementing the rights verification functions.


Signature Verification


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 veri
fy 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 s
ign was implicit in the sense that
A

knows
B
, or explicitly
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 fro
m 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, o
n the other hand, the
signing party's right to sign may be brought into question in the future, 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 as a revocation was issued, determining the true
order of events could be difficult.

Where

Because of the n
ature 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 one of the great strengths of public key cryptography.


ID
-
PKC


Who

In a sim
ilar manner to PKI, anyone with access to the public key
corresponding to the private key can verify the signature. As mentioned previously, that
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
as
sociated 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 s
ignature to be verified
somewhere that is logically and physically remote from the signing party.


Decryption


Again, we analyse potential PKI and ID
-
PKC systems separately.


PKI


Who

Who verifies the right will depend on how the system is built. If the PK
I 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.

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 w
hen the recipient decrypts the
message. There is a danger here that the original right might 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 rele
ased 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 li
kely 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 enc
ryption. 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, t
his could potentially be anywhere. If the key is chosen by the sending client,
then this 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
s
ection.




There is a relationship between the management of rights and the revocation issues as
discussed in Section 4.3. When you use a right (e.g. to verify a signature, encrypt a
document to a colleague), you need to know at that point whether the right
has been
revoked or not. It is this verification is 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 cli
ent 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
im
plementing a PKI. At first glance, it would appear that such strong binding
between verific
ation 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 genera
ted and
assessed immediately prior to decryption, rather than when encryption takes place.
This results in a mechanism which is very similar to one that proponents of ID
-
PKC
claim as a benefit of their approach. An example of such a system might be an
encr
ypted 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 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 ca
st a glance towards 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 simplify
ing 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 is issued to
B

on a regular basis b
y 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 a
ny entity
A

who 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
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 pub
lic 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 bootstrapped from some other basis for trust between
B

and the
CA.

T
his 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
actuall
y 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
Certific
ate
-
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 hou
r 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 a
n 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 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] build
s 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 P
ublic Key Cryptography


Independently of Gentry's work, Al
-
Riyami and Paterson [11] proposed another
new m
odel for supporting the use of public key cryptography. The key feature of the
model of [11] is that it completely eliminates the need for certificates, hence the moniker
certificateless public key cryptography

(CL
-
PKC). The technical means by which it doe
s
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 (ca
lled 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 which matches the private key. However,
this publi
c key need not be supported by a certificate. Instead, an entity
A

who 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 coul
d
perform the decryption, generate the signature, etc.

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 t
he temporal re
-
ordering of public and private key
generation in the same way as 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 simpl
y
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 p
rivate
information involved in the key generation process. And 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
unaccep
table, 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 en
cryption (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 fi
elds 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 de
tails of the
schemes' realizations.

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 t
o break free from the “mental
straightjacket” imposed by ID
-
PKC and PKI. Time will tell to what extent these
relatively new research ideas see further development and eventual deployment in
applications.


7 Discussion & Conclusions


We draw this paper to

a close with an overview and summary of what we consider the
key points 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
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 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 you can achieve 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
encryption send an accompanying policy statement to a monitor (Section 5.2).



The message flow and interaction between clients can become an issue. On the face
of i
t, 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, the saving could be
important. If an ID
-
PKC implementation could guarantee that a client generating a
public key ge
nerated 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 s
ystem. As we
mentioned in Section 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 us
eful in a
situation where the policy should be controlled locally at the client using a certificate.



Liveness of the trusted authority (CA or TA) is a potential issue. As mentioned in our
discussion on revocation (Section 4.3), one of the ways in which rev
ocation 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
separates ID
-
PKC fr
om 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. Per
haps 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

asy
mmetric 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 fact
or as the ability to provide

non
-
repudiation is between symmetric and asymmetric cryptography.


References


[1] W. Diffie and M. Hellman. New directions in cryptography.
IEEE Transactions on
Information Theory
, IT
-
22(6):644
-
654, 1976.


[2] R.L. Rivest, A. Shamir, and L. Adl
eman. A method for obtaining dig
ital signatures
and public
-
key cryptosystems.
Communications of the A.C.M.
, 21(2):120
-
126, February
1978.


[3] A. Shamir. Identity
-
based cryptosystems and signature schemes. In
Advances in
Cryptology


CRYPTO ’84
, volume 196

of
LNCS
, pages 47
-
53. Springer
-
Verlag, 1984.


[4] D. Boneh and M. Franklin. Identity
-
based encryption from the Weil pairing. In J.
Kilian, editor,
Advances in Cryptology


CRYPTO 2001
, volume 2139 of
LNCS
, pages
213
-
229. Springer
-
Verlag, 2001.


[5] C. Gen
try and A. Silverberg. Hierarchical ID
-
based cryptography. In Y. Zheng,
editor,
Advances in Cryptology


ASIACRYPT 2002
, volume 2501 of
LNCS
, pages 548
-
566. Springer
-
Verlag, 2002.


[6] L. Chen, K. Harrison, D. Soldera, and N.P. Smart. Applications of multi
ple trust
authorities in pairing based cryptosystems. In G.I. Davida, Y. Frankel, and O. Rees,
editors,
Infrastructure Security, International Conference, InfraSec
, volume 2437 of
LNCS
, pages 260
-
275. Springer
-
Verlag, 2002.


[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. E
l
lison. SPKI requirements. IETF RFC 2692, September 1
999.
http://www.ietf.org/rfc/rfc2692.txt
.


[9] P. Gutmann. PKI: It’s not dead, just resting.
IEEE Computer
, 35(8):41
-
49, 2002.


[10] C. Gentry. Certificate
-
based encryption and the certificate revocation problem. In E.
Biham, editor,
Advances in Cryptology



EUROCRYPT 2003
, volume 2656 of
LNCS
,
pages 272
-
293. Springer
-
Verlag, 2003.


[11] S.S. Al
-
Riyami and K.G. Paterson. Certificateless public key cryptography. In
Proceedings of Asiacrypt 2003
, Lecture Notes in Computer Science, 2003. to appear.