Key Management

.
15.1 SYMMETRIC-KEY DISTRIBUTION

Symmetric-key cryptography is more efficient than asymmetric-key

cryptography for enciphering large messages.

Symmetric-key cryptography, however, needs a shared secret key between

two parties.

If Alice needs to exchange confidential messages with N people, she needs N

different keys. What if N people need to communicate with each other?

A total of N(N − 1)/2 keys are needed if we allow a key to be used for both
directions.

.
 15.1 SYMMETRIC-KEY DISTRIBUTION

The number of keys is not the only problem;

the distribution of keys is another.

if Alice wants to communicate with one million people, how can she exchange one
million keys with one million people?

Need an efficient way to maintain and distribute secret keys.

.
Key-Distribution Center: KDC
To reduce the number of keys, each person establishes a shared secret key
with the KDC

.
 Key-Distribution Center: KDC

• A secret key is established between the KDC and each member.

• Alice has a secret key with the KDC, which we refer to as K Alice;

• Bob has a secret key with the KDC, which we refer to as K Bob; and so on.

• How Alice can send a confidential message to Bob.

.
 Key-Distribution Center: KDC

The process is as follows:

1. Alice sends a request to the KDC stating that she needs a session (temporary)
secret key between herself and Bob.
2. The KDC informs Bob about Alice’s request.
3. If Bob agrees, a session key is created between the two.

Secret key between Alice and Bob that is established with the KDC is used to authenticate Alice and
Bob to the KDC and to prevent Eve from impersonating either of them.

.
 Flat Multiple KDCs

When the number of people using a KDC increases, the system becomes
unmanageable and a bottleneck can result.

To solve the problem, we need to have multiple KDCs.

We can divide the world into domains.

Each domain can have one or more KDCs (for redundancy in case of failure).

If Alice wants to send a message to Bob, who belongs to another domain,

Alice contacts her KDC, which in turn contacts the KDC in Bob’s domain.

The two KDCs can create a secret key between Alice and Bob.

.
 Flat Multiple KDCs

Figure 15.2 shows KDCs all at the same level. We call this flat multiple KDCs.

.
 Hierarchical Multiple KDCs

There can be local KDCs, national KDCs, and international KDCs.

• When Alice needs to communicate with Bob, who lives in another country, she sends her
request to a local KDC;
• the local KDC relays the request to the national KDC;
• the national KDC relays the request to an international KDC.
The request is then relayed all the way down to the local KDC where Bob lives .

.
Session Keys
A KDC creates a secret key for each member.

This secret key can be used only between the member and the KDC, not
between two members.

A KDC can create a session key between Alice and Bob, using their keys with
the center.

The keys of Alice and Bob are used to authenticate Alice and Bob to the
center and to each other before the session key is established.

After communication is terminated, the session key is no longer useful.

.
Session Keys

Several different approaches have been proposed to create the session key using ideas
discussed in Chapter 14 for entity authentication.

.
A Simple Protocol Using a KDC

Creating a session key KAB between Alice and Bob.

.
 A Simple Protocol Using a KDC

1. Alice sends a plaintext message to the KDC to obtain a symmetric session key between Bob and
herself. The message contains her registered identity and the identity of Bob.

.
 A Simple Protocol Using a KDC

2. KDC receives the message and creates a ticket. Ticket is encrypted using Bob’s key (K B).
• Ticket contains the identities of Alice and Bob and the session key (K AB).
• Ticket with a copy of the session key is sent to Alice.
• Alice receives the message, decrypts it, and extracts the session key.
• In the second message, Alice is actually authenticated to the KDC, because only Alice can open
the whole message using her secret key with KDC.

.
 A Simple Protocol Using a KDC

3. Alice sends the ticket to Bob. Bob opens the ticket and knows that Alice needs to send messages
to him using KAB as the session key.
• In this message, Bob is authenticated to the KDC because only Bob can open the ticket.
• Because Bob is authenticated to the KDC, he is also authenticated to Alice, who trusts the KDC.
• In the same way, Alice is also authenticated to Bob, because Bob trusts the KDC and the KDC
has sent Bob the ticket that includes the identity of Alice.

Unfortunately, this simple protocol has a flaw. Eve can use the replay attack. That is, she can
save the message in step 3 and replay it later.

