Chapter 5
Key management and
Distribution
Key Management and Distribution
Topics of 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
Symmetric Key Distribution
Symmetric schemes require both parties to
share a common secret key
Frequent key changes can be desirable to
limit the amount of data compromised if
the attacker learns the key.
The issue is how to securely distribute this
key whilst protecting it from others
On many cases secure systems fail due to a
break in the key distribution schemes
Cont..
The strength of any cryptographic system
depends on the key distribution technique
Given parties A and B they can use
various symmetric 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 they
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
If end-to-end encryption is done at a network or IP level,
then a key is needed for each pair of hosts on the network
that wish to communicate. Thus, if there are N hosts, the
number of required keys is [N(N – 1)]/2
Key Hierarchy/KD Using Master Key
For end-to-end encryption, some variation on option 4 has
been widely adopted.
In this scheme, a key distribution center is responsible for
distributing keys to pairs of users as needed.
At a minimum, two levels of keys are used:
master key
shared by user & key distribution center
used to encrypt session keys
session key
temporary key
used for encryption of data between users
Used for one logical session and then discarded
Key Hierarchy
Key Distribution Scenario
1. A requests from the KDC a session key to protect a
logical connection to B. The message includes the
identity of A and B and a unique nonce N1.
2. The KDC responds with a message encrypted using Ka
that includes a one-time session key Ks to be used for
the session, the original request message to enable A to
match response with appropriate request, and info for B
3. A stores the session key for use in the upcoming session
and forwards to B the information from the KDC for B,
namely, E(Kb, [Ks || IDA]). Because this information is
encrypted with Kb, it is protected from eavesdropping.
Key Distribution Scenario
At this point, a session key has been securely delivered
to A and B, and they may begin their protected
exchange. Two additional steps are desirable:
4. Using the new 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 (eg.
adding one). These steps assure B that the original
message it received (step 3) was not a replay.
Note that the actual key distribution involves only
steps 1 through 3 but that steps 4 and 5, as well as 3,
perform an authentication function.
Key Distribution Scenario
Key Distribution Issues
hierarchies of KDC’s required for large
networks, but must trust each other
session key lifetimes should be limited for
greater security
use of automatic key distribution on behalf
of users provides flexibility, but the system
must be trusted for the users
– controlling key usage
Symmetric Key Distribution
Using Public Keys
One of the most important uses of a public-key
cryptosystem is to encrypt secret keys for
distribution.
An extremely simple scheme is that, 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,
encrypted with A's public key.
Cont..
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. 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.
Simple Secret Key Distribution
Merkle proposed this very simple scheme
– allows secure communications
– no keys before/after exist
Man-in-the-Middle Attack
this very simple scheme is vulnerable to
an active man-in-the-middle attack
Cont..
In this case, if an adversary, E, has control of the
intervening communication channel, then E can
compromise the communication in the following
fashion without being detected:
1. A generates a public/private key pair {PUa, PRa} and
transmits a message intended for B consisting of PUa
and an identifier of A, IDA.
2. E intercepts the message, creates its own public/private
key pair {PUe, PRe} and transmits PUe || IDA to B.
3. B generates a secret key, Ks, and transmits E(PUe, Ks).
16
4. E intercepts the message and learns Ks by
computing D(PRe, E(PUe, Ks)).
5. E transmits E(PUa, Ks) to A.
The result is that both A and B know Ks and
are unaware that Ks has also been revealed
to E.
A and B can now exchange messages using
Ks. E no longer actively interferes with the
communications channel but simply
eavesdrops.
17
Cont..
Knowing Ks, E can decrypt all messages,
and both A and B are unaware of the
problem. Thus, this simple protocol is only
useful in an environment where the only
threat is eavesdropping.
18
Secret Key Distribution with
Confidentiality and Authentication
Secret Key Distribution with Confidentiality
and Authentication
1. A uses B's public key to encrypt a message to B
containing an identifier of A (IA) and a nonce (N1),
which is used to identify this transaction uniquely.
2. 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 (1), the presence of N1 in
message (2) assures A that the correspondent is
B.
3. A returns N2, encrypted using B's public key, to
assure B that its correspondent is A.
20
Cont..
4. A selects a secret key Ks and sends M =
E(PUb, E(PRa, Ks)) to B. Encryption with B's
public key ensures that only B can read it;
encryption with A's private key ensures that
only A could have sent it.
5. B computes D(PUa, D(PRb, M)) to recover
the secret key.
The result is that this scheme ensures both
confidentiality and authentication in the
exchange of a secret key.
21
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 (public key is slow)
backward compatibility(can work in the existing
system with little modification)
Distribution of Public Keys
Can be considered as using one of:
public announcement
publicly available directory
public-key authority
public-key certificates
Public Announcement
users distribute public keys to recipients or
broadcast to community at large
E.g. append PGP keys to:-
email messages
post to news groups
email list
major weakness is forgery
Anyone can forge such a public announcement (any one
can create a key claiming to be someone else and
broadcast it)
until forgery is discovered can masquerade as claimed
user
Publicly Available Directory
can obtain greater security by registering keys
with a public directory
Maintenance and distribution of the public
directory would have to be the responsibility of
some trusted entity or organization
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
Improve security by tightening control
over distribution of keys from directory
has properties of directory and requires
users to know public key of the authority
then users interact with directory to obtain
any desired public key securely
does require real-time access to directory
when keys are needed
may be vulnerable to tampering
Public-Key Authority
Public key Certificates
~~~~
Before two parties exchange data using ~~~~
~~~~
Public Key cryptography, each wants to be Digital
Signature
sure that the other party is authenticated
Before B accepts a message with A’s Digital
Signature, B wants to be sure that the public key
belongs to A and not to someone masquerading as
A on an open network
One way to be sure, is to use a trusted third party to
authenticate that the public key belongs to A. Such
a party is known as a Certification Authority (CA)
Once A has provided proof of identity, the
Certification Authority creates a message
containing A’s name and public key. This message
is known as a Digital Certificate.
Public-Key Certificates
Digital 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 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 (CA)
– 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
Certificate Life Cycle
Key pair generated
Certificate issued
Key pair in use Private key
New key
compromised
Re-certify pair
generated
Certificate expires
Certificate
revoked
Key pair lifetime exceeded?
Obtaining a Certificate
any user with access to CA can get any
certificate from it
only the CA can modify a certificate
because the certificate cannot be forged,
certificates can be placed in a public
directory
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
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
PKI Players
Registration Authority (RA) to identity
proof users
Certification Authorities (CA) to issue
certificates and CRL’s
Repositories (publicly available databases)
to hold certificates and CRLs
Certification Authority (CA)
Certification Authority What’s Important
Trusted (Third) Party Operational Experience
Enrolls and Validates High Assurance Security
Subscribers Architecture
Issues and Manages Scalability
Certificates
Flexibility
Manages Revocation and
Renewal of Certificates
Interoperability
Establishes Policies & Trustworthiness
Procedures
Certification Authority = Basis of Trust
Registration Authority (RA)
Enrolling, de-enrolling, and approving or rejecting
requested changes to the certificate attributes of
subscribers.
Validating certificate applications.
Authorizing requests for key-pair or certificate
generation and requests for the recovery of
backed-up keys.
Accepting and authorizing requests for certificate
revocation or suspension.
Physically distributing personal tokens to and
recovering obsolete tokens from people authorized
to hold and use them.
Certificate Policy (CP) is …
the basis for trust between unrelated
entities
not a formal “contract” (but implied)
a framework that both informs and
constrains a PKI implementation
a statement of what a certificate means
a set of rules for certificate holders
a way of giving advice to Relying Parties