Key Management and Distribution

• Key distribution is the function that delivers a key to two parties who
wish to exchange secure encrypted data. Some sort of mechanism or
protocol is needed to provide for the secure distribution of keys.
• Key distribution often involves the use of master keys, which are
infrequently used and are long lasting, and session keys, which are
generated and distributed for temporary use between two parties.
• Public-key encryption schemes are secure only if the authenticity of the
public key is assured. A public-key certificate scheme provides the
necessary security.
• X.509 defines the format for public-key certificates. This format is widely
used in a variety of applications.
• A public-key infrastructure (PKI) is defined as the set of hardware,
software, people, policies, and procedures needed to create, manage,
store, distribute, and revoke digital certificates based on asymmetric
cryptography.
• Typically, PKI implementations make use of X.509 certificates.
• The topics of cryptographic key management and cryptographic key
distribution are complex, involving cryptographic, protocol, and
management considerations.
• The purpose of this chapter is to give the reader a feel for the issues
involved and a broad survey of the various aspects of key management
 1. Symmetric Key Distribution using Symmetric
Encryption
• The strength of any cryptographic system rests with the key
distribution technique, a term that refers to the means of
delivering a key to two parties who wish to exchange data
without allowing others to see the key.
• For two parties A and B, key distribution can be achieved in
a number of ways, as follows:
– A can select a key and physically deliver it to B.
– A third party can select the key and physically deliver it to A and B.
– If A and B have previously and recently used a key, one party can
transmit the new key to the other, encrypted using the old key.
– If A and B each has an encrypted connection to a third party C, C can
deliver a key on the encrypted links to A and B.
• A Key Distribution Scenario
• Automatic Key Distribution for Connection-Oriented
Protocol
Decentralized Key Distribution
• The use of a key distribution center imposes the requirement
that the KDC be trusted and be protected from subversion.
• This requirement can be avoided if key distribution is fully
decentralized.
• Although full decentralization is not practical for larger
networks using symmetric encryption only, it may be useful
within a local context.
• Thus, there may need to be as many as n(n-1)/2 master keys
for a configuration with n end systems.
 Symmetric Key Distribution using Asymmetric
Encryption
• Because of the inefficiency of public key cryptosystems, they
are almost never used for the direct encryption of sizable
block of data, but are limited to relatively small blocks.
• One of the most important uses of a public-key cryptosystem
is to encrypt secret keys for distribution.

• Despite its simplicity, this is an attractive protocol. No keys

exist before the start of the communication and none exist
after the completion of communication.
• Thus, the risk of compromise of the keys is minimal.
• At the same time, the communication is secure from
eavesdropping.
• The protocol depicted in previous figure is insecure against
an adversary who can intercept messages and then either
relay the intercepted message or substitute another
message.
• Such an attack is known as a man-in-the-middle attack.

• Thus, this simple protocol is only useful in an environment

where the only threat is eavesdropping.
• Secret Key Distribution with Confidentiality and
Authentication
3. Distribution of Public Keys
• Several techniques have been proposed for the distribution of
public keys.
• Virtually all these proposals can be grouped into the
following general schemes:
– Public announcement
– Publicly available directory
– Public-key authority
– Public-key certificates
• Public Announcement of Public Keys

• Although this approach is convenient, it has a major

weakness.
• Anyone can forge such a public announcement. That is, some
user could pretend to be user A and send a public key to
another participant or broadcast such a public key. Until
such time as user A discovers the forgery and alerts other
participants, the forger is able to read all encrypted
messages intended for A and can use the forged keys for
authentication.
• Publicly Available Directory

• This scheme is clearly more secure than individual public

announcements but still has vulnerabilities.
• If an adversary succeeds in obtaining or computing the
private key of the directory authority, the adversary could
authoritatively pass out counterfeit public keys and
subsequently impersonate any participant and eavesdrop on
messages sent to any participant.
• Another way to achieve the same end is for the adversary to
tamper with the records kept by the authority.
• Public-Key Authority

• The scenario is attractive, yet it has some drawbacks.

