Cryptography and Network

Security
Unit - 8
Chapter 14
Key Management and
Distribution

Reference: Cryptography and Network Security, 5/e or 6/e,

By William Stallings
 Key Management and
Distribution
 topicsof cryptographic key management /
key distribution are complex
 cryptographic, protocol, & management issues
 symmetric schemes require both parties to
share a common secret key
 public key schemes require parties to
acquire valid public keys
 have concerns with doing both
 Road Map

 symmetric key distribution using symmetric

encryption
 symmetric key distribution using public-key
encryption
 distribution of public keys
• announcement, directory, authrority, CA
 X.509 authentication and certificates
 public key infrastructure (PKIX)
 Key Distribution
 symmetric schemes require both parties to
share a common secret key
 issue is how to securely distribute this key
 whilst protecting it from others
 frequent key changes can be desirable
 often secure system failure due to a break
in the key distribution scheme
 Key Distribution
 given parties A and B have various key
distribution alternatives:
1. A can select key and physically deliver to B
2. third party can select & deliver key to A & B
3. if A & B have communicated previously can
use previous key to encrypt a new key
4. if A & B have secure communications with a
third party C, C can relay key between A & B
Key Distribution Task
 Key Hierarchy
 typically
have a hierarchy of keys
 session key
 temporary key
 used for encryption of data between users
 for one logical session then discarded
 master key
 used to encrypt session keys
 shared by user & key distribution center
Key Hierarchy
Key Distribution Scenario
 Let us assume that user A wishes to establish a logical
connection with B and requires a one-time session key to
protect the data transmitted over the connection. A has a
master key, Ka, , known only to itself and the KDC; similarly,
B shares the master key Kb with the KDC. The following
steps occur:

1. A issues a request to the KDC for a session key to protect a

logical connection to B. The message includes the identity of
A and B and a unique identifier, N1 .
 For this transaction, which we refer to as a nonce. The
nonce may be a timestamp, a counter, or a random number;
the minimum requirement is that it differs with each request.
Also, to prevent masquerade, it should be difficult for an
opponent to guess the nonce. Thus, a random number is a
good choice for a nonce.
2. The KDC responds with a message encrypted using Ka
Thus, A is the only one who can successfully read the
message, and A knows that it originated at the KDC.

The message includes two items intended for A:

 The one-time session key, Ks , to be used for the session.

 The original request message, including the nonce, to enable
A to match this response with the appropriate request.
Thus, A can verify that its original request was not altered
before reception by the KDC and, because of the nonce, that
this is not a replay of some previous request.

In addition, the message includes two items intended for B:

 The one-time session key, Ks to be used for the session

 An identifier of A (e.g., its network address), IDA

These last two items are encrypted with Kb (the master key that
the KDC shares with B). They are to be sent to B to establish
the connection and prove A's identity.
3. A stores the session key for use in the upcoming
session and forwards to B the information that
originated at the KDC for B, namely, E(Kb, [Ks || IDA]).
Because this information is encrypted with Kb, it is
protected from eavesdropping. B now knows the
session key (Ks), knows that the other party is A (from
IDA), and knows that the information originated at the
KDC (because it is encrypted using Kb).
At this point, a session key has been securely delivered to
A and B, and they may begin their protected exchange.
However, two additional steps are desirable.

4. Using the newly minted session key for encryption, B

sends a nonce N2, to A.

5. Also using Ks, A responds with f(N2), where f is a

function that performs some transformation on N2 (e.g.,
adding one). These steps assure B that the original
message it received (step 3) was not a replay.
 Key Distribution Issues
 Hierarchical key control: hierarchies of KDC’s
required for large networks, but must trust each
other – Local and Global KDC
 Session key Lifetime: session key lifetimes
should be limited for greater security
 A Transparent Key Control Scheme: use of
automatic key distribution on behalf of users, but
must trust system – For end-to-end encryption
like TCP (connection-oriented) - Session
Security Module(SSM)
Decentralized
DecentralizedkeykeyControl:
Control:use
useofofdecentralized
decentralized
key distribution
key distribution
 Controlling key usage:
 The concept of a key hierarchy and the use of automated key
distribution techniques greatly reduce the number of keys that must
be manually managed and distributed.

 It may also be desirable to impose some control on the way in which