.
Needham-Schroeder Protocol

Foundation for many other protocols.

Uses multiple challenge-response interactions between parties to achieve a

flawless protocol.

Uses two nonces: RA and RB.

.
 Needham-Schroeder Protocol

1. Alice sends a message to the KDC that includes nonce, R A, her identity, and Bob’s identity.

2. KDC sends an encrypted message to Alice that includes Alice’s nonce, Bob’s identity, the session key,
and an encrypted ticket for Bob. Whole message is encrypted with Alice’s key.
.
 Needham-Schroeder Protocol

3. Alice sends Bob’s ticket to him.

4. Bob sends his challenge to Alice (RB), encrypted with the session key.
5. Alice responds to Bob’s challenge. Note that the response carries R B− 1 instead of RB.

.
Otway-Rees Protocol

.
 Otway-Rees Protocol

1. Alice sends a message to Bob that includes a common nonce, R, identities of Alice and Bob, and a
ticket for KDC that includes Alice’s nonce R A (challenge for KDC to use), a copy of the common nonce,
R, and the identities of Alice and Bob.

2. Bob creates the same type of ticket, but with his own nonce RB. Both tickets are sent to the KDC.

.
 Otway-Rees Protocol

3. KDC creates a message that contains R, a ticket for Alice and a ticket for Bob; Message is sent to Bob.
Tickets contain the corresponding nonce, R A or RB, and the session key, KAB.
4. Bob sends Alice her ticket.
5. Alice sends a short message encrypted with her session key K AB to show that she has the session key.

.
 15.2 KERBEROS

Kerberos is an authentication protocol, and at the same time a KDC, that has
become very popular.

Several systems, including Windows 2000, use Kerberos.

Named after the 3-headed dog in Greek mythology that guards the gates of Hades.

Originally designed at MIT, it has gone through several versions.

Here discuss version 4, the most popular, and briefly explain the difference between
version 4 and version 5 (the latest).

.
 15.2 KERBEROS

Servers

Three servers are involved in the Kerberos protocol:

 an authentication server (AS),
 a ticket-granting server (TGS), and
 a real (data) server that provides services to others.

In our examples, Bob is the real server and Alice is the user requesting service.

.
15.2 KERBEROS
Servers

Figure 15.7 shows the relationship between these three servers.

.
 15.2 KERBEROS

Authentication Server (AS)

• Each user registers with the AS and is granted a user identity and a password.
• AS has a database with these identities and the corresponding passwords.
• AS verifies the user, issues a session key to be used between Alice and the TGS, and
sends a ticket for the TGS.

.
 15.2 KERBEROS

Ticket-Granting Server (TGS)

• Ticket-granting server (TGS) issues a ticket for the real server (Bob).
• It also provides the session key (KAB) between Alice and Bob.
• Kerberos has separated user verification from the issuing of tickets.
• In this way, though Alice verifies her ID just once with the AS, she can contact the TGS
multiple times to obtain tickets for different real servers.
.
15.2 KERBEROS
Operation : A client process (Alice) can access a process running on the real server (Bob)
in 6 steps.

1. Alice sends her request to

the AS in plain text using
her registered identity.

.
2. The AS sends a message encrypted with Alice’s
permanent symmetric key, KA-AS.

Message contains 2 items: a session key, KA-TGS,

that is used by Alice to contact the TGS, and a ticket
for the TGS that is encrypted with the TGS
symmetric key, KAS-TGS.

Alice does not know KA-AS, but when the message

arrives, she types her symmetric password. The
password and the appropriate algorithm together
create KA-AS if the password is correct. The password
is then immediately destroyed; it is not sent to the
network and it does not stay in the terminal. It is
used only for a moment to create K A-AS.

Process now uses KA-AS to decrypt the message

sent. KA-TGS and the ticket are extracted.

.
 15.2 KERBEROS

3. Alice now sends 3 items to the TGS.

First is the ticket received from the AS.

Second is the name of the real server (Bob),

Third is a timestamp that is encrypted by K A-TGS.

The timestamp prevents a replay by Eve.

.
 15.2 KERBEROS
4. TGS sends 2 tickets, each containing the
session key between Alice and Bob, KA-B.