• The public-key authority could be somewhat of a bottleneck in the
system, for a user must appeal to the authority for a public key for
every other user that it wishes to contact.
• As before, the directory of names and public keys maintained by
the authority is vulnerable to tampering.
• Public-Key Certificates
• Certificates that can be used by participants to exchange
keys without contacting a public-key authority, in a way that
is as reliable as if the keys were obtained directly from a
public-key authority.
• In essence, a certificate consists of a public key, an identifier
of the key owner, and the whole block signed by a trusted
third party.
• Typically, the third party is a certificate authority, such as a
government agency or a financial institution, that is trusted
by the user community.
• One scheme has become universally accepted for formatting
public-key certificates: the X.509 standard.
• X.509 certificates are used in most network security
applications, including IP security, transport layer security
(TLS), and S/MIME.
X.509 Certificates
• X.500 - Define a directory service.
• The directory is, in effect, a server or distributed set of
servers that maintains a database of information about
users.
• The information includes a mapping from user name to
network address, as well as other attributes and information
about the users.
• ITU-T recommendation X.509 is part of the X.500.
• X.509 defines a framework for the provision of
authentication services by the X.500 directory to its users.
• The directory may serve as a repository of public-key
certificates.
• Each certificate contains the public key of a user and is
signed with the private key of a trusted certification
authority.
• In addition, X.509 defines alternative authentication
protocols based on the use of public-key certificates.
• X.509 is an important standard because the certificate
structure and authentication protocols defined in X.509 are
used in a variety of contexts. For example, the X.509
certificate format is used in S/MIME, IP Security, and
SSL/TLS.
• X.509 was initially issued in 1988. The standard was
subsequently revised to address some of the security
concerns; a revised recommendation was issued in 1993. A
third version was issued in 1995 and revised in 2000.
• X.509 is based on the use of public-key cryptography and
digital signatures.
• The standard does not dictate the use of a specific algorithm
but recommends RSA. The digital signature scheme is
assumed to require the use of a hash function. Again, the
standard does not dictate a specific hash algorithm.
• The 1988 recommendation included the description of a
recommended hash algorithm; this algorithm has since been
shown to be insecure and was dropped from the 1993
recommendation.
• Public-Key Certificate Use
Certificates
• The heart of the X.509 scheme is the public-key certificate
associated with each user.
• These user certificates are assumed to be created by some
trusted certification authority (CA) and placed in the
directory by the CA or by the user.
• The directory server itself is not responsible for the creation
of public keys or for the certification function; it merely
provides an easily accessible location for users to obtain
certificates.
• X.509 Format
• If there is a large community of users, it may not be practical
for all users to subscribe to the same CA. Because it is the
CA that signs certificates, each participating user must have
a copy of the CA’s own public key to verify signatures.
• This public key must be provided to each user in an
absolutely secure (with respect to integrity and authenticity)
way so that the user has confidence in the associated
certificates.
• Thus, with many users, it may be more practical for there to
be a number of CAs, each of which securely provides its
public key to some fraction of the users.
• Now suppose that A has obtained a certificate from CA-X1
and B has obtained a certificate from CA-X2. If A does not
securely know the public key of X2, then B’s certificate,
issued by X2, is useless to A.
• A can read B’s certificate, but A cannot verify the signature.
• However, if the two CAs have securely exchanged their own
public keys, the following procedure will enable A to obtain
B’s public key.
• Step 1 A obtains from the directory the certificate of X2
signed by X1. Because A securely knows X1’s public key, A
can obtain X2’s public key from its certificate and verify it by
means of X1’s signature on the certificate.
• Step 2 A then goes back to the directory and obtains the
certificate of B signed by X2. Because A now has a trusted
copy of X2’s public key, A can verify the signature and
securely obtain B’s public key.
• A has used a chain of certificates to obtain B’s public key. In
the notation of X.509, this chain is expressed as

• In the same fashion, B can obtain A’s public key with the
reverse chain:
• This scheme need not be limited to a chain of two
certificates. An arbitrarily long path of CAs can be followed
to produce a chain. A chain with elements would be
expressed as
X.509 Hierarchy: A Hypothetical Example

In this example, user A can acquire the following certificates

from the directory to establish a certification path to B:
Revocation of Certificates
• Each certificate includes a period of validity, much like a
credit card.
• Typically, a new certificate is issued just before the
expiration of the old one.
• In addition, it may be desirable on occasion to revoke a
certificate before it expires, for one of the following reasons.
– The user’s private key is assumed to be compromised.
– The user is no longer certified by this CA. Reasons for this include
that the subject’s name has changed, the certificate is superseded, or
the certificate was not issued in conformance with the CA’s policies.
– The CA’s certificate is assumed to be compromised.
• Each CA must maintain a list consisting of all revoked but
not expired certificates issued by that CA, including both
those issued to users and to other CAs. These lists should
also be posted on the directory.
Certificate Revocation List

•Each certificate revocation list

(CRL) posted to the directory is
signed by the issuer and includes
the issuer’s name, the date the list
was created, the date the next CRL
is scheduled to be issued, and an
entry for each revoked certificate.

•Each entry consists of the serial

number of a certificate and
revocation date for that certificate.
Because serial numbers are unique
within a CA, the serial number is
sufficient to identify the certificate.
Public Key Infrastructure

• RFC 2822 (Internet Security Glossary) defines public-key

infrastructure (PKI) as the set of hardware, software, people,
policies, and procedures needed to create, manage, store,
distribute, and revoke digital certificates based on
asymmetric cryptography.
• The principal objective for developing a PKI is to enable
secure, convenient, and efficient acquisition of public keys.
• The Internet Engineering Task Force (IETF) Public Key
Infrastructure X.509 (PKIX) working group has been the
driving force behind setting up a formal (and generic) model
based on X.509 that is suitable for deploying a certificate-
based architecture on the Internet.
• PKIX Architectural Model
• End entity: A generic term used to denote end users,
devices (e.g., servers, routers), or any other entity that can
be identified in the subject field of a public key certificate.
End entities typically consume and/or support PKI-related
services.
• Certification authority (CA): The issuer of certificates
and (usually) certificate revocation lists (CRLs). It may also
support a variety of administrative functions, although these
are often delegated to one or more Registration Authorities.
• Registration authority (RA): An optional component that
can assume a number of administrative functions from the
CA. The RA is often associated with the end entity
registration process but can assist in a number of other
areas as well.
• CRL issuer: An optional component that a CA can delegate
to publish CRLs.
• Repository: A generic term used to denote any method for
storing certificates and CRLs so that they can be retrieved