automatically distributed keys are used.

 For example, in addition to separating master keys from session keys,

we may wish to define different types of session keys on the basis of
use, such as

•
• Data-encrypting key, for general communication across a network.

• PIN-encrypting key, for personal identification numbers (PINs)

used in electronic funds transfer and point-of-sale applications.

• File-encrypting key, for encrypting files stored in publicly

accessible locations.
 To illustrate the value of separating keys by type,
consider the risk that a master key is imported as a data-
encrypting key into a device.
 Normally, the master key is physically secured within the
cryptographic hardware of the key distribution center and
of the end systems.
 Session keys encrypted with this master key are
available to application programs, as are the data
encrypted with such session keys.
 However, if a master key is treated as a session key, it
may be possible for an unauthorized application to
obtain plaintext of session keys encrypted with that
master key.
 Thus, it may be desirable to institute controls in systems that limit
the ways in which keys are used, based on characteristics
associated with those keys.
 One simple plan is to associate a tag with each key. The proposed
technique is for use with DES and makes use of the extra 8 bits in
each 64-bit DES key.
 That is, the eight non-key bits ordinarily reserved for parity checking
form the key tag.
 The bits have the following interpretation:
• One bit indicates whether the key is a session key or a master key.
• One bit indicates whether the key can be used for encryption.
• One bit indicates whether the key can be used for decryption.
• The remaining bits are spares for future use.
 Because the tag is embedded in the key, it is encrypted along with
the key when that key is distributed, thus providing protection
The drawbacks of this scheme are

1. The tag length is limited to 8 bits, limiting its flexibility and

functionality.

2. Because the tag is not transmitted in clear form, it can be used only
at the point of decryption, limiting the ways in which key use can be
controlled.

 A more flexible scheme, referred to as the control vector, In this

scheme, each session key has an associated control vector
consisting of a number of fields that specify the uses and restrictions
for that session key.The length of the control vector may vary.
Control vector encryption and decryption
 The hash value is then XORed with the master key to produce an output
that is used as the key input for encrypting the session key. Thus,
Hash value = H = h(CV)
Key input = Km H
Ciphertext = E([Km H], Ks)
 where Km is the master key and Ks is the session key. The session key is
recovered in plaintext by the reverse operation:
D([Km H], E([Km H], Ks))
 When a session key is delivered to a user from the KDC, it is accompanied
by the control vector in clear form. The session key can be recovered only
by using both the master key that the user shares with the KDC and the
control vector.
 Thus, the linkage between the session key and its control vector is
maintained.
 Use of the control vector has two advantages over use of an 8-bit tag.
 First, there is no restriction on length of the control vector, which enables
arbitrarily complex controls to be imposed on key use.
 Second, the control vector is available in clear form at all stages of
operation. Thus, control of key use can be exercised in multiple locations.
 Road Map

 symmetric key distribution using symmetric

encryption
 symmetric key distribution using public-key
encryption
 distribution of public keys
• announcement, directory, authrority, CA
 X.509 authentication and certificates
 public key infrastructure (PKIX)
 Symmetric Key Distribution
Using Public Keys
 public key cryptosystems are inefficient
 so almost never use for direct data encryption
 rather use to encrypt secret keys for distribution
Simple Secret Key Distribution
 Merkle proposed this very simple scheme
 allows secure communications
 no keys before/after exist
If A wishes to communicate with B, the following procedure is employed:

1. A generates a public/private key pair {PUa, PRa} and transmits a

message to B consisting of PUa and an identifier of A, IDA

2. B generates a secret key, Ks , and transmits it to A, which is

encrypted with A’s public key.

3. A computes D(PRa, E(Pua, Ks)) to recover the secret key. Because

only A can decrypt the message, only A and B will know the identity of
Ks.

4. A discards Pua and PRa and B discards PUa.

A and B can now securely communicate using conventional encryption

and the session key Ks. At the completion of the exchange, both A and
B discard Ks.
 Man-in-the-Middle Attack
 thisvery simple scheme is vulnerable to