Ticket for Alice is encrypted with K A-TGS; ticket

for Bob is encrypted with Bob’s key, K TGS-B.

Note that Eve cannot extract KAB because Eve does

not know KA-TGS or KTGS-B.

She cannot replay step 3 because she cannot

replace the timestamp with a new one (she does not
know KA-TGS).

Even if she is very quick and sends the step 3

message before the timestamp has expired, she still
receives the same two tickets that she cannot
decipher.

.
 15.2 KERBEROS
5. Alice sends Bob’s ticket with the
timestamp encrypted by KA-B.

6. Bob confirms the receipt by

adding 1 to the timestamp. The
message is encrypted with KA-B
and sent to Alice.

.
 15.2 KERBEROS
Using Different Servers

If Alice needs to receive services from different servers, she need repeat only the
last 4 steps.

The first two steps have verified Alice’s identity and need not be repeated.

Alice can ask TGS to issue tickets for multiple servers by repeating steps 3 to 6.

.
15.2 KERBEROS
Kerberos Version 5

The minor differences between version 4 and version 5 are:

1. Version 5 has a longer ticket lifetime.
2. Version 5 allows tickets to be renewed.
3. Version 5 can accept any symmetric-key algorithm.
4. Version 5 uses a different protocol for describing data types.
5. Version 5 has more overhead than version 4.

.
15.2 KERBEROS
Realms

 Kerberos allows the global distribution of ASs and TGSs, with each system called a
realm.

 A user may get a ticket for a local server or a remote server.

 In the second case, for example, Alice may ask her local TGS to issue a ticket that is
accepted by a remote TGS.

 The local TGS can issue this ticket if the remote TGS is registered with the local one.

 Then Alice can use the remote TGS to access the remote real server.

.
15.4 PUBLIC-KEY DISTRIBUTION

In asymmetric-key cryptography, people do not need to know a symmetric

shared key.

If Alice wants to send a message to Bob, she only needs to know Bob’s public
key, which is open to the public and available to everyone.

In public-key cryptography, everyone shields a private key and advertises a

public key.

.
15.4 PUBLIC-KEY DISTRIBUTION

Public keys, like secret keys, need to be distributed to be useful.

Discuss the way public keys can be distributed.

.
15.4 PUBLIC-KEY DISTRIBUTION

Public Announcement

The naive approach is to announce public keys publicly.

Bob can put his public key on his website or announce it in a local or
national newspaper.

When Alice needs to send a confidential message to Bob, she can obtain
Bob’s public key from his site or from the newspaper, or even send a
message to ask for it.

.
 15.4 PUBLIC-KEY DISTRIBUTION

Public Announcement

This approach, however, is not secure; it is subject to forgery.

Eve could make such a public announcement.
Before Bob can react, damage could be done.
Eve can fool Alice into sending her a message that is intended for Bob.
Eve could also sign a document with a corresponding forged private key and make everyone believe it
was signed by Bob.

.
15.4 PUBLIC-KEY DISTRIBUTION
Trusted Center
• A more secure approach is to have a trusted center retain a directory of public keys.
• The directory, like the one used in a telephone system, is dynamically updated.
• Each user can select a private and public key, keep the private key, and deliver the
public key for insertion into the directory.
• The center requires that each user register in the center and prove his or her identity.
• The directory can be publicly advertised by the trusted center.
• The center can also respond to any inquiry about a public key.

.
15.4 PUBLIC-KEY DISTRIBUTION
Controlled Trusted Center
• A higher level of security can be achieved if there are added controls on the
distribution of the public key.
• The public-key announcements can include a timestamp and be signed by an authority
to prevent interception and modification of the response.
• If Alice needs to know Bob’s public key, she can send a request to the center including
Bob’s name and a timestamp.
• The center responds with Bob’s public key, the original request, and the timestamp
signed with the private key of the center.
• Alice uses the public key of the center, known by all, to verify the timestamp.
• If the timestamp is verified, she extracts Bob’s public key.

.
15.4 PUBLIC-KEY DISTRIBUTION
Certification Authority
• Previous approach can create a heavy load on the center if the number of
requests is large.

• The alternative is to create public-key certificates.

Bob wants two things:

