Beruflich Dokumente
Kultur Dokumente
www.elsevier.com/locate/comcom
Tutorial
Abstract
Secure E-Commerce and VPN technology is only possible with the use of appropriate security systems such as encryption, digital
signatures, digital certi®cates, public/private key pairs, non-repudiation, and time-stamping. A PKI comprises a system of certi®cates,
certi®cate authorities, subjects, relying partners, registration authorities, and key repositories that provide for safe and reliable E-business.
This paper discusses these key technologies focusing particularly on recent standardisation as well as looking at some of the criticism and
challenges to its widespread operation in the industry. q 2001 Elsevier Science B.V. All rights reserved.
Keywords: Symmetric and asymmetric encryption; VPN; Dif®e±Hellman key exchange; Digital signature; X.509; IPSec; CA; RA; TTP; CRL; PKI; SPKI;
PKIX; Digital certi®cate; Key management
the decryption key and vice versa. This lets a user, Alice Development of the operational protocols has been more
publish her encryption key so that anyone can use her public straightforward. Two documents for LDAP (Lightweight
key to encrypt a message that only Alice can decipher with her Directory Access Protocol) have been developed Ð one
private key. Theoretically, no con®dential information needs for de®ning LDAPv3 as an access protocol to repositories
to be exchanged between participants before secure commu- [17,20] and one for storing PKI information in an LDAP
nication is possible. The problem is that everyone has access to directory [32]. Using FTP and HTTP to retrieve certi®cates
Alice's public key and that even though the communication and CRLs from PKI repositories is speci®ed in Ref. [31].
between Alice and another user, Bob is private, the message
cannot be authenticated. This shows that public key crypto-
3. Public key infrastructure
graphy on its own, is not enough. If the conditions for
traditional paper based commerce are to be reproduced in
In its simplest form, a PKI is a system for publishing the
the electronic environment, the following are required:
public keys used in public key cryptography. PKI provides
² Security policies to de®ne the rules under which crypto-
the core framework for a wide variety of components, appli-
graphic systems should operate.
cations, policies and practices to combine and achieve the
² Products to generate, store and manage certi®cates and their
three principal security functions (integrity, authentication
associated keys.
and non-repudiation). A PKI is a combination of hardware
² Procedures to dictate how the keys and certi®cates should
and software products, policies and procedures. It provides
be generated, distributed and used.
the basic security required to carry out E-business so that
users who do not know each other or are widely distributed,
In other words, a trusted and authenticated key distribution
can communicate securely through a chain of trust. Digital
infrastructure is necessary to support the use of public keys on
certi®cates are a vital component in the PKI infrastructure as
a public network such as the Internet. Recent efforts in stan-
they act as `digital passports' by binding the user's digital
dardisation have seen developments on a number of fronts.
signature to their public key. 2
The ITU-T Recommendation X.509 provides a very useful A PKI consists of:
basis for de®ning data formats and procedures related to the
distribution of public keys via certi®cates that are digitally ² A Security Policy.
signed by CAs. X.509 does not however include a pro®le to ² Certi®cate Authority (CA).
specify the supporting requirements for many of the certi®cate ² Registration Authority (RA).
data structure's sub-®elds, extensions or for some data values. ² Certi®cate Repository and Distribution System.
The standards effort produced an outline for PKI of X.509 ² PKI-enabled Applications.
Version 3 certi®cates as well as Version 2 Certi®cate Revo-
cation Lists (see Section 3.2.3). The Internet PKI pro®le 3.1.1. Security policy
went through eleven draft versions before becoming ªInter- A security policy sets out and de®nes an organisation's
net X.509 Public Key Infrastructure Certi®cate and CRL top level direction on information security as well as the
Pro®leº [23]. Other pro®les have been developed for parti- processes and principles for the use of cryptography. Typi-
cular algorithms to make use of Ref. [23]. cally it will include statements on how the organisation will
The development of the PKI management protocols has handle keys and valuable information and will set the level
gone though a number of iterations. PKI [24] was developed of control required to match the levels of risk.
to specify a message protocol to be used between entities in Some PKI systems are operated by Commercial Certi®-
a PKI. The need for an enrolment protocol and the prefer- cate Authorities (CCAs) or Trusted Third Parties (TTPs)
ence to use PKCS [16] message format as the certi®cate and therefore require a Certi®cate Practice Statement
request syntax lead to two parallel developments. 1 (CPS) [1]. This is a detailed document containing the opera-
1
tional procedures on how the security policy will be
The Certi®cate Request Syntax was developed in the S/MiMe WG
enforced and supported in practice. It typically includes
which used PKCS #10 [16] as the certi®cation request message formate.
Certi®cate Request Message Format [25] draft was also developed but in vital speci®cations on how the CAs are constructed and
the PKIX WG. It was to de®ne a simple enrolment protocol that would work
2
for the PKI [24] enrolment protocols, but it did not use PKCS#10 [16] as the Only the user holds their private key. The user's computer generates the
certi®cate request message format. Then, the Certi®cate Management public and private key pair. The public key is then send to the CA where it is
Protocols [24] and Messages [4] were developed to de®ne an extended veri®ed and a digital certi®cate is issued. This certi®cate is then sent back to
set of management messages that ¯ow between the components of the the user and stored. Copies of this certi®cate can then accompany transac-
Internet PKI. These, combined with CMS [4] allowed the use of an existing tions from which the (certi®ed) public key is available. The fact that a
protocol (S/MIME) as a PKI management protocol, without requiring the cryptographically strong private key may be kept on a computer protected
development of an entirely new protocol such as CMP [24]. It also included by a cryptographically weak password is a security issue that needs careful
in PKCS#10 [16]as the certi®cate request syntax. consideration.
1462 R. Hunt / Computer Communications 24 (2001) 1460±1471
operated, how certi®cates are issued, accepted and revoked, There is also a hybrid-outsourcing model where an orga-
how keys will be generated, registered and certi®ed, where nisation outsourcers its private CA operations to a public
they will be stored and how they will be made available to CA in a similar manner to which PBXs are hosted at telco
users. The Electronic Commerce Promotion Council of premises (Centrex). An example of this infrastructure is the
Japan (ECOM) came out with some guidelines, which Equifax system [37].
form the basis for the general management requirements
for the operation of a CA, the requirements for speci®c 3.1.3. Registration authority (RA)
services conducted by CAs as well as facility and system An RA provides the interface between the user and the
requirements [10]. For more speci®c information of what a CA. It authenticates the identity of the users and submits the
CPS should contain, VeriSign, a leading provider of Internet certi®cate request to the CA. The quality of this authentica-
trust services, have also publicised their CPS [39]. tion process determines the level of trust that can be placed
in the certi®cates. For example, if all an RA requires an
3.1.2. Certi®cation authority (CA) e-mail address and a name Ð before it issues a certi®cate
The CA is an entity which issues and revokes certi®cates. Ð the level of trust that should be placed in that certi®cate
An in-house server or a TTP such as Entrust, Baltimore or would be considerably lower than if more stringent registra-
VeriSign, can provide a CA function. A CA provides the tion procedures were required.
trust basis for a PKI as it manages public key certi®cates for Registration is distinct from the process of creating, sign-
their whole life cycle. ing and issuing certi®cates. For example a Human
The CA will: Resources Department may manage the RA function
while an Information Technology Department manages
² Issue certi®cates by binding the identity of a user or the CA. A separate RA also makes it harder for any single
system to a public key with a digital signature. department to subvert the security of the system. Organisa-
² Schedule expiry dates for certi®cates. tions can choose to have registration handled by a separate
² Ensure certi®cates are revoked when necessary by RA, or included as a function of the CA.
publishing CRLs.
3.1.4. Certi®cate repository and distribution system
When implementing a PKI, an organisation can either The Certi®cate Repository provides a mechanism for
operate its own CA or use the services of a Commercial storing keys, certi®cates and Certi®cate Revocation Lists
CA or TTP. (CRLs), which is usually based on an LDAP-enabled direc-
While the principles of PKI are the same there are tory service. Key recovery is an advanced function required
currently two major commercial implementation models to recover data or messages when a key is lost and a PKI
which depend upon who the CA is: may provide such an automated key recovery service.
Certi®cates can be distributed in a number of ways
1. Private CA Ð vendors sell a complete PKI system to an depending on the structure of the PKI environment. For
organisation which then becomes its own CA and is example, certi®cates may be distributed by the users them-
responsible for the issuing and management of certi®- selves or through an LDAP directory service.
cates. Examples include RSA's Keon, IBM's Trust
Authority, Baltimore's Unicert and Entrust's PKI. 3.1.5. PKI-enabled applications
2. Public CA Ð certi®cates are purchased from a public A PKI is a means to an end Ð providing the security
CA organisation as required. The most common example framework by which PKI-enabled applications can be con®-
of this approach is VeriSign. dently deployed to achieve the end bene®ts. Fig. 1 shows the
relationship between some applications and infrastructure,
The fundamental difference between these two models is and their related standards. Examples include:
that the later sells commercial digital certi®cates while the
former sells the software for the user to produce their own ² Document exchange between web servers and remote
certi®cates. On each of the respective web sites are a access clients.
number of white papers claiming the advantages of these ² E-mail and Groupware (PGP, S/MIME, Lotus Notes
models [13,38]. Groupware).
Generally for a large organisation it is more cost effective to ² Online banking, shopping and credit card transactions
operate a private CA as it offers more ¯exible control and once over the Internet.
the system is in place the economies of scale allow extra ² Virtual Private Networks (VPNs) operating with PPTP,
certi®cates to be produced and managed very cheaply. For a IPSec, etc.
small organisation it is likely to be advantageous to purchase
individual certi®cates as such organisations are unlikely to 3.2. Operations of PKI
have the infrastructure required to deploy such a large system
nor the volume necessary to produce cheap certi®cates. The main PKI functions are shown in Table 1. These
R. Hunt / Computer Communications 24 (2001) 1460±1471 1463
Di gi t al l y E- mai l Onl i ne
Si gned Banki ng
Gr oupw ar e VPN
Code and Onl i ne
Fi l es Shoppi ng
St andar ds
S/ MI ME SSLv3 .0 I PSec
t hat r el y
TLSv1 .0 PPTP on a PKI
SET
St andar ds
X.5 09 PKI X PKCS t hat def i ne
t he PKI
include Ð registration, issuing and revoking certi®cates, ®cate. If a user, Alice wishes to communicate with
creating and publishing CRLs, storing and retrieving certi- another user, Bob using a public key cryptosystem,
®cates and CRLs, as well as key lifecycle management. Alice must have direct knowledge of Bob's public key.
Some of the enhanced functions include time-stamping With a PKI, Alice only needs to have direct knowledge
and policy-based certi®cate validation. of the CA's public key and the CA would issue an
These functions can be described in terms of three basic identity certi®cate for Bob's public key. If Alice and
PKI infrastructures: the CA are distinct entities, how Alice trusts the CA
would depend on how much con®dence she has in
² Certi®cation is the process of binding a public key value using the CA's certi®cates for secure communications.
to an entity. A CA might have different classes of certi®cates with
² Validation is the process of verifying that a certi®cate is each class providing a designated level of trust.
valid and revoking where necessary. For example to overcome these inherent limitations
² Key management Ð updating, backing up, archiving etc. VeriSign has introduced four different levels of certi®cate
[40] (each with different cost structures) corresponding to
the degree of authentication required. See Table 2.
3.2.1. Certi®cation In addition to the content and authenticity of a transac-
Certi®cation is the fundamental function of all PKIs tion, the exact time of the transaction can be important. For
and it is the means by which the public keys and infor- example, a transaction may have to be submitted within a
mation pertaining to those keys are published. PKI speci®ed timeframe to be valid. The solution to having
communicates this information through a certi®cate. trusted transactions is to combine digital signatures with a
Fig. 2 shows the information contained in a basic certi- time-stamping service. (See Section 5.5)
Table 1
Public Key Infrastructure (PKI) Functions
proposed such as dividing the CRL into smaller sections (for tion and should not accept a message signed with an expired
example grouped by reason for revocation). At best this is key. This means that when one's own key expires, every-
only a temporary solution to the problem and research is still thing signed with it will no longer be considered valid.
being carried out. There may be cases in which it is important that a signed
The PKIX recommendation does not require CAs to issue document be considered valid for a much longer period of
CRLs [18]. On-line methods of revocation noti®cation may time and time stamping is therefore necessary.
be applicable in some situations as an alternative to CRLs. If a private key is lost or destroyed but not compromised,
PKIX de®nes an Online Certi®cate Status Protocol that messages can no longer be signed or decrypted Ð but
facilitates on-line checking of the status of certi®cates anything previously signed with the lost key is still valid.
[7,30]. The key must be placed on a CRL to prevent any illegiti-
mate use should the key be found or recovered by an
3.2.4. Key management attacker. Loss of a private key can happen, for example, if
The PKI performs functions, such as issuing a certi®cate the smart-card used to store keys is lost, or if the disk on
and listing a certi®cate on a CRL in response to a current which the key is stored is damaged.
request. In contrast, key lifecycle functions, such as updat-
ing, backing up, and archiving keys, are performed
routinely. Each user is likely to have a number of keys 4. Use of PKI with PGP
that require lifecycle management. For example, users
typically have at least one key pair for each secure There are a number of important protocols, which will
application (e.g. e-mail, desktop ®le encryption, VPN). bene®t from the use of PKI Ð these include S/MIME, PGP
Some applications use several key pairs for different and TLS1.0 (old SSLv3). One of these Ð PGP (Pretty Good
purposes, such as digital signatures, bulk encryption, and Privacy) is brie¯y discussed here.
authentication. PGP is a public key cryptography program designed for
use with Internet e-mail and created by Zimmermann [41].
3.2.4.1. Updating keys. New keys are usually issued at It is the world's defacto standard for e-mail encryption with
regular intervals so as to reduce the exposure from keys over six million users. PGP is a hybrid cryptosystem made
that have been unknowingly compromised. up of four cryptographic elements Ð a symmetric encryp-
tion cipher (IDEA), an asymmetric encryption cipher
3.2.4.2. Backing up keys. Users frequently forget the (RSA), a hash function (MD5) and a random number
passwords that protect their private keys Ð or they may generator. Each of these four elements are subject to a
lose the keys, for example, through a disk crash or virus different form of attack [14]. PGP users each maintain
attack. The company should be able to restore the keys to their own list (keyring) of the public keys of the people
the user. they communicate with. This keyring is signed by the user's
3.2.4.3. Archiving keys. When employees leave the own private key as a precaution against tampering. PGP
company, their keys must be invalidated, while retaining allows users to exchange keyrings and a user can add
the keys in order to access previously encrypted ®les and another key to the keyring, assigning one of the following
messages. Keys used for digital signatures may be retained four values to this new key:
for as long as the signed documents exist so that signatures
can be veri®ed. Some organisations archive encryption keys ² Completely trusted Ð if any other key is signed by this
but not signing keys, since the availability of archived key, then add the new key to the keyring.
signing keys could invite abuse via identity impersonation. ² Marginally trusted Ð a key signed by this key must also
be signed by one or more keys before it is added to the
3.2.4.4. Key expiry. To guard against a long-term keyring.
cryptanalytic attack, every key must have an expiration ² Untrusted Ð this key should not be used in determining
date. The time to expiration must therefore be much whether other keys can be added to the keyring or not.
shorter than the expected time for cryptanalysis. That is, ² Unknown Ð the level of trust for this key cannot be
the key length must be long enough to make the chances determined.
of cryptanalysis before key expiration extremely small. The
validity period for a key pair may also depend on the These values allow a user to assign a level of trust and the
circumstances in which the key is used. The appropriate user is able to tune the PGP's criteria for accepting a key.
key size is determined by the validity period, together For example if there are four users, Alice, Bob, Eve and
with the value of the information protected and the Chris. Bob knows Alice personally and has her key, while
estimated strength of an expected attacker. In a certi®cate Chris knows Eve and has her key. On day, Chris and Bob
the expiration date of a key is typically the same as the met and decided to exchange their keys.
expiration date of the certi®cate. At this point, Alice's keyring contains keys for Bob,
A signature veri®cation program should check for expira- Bob's keyring contains keys for Alice and Chris, Chris's
R. Hunt / Computer Communications 24 (2001) 1460±1471 1467
keyring contains keys for Bob and Eve and Eve's keyring quali®ed resources and a critical mass of businesses. It
only contains the key for Chris. would seem that PKI would eventually become more wide-
One day, Bob decides to exchange keyrings with Alice spread when it ®nally ®nds a solution to the problems
and Chris. He is able to exchange keyrings with Chris mentioned above. In the meantime, companies are imple-
securely because he knows Chris's key. Since Alice menting PKIs as a practical way to solve technological
knows Bob's key, when Bob sends her his keyring, she is problems such as managing VPNs.
able to verify that it is indeed Bob's keyring. Alice now has VPNs are now standardising on the IP Security (IPSec)
the keys for Bob, Chris and Eve. Alice can now commu- protocol [21]. A critical aspect of IPSec is how keys are
nicate reasonably securely with Chris since Bob obtained exchanged to authenticate each endpoint of the encrypted
Chris's key directly before giving it to her. However, if tunnel. The protocol for doing this is called Internet Key
Alice wants to communicate with Eve, she is relying on Exchange (IKE) [22] and supports manually entering
Chris. This effectively implies a chain of trust. Because pre-shared keys into both hosts, by the use of a secure
Alice trusts Bob, she ends up trusting Chris (someone she DNS and by a PKI CA. Manually con®guring shared secrets
never met). Alice also has no way of knowing which keys on every router and ®rewall is giving way to central
came from Chris unless Bob tells her explicitly. management through a CA. Con®guring VPN devices [19]
to authenticate via a CA provides a scalable, centrally
4.1. PGP PKI managed solution to revoking and reassigning the certi®-
cates used to create a trusted connection. This is just one
As users trade keyrings, they build up a web of trust and example of the many services that a PKI can provide.
this is the simplest form of a PKI. Each user, effectively
acting as their own root CA, is able to assign a level of
trust. The user's public key, with the keyring included, 5. PKI working group activities
could also be considered to be a type of user's certi®cate.
This simplicity, together with the fact that there is no expli- There are two key IETF working groups focused on PKI
cit infrastructure (the only infrastructure needed is e-mail) standards and implementations.
to maintain, allowed PGP to gain acceptance on the Internet. The Simple Public Key Infrastructure (SPKI) working
However, in applications where strong authentication is group 5 is developing Internet drafts for public key certi®cate
needed, the PGP±PKI is not acceptable. formats, signature formats and key acquisition protocols.
SPKI is intended to provide mechanisms to support security
4.2. Shortcomings of PGP±PKI over a range of protocols (e.g. IPSec) and applications,
which may require public key certi®cates such as encrypted
The web of trust method forces users to trust someone's e-mail, web documents and electronic payment systems.
entire keyring even if the user only really trusts the owner of Two important RFCs developed under SPKI are included
the keyring. In the example above, Alice trusts Bob, and in Refs. [33,34].
because she trusts Bob and his entire keyring, she is also The PKIX working group 6 has developed recommended
forced to trust Chris. Another problem related to the web of standards covering ®ve signi®cantly different sections [18]:
trust method is that if one user is fooled into believing some-
one else's identity, any other users will also be fooled into ² Pro®les of the X.509v3 certi®cate standards and the
believing that person's identity by trusting the keyring of the X.509v2 CRL standards for the Internet.
user who was originally fooled. ² Operational protocols, in which relying parties can obtain
A PGP certi®cate contains only an e-mail address, a information such as certi®cates or certi®cate status.
public key and a degree of trust attribute. Since an e-mail ² Management protocols, in which different entities in the
address can easily be forged, PGP does not provide strong system exchange information needed for proper manage-
authentication of a person's identity. Also PGP's use of ment of the PKI.
e-mail addresses prevents its users from having any degree ² Certi®cate policies and certi®cate practice statements,
of anonymity. Another issue with PGP certi®cates is that covering the areas of PKI security not directly addressed
they are not extensible and currently there is no coherent in the rest of PKIX.
method for validating, revoking PGP certi®cates (currently ² Time-stamping and data certi®cation services, which can
performed by word-of-mouth) or recovering lost keys. be used to build services such as non-repudiation.
These problems, and the fact that PGP was designed only
for securing e-mail prevents PGP from being used for appli-
cations beyond causal e-mail communication. 5.1. X.509v3 pro®les
4.3. An application of PKI X.509v3 certi®cates are complex data structures as they
offer a variety of extensions, which can take on a wide range requirements, revocation policy and others. PKI of Ref. [26]
of options. This provides considerable ¯exibility, which provides such a framework.
allows the X.509v3 certi®cate format to be used with a
many applications. Unfortunately, this same ¯exibility 5.5. Time-stamp and data certi®cation services
makes it extremely dif®cult to produce independent imple-
Time-stamping is a service in which a Time-stamp
mentations that will actually interoperate. To build an Inter-
Authority (TSA), which may be a TTP Ð signs a message
net PKI based on X.509v3 certi®cates, the PKIX working
to provide evidence that it existed prior to a speci®c time. A
group developed a pro®le of the X.509v3 speci®cation.
Time-stamping Protocol [9] provides some support for non-
A pro®le of the X.509v3 speci®cation is a description of
repudiation so that a user cannot claim that a transaction was
the contents of the certi®cate together with mandatory,
later forged after compromise of a private key. Existence of
optional or denied extensions. PKI of Ref. [23] provides
the signed time-stamp indicates that the transaction in
such a pro®le of X.509v3 and recommends a range of values
question could not have been created after the speci®ed
for various extensions. To promote interoperability, it is
time.
necessary to constrain the choices an implementer supports.
A token associates a message with a particular event and
In addition to pro®ling the certi®cate and CRL formats, it
provides supplementary evidence for the time speci®ed in
is necessary to specify particular Object Identi®ers (OIDs)
the time-stamp token. For example a token could associate
for certain encryption algorithms, since there are a variety of
the message with the most recent ®nal currency exchange
OIDs registered for certain algorithm suites. PKIX has
rate for the day.
produced two documents Ð [6,27], which provide
A Data Certi®cation Server protocol [5] is a TTP that
assistance on the implementation of speci®c algorithms.
veri®es the correctness of speci®c data submitted to it thus
Some countries are in a process of updating their legal
going beyond a simple time-stamping service. The DCS
frameworks in order to regulate and incorporate recognition
certi®es possession of data or validity of another entity's
of signatures in electronic format. Many of these frame-
signature. As part of this, the DCS veri®es the mathematical
works introduce certain basic requirements on certi®cates,
correctness of the actual signature value contained in a
(Quali®ed Certi®cates) for the support of these types of
request and also checks the full certi®cation path from the
`legal' signatures. There is a need for a speci®c certi®cate
signing entity to a trusted point (e.g. the DCS's CA, or the
pro®le providing standardised support for related issues
root CA in a hierarchy).
such as a common structure for expressing identities of
certi®ed subjects (unmistakable identity). The PKIX work- 5.6. PKI authorities, services and toolkits
ing group has adopted a re®nement of Ref. [23] that further
pro®les PKIX certi®cates into quali®ed certi®cates. This In Australia, Baltimore has been granted full accredita-
work is described in Ref. [8]. tion for `Gatekeeper' Ð the Australian Government PKI Ð
The Government Public Key Authority (GPKA), provides
5.2. Operational protocols public key infrastructure services for online Government
services. Other Australian organisations with `entry level'
Certi®cates and CRLs can be delivered by protocols such status include eSign (Verisign and Telstra), Price Water-
as LDAP, HTTP, FTP and X.500. Operational protocols that house Coopers, 7 while other regional PKI authorities
facilitate certi®cate delivery are de®ned in Refs. [7,28±31]. include: 128i-BayCorp (New Zealand), Singapore Govern-
ment, Hong Kong Post, and others. Suppliers of PKI
5.3. Management protocols systems include: Entrust (PKI 4.0), RSA (Keon 5.0), Micro-
soft (Windows 2000), Baltimore (Unicert), IBM Vault
Management protocols are needed to support online inter- Registry and SecureWay Trust Authority 3.1.
actions between PKI user and management entities. For
example, a management protocol might be used between a
6. Risks associated with the use of PKI
CA and a client with whom a key pair is associated, or
between CAs, which cross-certify one another. A manage-
Security has long been identi®ed as the major obstacle to
ment protocol can be used to carry user or client system
Internet-based commerce and PKI is frequently quoted as
registration information, or requests for certi®cate revoca-
the solution critical to secure transmissions over the Inter-
tion. Management protocols that facilitate message format
net. More recently questions have been raised [11] and this
and transmission are de®ned in Refs. [4,24].
reference questions some of the fundamental assumptions of
the PKI solution. The risks outlined in this paper are
5.4. Certi®cate policies discussed here Ð and to a considerable degree refuted. 8
Certi®cate policy and certi®cate practice statements 7
www.betrusted.com.
should address a variety of protocol security requirements 8
Comments drawn from Albertson, A., Analysis on the Ten Risks of
such as physical and personal security, subject identi®cation Using PKI, Work in Progress, University of Canterbury, 2000.
R. Hunt / Computer Communications 24 (2001) 1460±1471 1469
Can we trust the CAÐ and for what purposes are they be expected that CAs take adequate measures to provide
trustworthy? such protection and a good security audit would ensure
While it is possible that a `rogue' CA could be set up that this to be the case. For example VeriSign's issuing compu-
issued certi®cates of dubious value, a customer or business ters is housed in a secure non-networked environment that
would still need to be convinced that they are of some value requires multi-operator simultaneous access to counter such
and can be trusted. Currently browsers contain a number of problems.
public certi®cates from CAs that the user considers to be Can one determine which person is linked to a certi®cate
trustworthy (see Fig. 4). If a certi®cate from an unknown and how is this person different from any others?
CA is presented, the browser informs the user that this If all that was know about someone was that their name
certi®cate is from an unlisted CA and requests con®rmation was John Robinson and then one met someone called John
before acceptance. Robinson, there is not enough information to determine if
Who has access to your private key and how safe is it on this is an exact match. In real life, additional information is
your computer? known and this is the very reason why multiple factor
This is the greatest weakness of any cryptographic system authentication is becoming commonplace.
controlling access to private keys and is not speci®cally a When a digital certi®cate is received from somebody,
PKI issue. Cryptographically strong private keys are stored additional information is available over and above the
on a computer that is protected by a cryptographically weak name. Even if the certi®cate cannot authenticate a person
system such as normal passwords. However this is not a it does show that the same private key signed every message
dif®cult problem to guard against. Thus the risks here are received from John Robinson. To assist with such an issue,
real but they are the same as with any cryptographic system public key CAs such as VeriSign offer a certi®cate hierarchy
Ð the weakest link being that of controlling access to the as was discussed in Section 3.2.1.
keys rather than the strength of the encryption algorithm. Can the CA determine whom they are dealing with? Who
How secure is the verifying computer? has granted authority for the CA to be an authority?
The issue here is Ð can an attacker add their own private Private CA organisations that have bought PKI soft-
key to a list of keys used by the verifying computer? This ware and systems from companies can generate their
would allow an intruder to issue their own certi®cates that own certi®cates. As they know who the people in
are indistinguishable from legitimate certi®cates. It would their organisation are, they can identify who is being
1470 R. Hunt / Computer Communications 24 (2001) 1460±1471
issued with certi®cates. The major weakness is that keys. However, the solution to these issues should not
although the private CA can authenticate whom they impede the use of PKI at this time.
have issued certi®cates to, a recipient may not be able In summary Ð although there is some element of concern
to identify, who the CA is. over the path of trust, it is likely that CAs will become linked to
Public CAs such as VeriSign have the opposite problem. de®nitive sources such as a Government Department (e.g.
Everyone can identify the CA `VeriSign or an international Ministry of Commerce or other Government Security Bureau)
Af®liate' but who is named on the certi®cate? To overcome Ð even though the CA as seen from a user's perspective may
this inherent limitation, again CAs such as VeriSign can well be a (quasi) private organisation. The issuing of passports
offer a hierarchical level of certi®cates with appropriate by the Government passport of®ce Ð via another Department
levels of information content and associated trust (See or quasi government body Ð is not unlike the manner in which
Section 3.2.1). digital certi®cates could be issued.
Does the user get to see, read or check the certi®cate or is
it processed automatically within the computer? Does the
user control when a certi®cate is sent? 7. Summary
In practise both Netscape Navigator and Microsoft
Internet Explorer ask the user before any certi®cates are This paper has reviewed a range of technical, infrastruc-
sent (https://digitalid.verisign.com/client/help/privacy.htm) tural, operational and management issues associated with
although most users prefer the automatic features and the use of PKI. The major problem lies not in that it has a
allow the process to operate on their behalf. This is not number of limitations but that its supporters have sold it as a
similar to the manner in which cookies operate Ð most super safe security system [12]. They have equated the
users do not read, edit or analyse their cookies. cryptographic strength of current asymmetric and
Is the user dealing with the CA or the CA and an RA? symmetric algorithms with that of the strength of the PKI
Some systems on-sell the rights to certi®cate production system itself. There is no weakness in the cryptographic
to other companies. If a company does not consider itself an strength of the encryption and digital signature processes.
authority it can buy the rights to issues certi®cates from an However, the management of these processes, storage of
RA. This is more a theoretical risk since the major issue is cryptographically strong keys, identi®cation of entities,
whether the CA will follow the guidelines set down by the storage of certi®cates, etc. all need be subject to good
RA. While it is possible that a company could start issuing business practices Ð common to many security-based
certi®cates without following the procedures or proper business infrastructures.
authentication checks for its users, it is the responsibility PKI is still open to misrepresentation but the improve-
of the RA to control such subcontracts. As all full CAs have ments mentioned above would go a long way to ensuring
an RA authority function as well, it is just as likely that a full realistic expectations from PKI.
CA will not follow the correct procedures as a subcontracted PKI is still in its infancy and yet many organisations have
CA. So overall the risk is low as long as good business already begun deploying certi®cate-enabled applications
practises are adhered to. and infrastructures. 9 Looking ahead, businesses and organi-
This does raise the issue of new companies entering the sations who intend to use PKI will have to look at issues
market. Most customers are likely to choose an established such the legal aspects of liability, 10 interoperability between
supplier, which has a trusted history. This does mean that multiple PKIs, certi®cation validation paths, protection of
the current dominant public CA (VeriSign and its interna- private keys and user acceptance.
tional af®liates), will continue to have a virtual monopoly on PKI is a very promising security technology and if used
public CA certi®cation. properly, businesses and organisations can bene®t from it to
How secure are the certi®cate practices? Can anyone support a number of E-business initiatives, ranging from
steal a certi®cate? Can certi®cates be revoked? Do certi®- electronic commerce to secure communications to reduced
cates have a lifetime? infrastructure. The development of smart-cards is also likely
Again the issue of stolen certi®cates relates to good to be closely linked to future PKI development and deploy-
business practice, private key security, etc. Certi®cate revo- ment. However at this stage Ð given the complexity of the
cation and lifetime are pertinent management issues, which infrastructure required to implement and support a public
can currently be solved with small to medium scale PKI PKI system Ð continued deployment of PKI-enabled
systems. Both VeriSign and Entrust explain these problems applications for speci®c industry groups seems to be the
to their customers on their web sites. VeriSign has greater most likely path. By addressing the issues described
control as is responsible for generating certi®cates, which above, organisations should be able to take full advantage
have a ®nite lifetime (normally one year) as well as a simple of this new and signi®cant technology.
mechanism for users to revoke and renew their certi®cates 9
An example of this is the U.S. Department of Defense (DOD) imple-
(www.verisign.com/repository/digidren.html). The operation menting PKI department wide during the 2000±2003 timeframe.
of PKI on a much broader scale does pose some important 10
The legal status of digital signatures still requires further clari®cation
issues for the storage of revoked certi®cates and expired [2].
R. Hunt / Computer Communications 24 (2001) 1460±1471 1471