an active man-in-the-middle attack
Secret Key Distribution with
Confidentiality and
Authentication
 Hybrid Key Distribution
 retain use of private-key KDC
 shares secret master key with each user
 distributes session key using master key
 public-key used to distribute master keys
 especially useful with widely distributed users
 rationale
 performance
 backward compatibility
 Road Map

 symmetric key distribution using symmetric

encryption
 symmetric key distribution using public-key
encryption
 distribution of public keys
• announcement, directory, authority, CA
 X.509 authentication and certificates
 public key infrastructure (PKIX)
 Distribution of Public Keys
 can be considered as using one of:
 public announcement
 publicly available directory
 public-key authority
 public-key certificates
Public Announcement
 Public Announcement
 users
distribute public keys to recipients or
broadcast to community at large
 eg. append PGP keys to email messages or
post to news groups or email list
 major weakness is forgery
 anyone can create a key claiming to be
someone else and broadcast it
 until forgery is discovered can masquerade as
claimed user
Publicly Available Directory
 Publicly Available Directory
 can obtain greater security by registering
keys with a public directory
 directory must be trusted with properties:
 contains {name,public-key} entries
 participants register securely with directory
 participants can replace key at any time
 directory is periodically published
 directory can be accessed electronically
 still vulnerable to tampering or forgery
Public-Key Authority
 1.A sends a timestamped message to the public-key
authority containing a request for the current public key
of B.
 2. The authority responds with a message that is
encrypted using the authority's private key, PRauth Thus,
A is able to decrypt the message using the authority's
public key. Therefore, A is assured that the message
originated with the authority.
 The message includes the following:
 B's public key, PUb which A can use to encrypt messages destined for B
 The original request, to enable A to match this response with the
corresponding earlier request and to verify that the original request was
not altered before reception by the authority
 The original timestamp, so A can determine that this is not an old
message from the authority containing a key other than B's current
public key
 3. A stores B's public key and also uses it to encrypt a message to B
containing an identifier of A ( IDA) and a nonce ( N1), which is used
to identify this transaction uniquely.
 4, 5. B retrieves A's public key from the authority in the same
manner as A retrieved B's public key.
 At this point, public keys have been securely delivered to A and B,
and they may begin their protected exchange. However, two
additional steps are desirable:
 6. B sends a message to A encrypted with PUa and containing A's
nonce ( N1) as well as a new nonce generated by B ( N2). Because
only B could have decrypted message (3), the presence of N1 in
message (6) assures A that the correspondent is B.
 7. A returns N2, encrypted using B's public key, to assure B that its
correspondent is A.

 The scenario is attractive but it has 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 allow key exchange without
real-time access to public-key authority
 a certificate binds identity to public key
 usually with other info such as period of
validity, rights of use etc
 with all contents signed by a trusted
Public-Key or Certificate Authority (CA)
 can be verified by anyone who knows the
public-key authorities public-key
 We can place the following requirements on this
scheme:
1. Any participant can read a certificate to determine
the name and public key of the certificate's owner.
2. Any participant can verify that the certificate
originated from the certificate authority and is not
counterfeit.
3. Only the certificate authority can create and
update certificates.
 These requirements are satisfied by the original proposal
in [KOHN78]. Denning [DENN83] added the following
additional requirement:
4. Any participant can verify the currency of the
certificate.
 Public-Key Certificates

D(PUauth , CA ) = D(PUauth , E(PRauth , [ T|| IDA || PUa ])) = ( T || IDA || PUa )

 Road Map

 symmetric key distribution using symmetric

encryption
 symmetric key distribution using public-key
encryption
 distribution of public keys
• announcement, directory, authrority, CA
 X.509 authentication and certificates
 public key infrastructure (PKIX)
 Public-Key Certificates
 certificates allow key exchange without
real-time access to public-key authority
 a certificate binds identity to public key
 usually with other info such as period of
validity, rights of use etc
 with all contents signed by a trusted
Public-Key or Certificate Authority (CA)
 can be verified by anyone who knows the
public-key authorities public-key
Public-Key Certificates
X.509 Authentication Service
 part of CCITT X.500 directory service standards
 distributed servers maintaining user info database
 defines framework for authentication services
 directory may store public-key certificates
 with public key of user signed by certification authority
 also defines authentication protocols
 uses public-key crypto & digital signatures
 algorithms not standardised, but RSA recommended
 X.509 certificates are widely used
 have 3 versions