• he wants people to know his public key
• he wants no one to accept a forged public key as his.

.
15.4 PUBLIC-KEY DISTRIBUTION
Certification Authority

• Bob can go to a certification authority (CA), a federal or state organization that binds a
public key to an entity and issues a certificate.

• The CA has a well-known public key itself that cannot be forged.

• The CA checks Bob’s identification (using a picture ID along with other proof). It then
asks for Bob’s public key and writes it on the certificate.

• To prevent the certificate itself from being forged, the CA signs the certificate with its
private key. Now Bob can upload the signed certificate.

• Anyone who wants Bob’s public key downloads the signed certificate and uses the
center’s public key to extract Bob’s public key.

.
15.4 PUBLIC-KEY DISTRIBUTION
Certification Authority

.
15.4 PUBLIC-KEY DISTRIBUTION
X.509
• Although the use of a CA has solved the problem of public-key fraud, it has
created a side-effect.

• Each certificate may have a different format.

 If Alice wants to use a program to automatically download different certificates and
digests belonging to different people, the program may not be able to do this.
 One certificate may have the public key in one format and another in a different
format.
 The public key may be on the first line in one certificate, and on the third line in
another.
 Anything that needs to be used universally must have a universal format .

.
15.4 PUBLIC-KEY DISTRIBUTION
X.509

• To remove this side effect, the ITU has designed X.509, a recommendation
that has been accepted by the Internet with some changes.

• X.509 is a way to describe the certificate in a structured way.

It uses a well-known protocol called ASN.1 (Abstract Syntax Notation 1) that defines fields familiar to C
programmers.

.
15.4 PUBLIC-KEY DISTRIBUTION
X.509 Certificate : Figure shows the format of a certificate

.
 15.4 PUBLIC-KEY DISTRIBUTION
X.509 Certificate : Figure shows the format of a certificate

Version number. This field defines the version of X.509 of the certificate. The version number started at 0;
the current version (third version) is 2.

Serial number. Defines a number assigned to each certificate. Unique for each certificate issuer.

Signature algorithm ID. This field identifies the algorithm used to sign the certificate. Any parameter that
is needed for the signature is also defined in this field.

.
 15.4 PUBLIC-KEY DISTRIBUTION
X.509 Certificate : A certificate has the following fields

Issuer name. Identifies the certification authority that issued the certificate. The name is normally a
hierarchy of strings that defines a country, a state, organization, department, and so on.

Validity Period. Defines the earliest time (not before) and the latest time (not after) the certificate is
valid.

Subject name. Defines the entity to which the public key belongs. It is also a hierarchy of strings.
.
 15.4 PUBLIC-KEY DISTRIBUTION

Subject public key. This field defines the owner’s public key, the heart of the certificate.
The field also defines the corresponding public-key algorithm (RSA, for example) and its parameters.

Issuer unique identifier. This optional field allows two issuers to have the same issuer field value, if
the issuer unique identifiers are different.

Subject unique identifier. This optional field allows two different subjects to have the same subject
field value, if the subject unique identifiers are different.

.
15.4 PUBLIC-KEY DISTRIBUTION

Extensions. This optional field allows issuers to add more private information to the certificate.

Signature. This field is made of three sections.

• The first section contains all other fields in the certificate.
• The second section contains the digest of the first section encrypted with the CA’s public key.
• The third section contains the algorithm identifier used to create the second section.

.
 15.4 PUBLIC-KEY DISTRIBUTION

Certificate Renewal
• Each certificate has a period of validity.

• If there is no problem with the certificate, the CA issues a new certificate before
the old one expires.

.
 15.4 PUBLIC-KEY DISTRIBUTION

Certificate Revocation
In some cases a certificate must be revoked before its expiration. Here are some
examples:
a. The user’s (subject’s) private might have been comprised.
b. The CA is no longer willing to certify the user. For example, the user’s certificate
relates to an organization that she no longer works for.
c. The CA’s private key, which can verify certificates, may have been compromised.
In this case, the CA needs to revoke all unexpired certificates.

.
 15.4 PUBLIC-KEY DISTRIBUTION

