Key Management and

Distribution
MODULE - 4
Distribution of Public Keys
Introduction

To distribute the keys among different users, we use 4 different schemes:

1. Public announcement
2. Publicly available directory
3. Public-key authority
4. Public-key certificates
1. Public announcement

● Any participant can send his or her public key to any other participant or broadcast
the key to the community at large.
● Major weakness - Anyone can forge such a public announcement.
○ Meaning - some user could pretend to be user A and send a public key to another participant
or broadcast such a public key
Uncontrolled Public-Key Distribution
2. Publicly Available Directory

● A greater degree of security can be achieved by maintaining a publicly available

dynamic directory of public keys.
● Maintenance and distribution of the public directory would have to be the
responsibility of some trusted entity or organization.
● Such a scheme would include the following elements:
○ The authority maintains a directory with a {name, public key} entry for each participant.
○ Each participant registers a public key with the directory authority.
○ A participant may replace the existing key with a new one at any time, either because of the
desire to replace a public key that has already been used for a large amount of data, or
because the corresponding private key has been compromised in some way.
○ Participants could also access the directory electronically.
Public-Key Publication

● 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.
3. Public Key Authority

● Stronger security for

public-key distribution
can be achieved by
providing tighter
control over the
distribution of public
keys from the
directory.
For exchange of keys, the following steps occur:

Step 1: A sends a time stamped message to the public-key authority containing a request
for the current public key of B.

Step 2: The authority responds with a message that is encrypted using the authority’s
private key, PRauth.

Step 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.

Step 4,5: B retrieves A’s public key from the authority in the same manner as A retrieved
B’s public key.
For exchange of keys, the following steps occur(conti.):

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:

Step 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).

Step 7: A returns N2, which is encrypted using B’s public key, to assure B that its
correspondent is A.

Periodically, a user should request fresh copies of the public keys of its correspondents to
ensure currency.
Drawback

● 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.
4. Public-Key Certificates

● Alternative approach to the previous one is to use certificates.

● Certificates can be used by participants to exchange keys without contacting a
public-key authority.
● A certificate consists of a public key, an identifier of the key owner, and the whole
block signed by a trusted third party.
● The third party is a certificate authority, such as a government agency or a financial
institution, that is trusted by the user community.
● A user can present his or her public key to the authority in a secure manner and
obtain a certificate.
● The user can then publish the certificate.
Public-Key Certificates(conti.)

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.
4. Any participant can verify the time validity of the certificate.
X.509 Certificates
X.509 Certificate

● X.509 is a scheme that has become universally accepted for formatting public-key certificates.
● X.509 certificates are used in most network security applications, including IP security,
transport layer security (TLS), and S/MIME etc.

● X.509 defines a framework for the provision of authentication services by the X.500 directory
to its users.
● The directory is 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.
X.509 Certificate

● X.509 is based on the use of public-key cryptography and digital signatures.

● The certificate for Bob’s public key includes unique identifying information for Bob,
Bob’s public key, and identifying information about the CA, plus other information.
● This information is then signed by computing a hash value of the information and
generating a digital signature using the hash value and the CA’s private key.
X.509
Public-
Key
Certificat
e 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 general format of a certificate, which includes the following elements:
○ Version: Differentiates among successive versions of the certificate format; the default is
version 1. If the issuer unique identifier or subject unique identifier are present, the value
must be version 2. If one or more extensions are present, the version must be version 3.
○ Serial number: An integer value unique within the issuing CA that is unambiguously
associated with this certificate.
○ Signature algorithm identifier: The algorithm used to sign the certificate together with
any associated parameters.
○ Issuer name: X.500 name of the CA that created and signed this certificate.
○ Period of validity: Consists of two dates: the first and last on which the certificate is valid.
○ Subject name: The name of the user to whom this certificate refers. That is, this certificate
certifies the public key of the subject who holds the corresponding private key.
○ Subject’s public-key information: The public key of the subject, plus an identifier of the
algorithm for which this key is to be used, together with any associated parameters.
○ Issuer unique identifier: An optional-bit string field used to identify uniquely the issuing
CA in the event the X.500 name has been reused for different entities.
○ Subject unique identifier: An optional-bit string field used to identify uniquely the subject
in the event the X.500 name has been reused for different entities.
○ Extensions: A set of one or more extension fields. Extensions were added in version 3 and
are discussed later in this section.
○ Signature: Covers all of the other fields of the certificate. One component of this field is the
digital signature applied to the other fields of the certificate. This field includes the signature
algorithm identifier.
REVOCATION OF CERTIFICATES

● Each certificate includes a period of validity and a new certificate is issued just before the
expiration of the old one.
● It may be desirable on occasion to revoke a certificate before it expires, for one of the
following reasons:
1. The user’s private key is assumed to be compromised.
2. The user is no longer certified by this CA.
3. 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, this list should also be posted on the directory.
The
standard
uses the
following
notation
to define
a
certificat
e:
Case 1
● Problem: A has obtained a certificate from certification authority X1 and B has obtained a
certificate from CA X2.
● Solution: 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.

B can obtain A’s public key: X1 << X2 >> X2 << B >>

B can obtain A’s public key: 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:
Case 2

● User A can acquire the following certificates from

the directory to establish a certification path to B:
X <<W>> W <<V>> V <<Y>> Y <<Z>>
Z<<B>>

● If A wishes to receive encrypted messages back

from B, or to sign messages sent to B, then B will
require A’s public key, which can be obtained
from the following certification path:
Z <<Y>> Y <<V>> V <<W>> W <<X>> X
<<A>>
X.509 Version 3

● The X.509 version 2 format does not convey all of the information that recent
design and implementation experience has shown to be needed.
● Rather than continue to add fields to a fixed format.
● Version 3 includes a number of optional extensions that may be added to the
version 2 format.
● Each extension consists of an extension identifier, a criticality indicator, and an
extension value.
● The certificate extensions fall into three main categories: key and policy information,
subject and issuer attributes, and certification path constraints.