X.509 Certificate Use
 X.509 Certificates
 issued by a Certification Authority (CA), containing:
 version V (1, 2, or 3)
 serial number SN (unique within CA) identifying certificate
 signature algorithm identifier AI
 issuer X.500 name - of the CA that created and signed this
certificate
 period of validity TA (from - to dates)
 subject X.500 name A (name of owner)
 subject public-key info Ap (algorithm, parameters, key)
 issuer unique identifier (v2+)
 subject unique identifier (v2+)
 extension fields (v3)
 signature (of hash of all fields in certificate)
 notation CA<<A>> denotes certificate for A signed by CA
X.509 Certificates
X.509 Certificates
 Obtaining a Certificate
 any user with access to the public key of
the CA can verify the user public key that
was certified.
 only the CA can modify a certificate
 because cannot be forged, certificates can
be placed in a public directory
 Obtaining a Certificate
 Now suppose that A has obtained a certificate from
certification authority and B has obtained a certificate
from CA .

 If A does not securely know the public key of , then B’s

certificate, issued by , 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.
 Obtaining a Certificate
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.
 Obtaining a Certificate
 A has used a chain of certificates to obtain B’s public key.
In the notation of X.509, this chain is expressed as
X1 << X2 >> X2 << B >>
 In the same fashion, B can obtain A’s public key with the
reverse chain:
X2 << X1 >> X1 << A >>
 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 N elements
would be expressed as
X1 << X2 >> X2 << X3 >> … XN << B >>
 CA Hierarchy
 if both users share a common CA then they are
assumed to know its public key
 otherwise CA's must form a hierarchy
 use certificates linking members of hierarchy to
validate other CA's
 each CA has certificates for clients (forward) and
parent (backward)
 each client trusts parents certificates
 enable verification of any certificate from one CA
by users of all other CAs in hierarchy
CA Hierarchy Use
 CA Hierarchy
 Figure , taken from X.509, is an example of such a
hierarchy. The connected circles indicate the hierarchical
relationship among the CAs.

 The associated boxes indicate certificates maintained in

the directory for each CA entry.

 The directory entry for each CA includes two types of

certificates:

• Forward certificates: Certificates of X generated by

other CAs
• Reverse certificates: Certificates generated by X that are
the certificates of other CAs
CA Hierarchy
 Certificate Revocation
 certificates have a period of validity
 may need to revoke before expiry, eg:
1. user's private key is compromised
2. user is no longer certified by this CA
3. CA's certificate is compromised
 CA’s maintain list of revoked certificates
 the Certificate Revocation List (CRL)
 users should check certificates with CA’s CRL
 X.509 Version 3
 has been recognised that additional
information is needed in a certificate
 email/URL, policy details, usage constraints
 ratherthan explicitly naming new fields
defined a general extension method
 extensions consist of:
 extension identifier
 criticality indicator
 extension value
 Certificate Extensions
 key and policy information
 convey additional info. about subject & issuer keys,
plus indicators of certificate policy

 A certificate policy is a named set of rules that

indicates the applicability of a certificate to a particular
community and/or class of application with common
security requirements.

 For example, a policy might be applicable to the

authentication of electronic data interchange (EDI)
transactions for the trading of goods within a given
price range.
 Certificate Extensions
 This area includes:
 Authority key identifier: Identifies the public
key to be used to verify the signature on this
certificate or CRL.

 Subject Key Identifier: Identifies the public

key being certified. Useful for subject key pair
updating

 Key usage: Indicates a restriction imposed as

to the purpose for which, and the policy under
which, the certificate public key may be used.
 Certificate Extensions
 This area includes:
 Private-Key usage period: Indicates the
period of use of private key correspondingly to
the public key.

 Certificate policy: Certificates may be used

in environment where multiple polices apply.

 Policy mappings: Used only in certificates

for CAs issued by other CAs.
 Certificate Extensions
 certificate subject and issuer attributes
 support alternative names, in alternative formats for
certificate subject and/or issuer

 Subject alternative names: Contains one or more

alternative names, using any of variety of forms. Used
in application like E-mail, EDI and IPSec.

 Issuer alternative name: Contains one or more

alternative names, using variety of forms.

 Subject directory attributes: Conveys any desired