Certificate Revocation
The revocation is done by periodically issuing a certificate revocation list (CRL).
The list contains all revoked certificates that are not expired.
When a user wants to use a certificate, she first needs to check the directory of the
corresponding CA for the last certificate revocation list.

.
 15.4 PUBLIC-KEY DISTRIBUTION
Certificate Revocation

A certificate revocation list has the following fields:

Signature algorithm ID. This field is the same as the one in the certificate.
Issuer name. This field is the same as the one in the certificate.
This update date. This field defines when the list is released.
Next update date. This field defines the next date when the new list will be released
Revoked certificate. This is a repeated list of all unexpired certificates that have been revoked. Each
list contains two sections: user certificate serial number and revocation date.
Signature. This field is the same as the one in the certificate list.

.
15.4 PUBLIC-KEY DISTRIBUTION

Delta Revocation
To make revocation more efficient, the delta certificate revocation list (delta CRL)
has been introduced.
A delta CRL is created and posted on the directory if there are changes after
this update date and next update date.
For example, if CRLs are issued every month, but there are revocations in
between, the CA can create a delta CRL when there is a change during the
month.
However, a delta CRL contains only the changes made after the last CRL.

.
15.4 PUBLIC-KEY DISTRIBUTION

Public-Key Infrastructures (PKI)

Public-Key Infrastructure (PKI) is a model for creating, distributing, and revoking

certificates based on the X.509.

Internet Engineering Task Force has created the Public-Key Infrastructure X.509 (PKIX).

Duties
Several duties have been defined for a PKI.
The most important ones are.

.
 15.4 PUBLIC-KEY DISTRIBUTION

Public-Key Infrastructures (PKI)

Certificates’ issuing, renewal, and revocation.

Keys’ storage and update. Storage place for private keys of those members that need to hold their private
keys somewhere safe. In addition, a PKI is responsible for updating these keys on members’ demands.

Providing services to other protocols. Some Internet security protocols, such as IPSec and TLS, are
relying on the services by a PKI.

Providing access control. A PKI can provide different levels of access to the information stored in its
database. For example, an organization PKI may provide access to the whole database for the top
management, but limited access for employees

.
15.4 PUBLIC-KEY DISTRIBUTION

Trust Model
• It is not possible to have just one CA issuing all certificates for all users in the
world.
• There should be many CAs, each responsible for creating, storing, issuing,
and revoking a limited number of certificates.
• The trust model defines rules that specify how a user can verify a certificate
received from a CA.

Hierarchical Model
• In this model, there is a tree-type structure with a root CA.
• The root CA has a self-signed, self-issued certificate; it needs to be trusted by other
CAs and users for the system to work.

.
15.4 PUBLIC-KEY DISTRIBUTION

• Figure 15.20 shows a trust model.

• The number of levels can be more than three in a real situation.

• The CA (the root) has signed certificates for CA1, CA2, and CA3;
• CA1 has signed certificates for User1, User2, and User3; and so on.
• PKI uses the following notation to mean the certificate issued by authority X for entity Y.

.
15.4 PUBLIC-KEY DISTRIBUTION
Example : Show how User1, knowing only the public key of the CA (the root), can obtain a
verified copy of User3’s public key.

Solution
User3 sends a chain of certificates, CA<<CA1>> and CA1<<User3>>, to User1.
a. User1 validates CA<<CA1>> using the public key of CA.
b. User1 extracts the public key of CA1 from CA<<CA1>>.
c. User1 validates CA1<<User3>> using the public key of CA1.
d. User1 extracts the public key of User 3 from CA1<<User3>>.

.
15.4 PUBLIC-KEY DISTRIBUTION

Mesh Model
The hierarchical model may work for an organization or a small community.

A larger community may need several hierarchical structures connected together.

One method is to use a mesh model to connect the roots together.

In this model, each root is connected to every other root, as shown in Figure 15.21.

.
15.4 PUBLIC-KEY DISTRIBUTION

Mesh Model
Mesh structure connects only roots together; each root has its own hierarchical structure,
shown by a triangle.

The certifications between the roots are cross-certificates; each root certifies all other roots,
which means there are N (N − 1) certificates.

In Figure 15.21, there are 4 nodes, so we need 4 × 3 = 12 certificates.

Note that each double-arrow line represents two certificates.

.
END