X.500 directory attributes values for the subject of this
certificates
 Certificate Extensions
 certificate path constraints
 allow constraints on use of certificates by other CA’s

 Basic constraints: Indicates if the subject may act as a

CA. If so, a certification path length constraint may be
specified.

 Name constraints: Indicates a name space within which

all subject names in subsequent certificates in a
certification path must be located.

 Policy constraints: Specifies constraints that may

require explicit certificate policy identification or inhibit
policy mapping for the remainder of the certification path.
 Road Map

 symmetric key distribution using symmetric

encryption
 symmetric key distribution using public-key
encryption
 distribution of public keys
• announcement, directory, authrority, CA
 X.509 authentication and certificates
 public key infrastructure (PKIX)
 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 IETF Public Key Infrastructure X.509 (PKIX) working

group has setup a formal (and generic) model based on
X.509 that is suitable for deploying a certificate-based
architecture on the Internet.
 Public Key Infrastructure
 Figure shows interrelationships among some key elements:

• 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 can 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.
Public Key Infrastructure

Figure. PKIX Architectural Model

 Public Key Infrastructure
• 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
by End Entities.
 PKIX Management
 PKIX identifies a number of management functions that
potentially need to be supported by management
protocols. These are indicated in previous figure and
include the following:

 Registration: This is the process whereby a user first

makes itself known to a CA (directly or through an
RA), prior to that CA issuing a certificate or certificates
for that user. Registration begins the process of
enrolling in a PKI. Registration usually involves some
offline or online procedure for mutual authentication.
Typically, the end entity is issued one or more shared
secret keys used for subsequent authentication.
 PKIX Management
 Initialization: Before a client system can operate
securely, it is necessary to install key materials that
have the appropriate relationship with keys stored
elsewhere in the infrastructure. For example, the
client needs to be securely initialized with the public
key and other assured information of the trusted
CA(s), to be used in validating certificate paths.

 Certification: This is the process in which a CA

issues a certificate for a user’s public key, returns that
certificate to the user’s client system, and/or posts
that certificate in a repository.
 PKIX Management
 key pair recovery
 Key pairs can be used to support digital signature
creation and verification, encryption and
decryption, or both.
 When a key pair is used for encryption/decryption,
it is important to provide a mechanism to recover
the necessary decryption keys when normal
access to the keying material is no longer possible,
otherwise it will not be possible to recover the
encrypted data.
 PKIX Management
 Loss of access to the decryption key can result from
forgotten passwords/PINs, corrupted disk drives,
damage to hardware tokens, and so on.

 Key pair recovery allows end entities to restore their

encryption/decryption key pair from an authorized key
backup facility (typically, the CA that issued the end
entity’s certificate).
 PKIX Management
 key pair update
 All key pairs need to be updated regularly (i.e.,
replaced with a new key pair) and new certificates
issued. Update is required when the certificate
lifetime expires and as a result of certificate
revocation.
 revocation request
 An authorized person advises a CA of an abnormal
situation requiring certificate revocation. Reasons
for revocation include private key compromise,
change in affiliation, and name change.
 PKIX Management
 cross certification
 Two CAs exchange information used in
establishing a cross-certificate. A cross-certificate
is a certificate issued by one CA to another CA that
contains a CA signature key used for issuing
certificates.
 PKIX Management
 protocols:
 CMP
 RFC 2510 defines the certificate management
protocols (CMP). Within CMP, each of the
management functions is explicitly identified by
specific protocol exchanges. CMP is designed to be a
flexible protocol able to accommodate a variety of
technical, operational, and business models.
 PKIX Management
 protocols:
 CMC
 RFC 2797 defines Certificate Management messages
over CMS (Cryptographic Message Syntax)(CMC), where
CMS refers to RFC 2630, cryptographic message
syntax.
 CMC is built on earlier work and is intended to
leverage existing implementations.
 Although all of the PKIX functions are supported, the
functions do not all map into specific protocol
exchanges.
 Summary
 have considered:
 symmetric key distribution using symmetric
encryption
 symmetric key distribution using public-key
encryption
 distribution of public keys
• announcement, directory, authrority, CA
 X.509 authentication and certificates
 public key infrastructure (PKIX)