IS unit 3 part 2

1. SYMMETRIC KEY DISTRIBUTION

Introduction:
- Symmetric-key cryptography is e2icient but requires a shared secret key.
- For N people to communicate securely, N(N-1) keys are needed for
bidirectional communication.
- If each person needs to communicate with all others, almost N² keys are
required.(N2 problem)
- Distributing keys securely is challenging, especially for large groups.
- Current methods for key distribution, like exchanging keys over the
internet, are not secure enough.
- E2icient solutions for maintaining and distributing secret keys are
needed.

KDC (Key-Distribution Center):

- A practical solution for key distribution is a Key-Distribution Center (KDC).

- To reduce the number of keys,each participant establishes a shared
secret key with the KDC.
- For example, Alice has a secret key (KAlice) with the KDC, and Bob has a
secret key (KBob) with the KDC.
- To send a confidential message to Bob, Alice requests a session key
(temporary) between herself and Bob from the KDC.
- The KDC informs Bob about Alice's request.
- If Bob agrees, a session key is created between Alice and Bob.
- This session key is used to authenticate Alice and Bob to the KDC and
prevent impersonation by Eve.
Flat Multiple KDCs:

- As the number of users increases, managing them with a single Key-

Distribution Center (KDC) becomes challenging and can lead to
bottlenecks.
- To address this, multiple KDCs can be deployed across di2erent domains.
- Domains are geographical or logical divisions where each can have one or
more KDCs for redundancy.
- When a user from one domain needs to communicate securely with a
user from another domain, their respective KDCs facilitate the key
exchange process.
- This approach, called flat multiple KDCs, involves KDCs at the same level
across domains.

Hierarchical Multiple KDCs:

- The concept of multiple Key-Distribution Centers (KDCs) can be extended

to a hierarchical system.
- In a hierarchical system, there are KDCs at di2erent levels, such as local,
national, and international.
 - When a user, like Alice, needs to communicate with someone in another
country, like Bob, she sends her request to her local KDC.
- The local KDC then relays the request to the national KDC, which further
relays it to the international KDC.
- Finally, the request is relayed down to the local KDC where Bob resides,
and the necessary session key is established.
- This configuration of hierarchical multiple KDCs provides a scalable and
e2icient way to manage key distribution across di2erent levels of
organization or geographical regions.

Session Keys:
- A Key-Distribution Center (KDC) generates a secret key for each member,
usable only between the member and the KDC, not between members.
- When Alice needs to communicate securely with Bob, she requires a
secret key specifically between herself and Bob.
- The KDC facilitates this by creating a session key between Alice and Bob,
utilizing their respective keys with the center.
- The keys of Alice and Bob serve to authenticate them both to the KDC and
to each other before the session key is established.
- Once the communication session ends, the session key becomes
obsolete and is no longer useful.

Protocols for generating session keys:

a.) A Simple Protocol Using a KDC:
Steps:

1. Alice Requests Session Key: Alice sends a plaintext message to the KDC
requesting a symmetric session key for communication with Bob. The message
includes her identity (Alice) and Bob's identity (Bob). This message is public and
unencrypted.

2. KDC Generates Ticket: The KDC receives Alice's message and creates a
"ticket." This ticket is encrypted using Bob's secret key (KB) and contains the
identities of both Alice and Bob, along with the session key (KAB). The encrypted
ticket is sent to Alice. Alice decrypts the ticket using her secret key with the KDC,
extracting the session key. However, she cannot decrypt Bob's ticket portion as it
is encrypted with Bob's key.

3. Alice Sends Ticket to Bob: Alice sends the ticket to Bob. Bob decrypts the
ticket using his secret key with the KDC, obtaining the session key (KAB). Now
both Alice and Bob possess the session key for secure communication.

4. Authentication and Trust: Through this process, both Alice and Bob are
authenticated to the KDC. Alice trusts the KDC, so she trusts that the ticket sent
by Bob is genuine. Similarly, Bob trusts the KDC, so he trusts that the ticket
received from Alice is authentic.

However, this protocol has a flaw: it is vulnerable to a replay attack by Eve. Eve
can intercept and save the ticket exchanged between Alice and Bob, then replay
it later to gain unauthorized access to their communication.
b.) Needham-Schroeder Protocol:

Steps:

1. Alice Requests Session: Alice sends a message to the KDC containing her
nonce (RA), her identity, and Bob's identity.
2. KDC Responds: The KDC sends an encrypted message to Alice including her
nonce, Bob's identity, the session key, and an encrypted ticket for Bob.
3. Alice Sends Ticket to Bob: Alice forwards Bob's ticket to him.
4. Bob Challenges Alice: Bob sends his challenge (RB) to Alice, encrypted with
the session key.
5. Alice Responds to Challenge: Alice responds to Bob's challenge with RB - 1
instead of RB.
c.) Otway-Rees Protocol:

Steps:

1. Alice Initiates Communication: Alice sends a message to Bob including a

common nonce (R), their identities, and a ticket for the KDC containing Alice's
nonce (RA).
2. Bob Sends Ticket to KDC: Bob creates a similar ticket with his nonce (RB) and
sends it to the KDC along with Alice's ticket.
3. KDC Facilitates Key Exchange: The KDC combines the nonces and creates a
message containing the common nonce, tickets for Alice and Bob, and sends it
to Bob.
4. Bob Sends Alice Her Ticket: Bob forwards Alice's ticket to her.
5. Alice Confirms Key Possession: Alice sends a message encrypted with the
session key (KAB) to demonstrate possession of the key.
2. KERBEROS:
Kerberos is an authentication protocol, and at the same time a KDC, that has
become very popular.

Servers:
Here's an overview of the three servers involved in the Kerberos protocol:

1. Authentication Server (AS):

- The AS serves as the Key Distribution Center (KDC) in Kerberos.
- Users register with the AS and are assigned a user identity and password.
- The AS maintains a database of user identities and corresponding
passwords.
- It verifies users and issues session keys for communication between
users and the Ticket-Granting Server (TGS).
- The AS also provides a ticket for the TGS.

2. Ticket-Granting Server (TGS):

- The TGS issues tickets for real servers, like Bob, and provides session keys
between users (like Alice) and real servers.
- Separating user verification from ticket issuance allows users to contact
the TGS multiple times for tickets to di2erent real servers.
- Upon receiving a valid ticket from the AS, the TGS issues a ticket for the
requested real server and provides the session key.

3. Real Server (Bob):

- The real server, such as Bob, hosts services that users, like Alice, request.
- Kerberos is designed for client-server programs, like FTP, where users
access server processes using client processes.
- Kerberos is not typically used for person-to-person authentication but
rather for user-server authentication in client-server interactions.
Operation:

Here's a concise breakdown of the six steps involved in Alice (client process)
accessing a process running on the real server (Bob) in the Kerberos protocol:

1. Alice Sends Request to AS:

- Alice sends her request to the Authentication Server (AS) using her
registered identity.

2. AS Response:
- The AS responds with a message encrypted with Alice's permanent
symmetric key (KA-AS), containing a session key (KA-TGS) for Alice to
contact the Ticket-Granting Server (TGS), and a ticket for the TGS
encrypted with the TGS symmetric key (KAS-TGS).
 3. Alice Sends Request to TGS:
- Alice sends the ticket received from the AS, along with the name of the
real server (Bob) and a timestamp encrypted by KA-TGS to the Ticket-
Granting Server (TGS).

4. TGS Response:
- The TGS sends two tickets:
- One containing the session key (KA-B) between Alice and Bob, encrypted
with KA-TGS.
- Another ticket containing the session key (KA-B) between Alice and Bob,
encrypted with Bob's key (KTGS-B).
- Eve cannot decipher KA-B because she doesn't know KA-TGS or KTGS-B,
and she cannot replay the process due to the timestamp encryption.

5. Alice Sends Bob's Ticket:

- Alice sends Bob's ticket along with the timestamp encrypted by KA-B to
Bob.

6. Bob's Response:
- Bob confirms receipt by adding 1 to the timestamp, encrypting the
message with KA-B, and sending it to Alice.

Using DiBerent Servers:

Note that if Alice needs to receive services from di2erent servers, she need repeat only
the last four 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.

Kerberos Version 5 :
The minor di2erences between version 4 and version 5 are briefly listed below:

• Version 5 has a longer ticket lifetime.

• Version 5 allows tickets to be renewed.
• Version 5 can accept any symmetric-key algorithm.
• Version 5 uses a di2erent protocol for describing data types.
• Version 5 has more overhead than version 4.
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.

3. Symmetric Key Arrangement:

• Alice and Bob can create a session key between themselves without using a
KDC. This method of session-key creation is referred to as the symmetric-key
agreement.

A. DiBie-Hellman Key Agreement:

• In the Diffie-Hellman protocol two parties create a symmetric session key

without the need of a KDC.
• Before establishing a symmetric key, the two parties need to choose two
numbers p and g. The first number, p, is a large prime number on the order of
300 decimal digits (1024 bits).
• The second number, g, is a generator of order p − 1 in the group <Zp*, ×>.
• These two (group and generator) do not need to be confidential. They can be
sent through the Internet; they can be public. P
The steps are as follows:
1.) Alice chooses a large random number x such that 0 ≤ x ≤ p − 1 and
calculates R1 = gx mod p.
2.) Bob chooses another large random number y such that 0 ≤ y ≤ p − 1 and
calculates R2 = gy mod p.
3.) Alice sends R1 to Bob. Note that Alice does not send the value of x; she
sends only R1.
4.) Bob sends R2 to Alice. Again, note that Bob does not send the value of y,
he sends only R2.
5.) Alice calculates K = (R2)x mod p.
6.) Bob also calculates K = (R1)y mod p.
K is the symmetric key for the session.

Bob has calculated K = (R1)y mod p = (gx mod p)y mod p = gxy mod p. Alice
has calculated K = (R2)x mod p = (gy mod p)x mod = gxy mod p. Both have
reached the same value without Bob knowing the value of x and without Alice
knowing the value of y.

Analysis of DiBie -Hellman key Agreement:

 - The secret key between Alice and Bob can be conceptualized as
composed of three parts: g , x , and y .
- The first part, g , is public knowledge, known by everyone, representing
1/3 of the key.
- Each party contributes one part of the key: Alice adds x for Bob, and Bob
adds y for Alice, completing 2/3 of the key.
- When Alice receives Bob's contribution, she combines it with her own x
to complete the key. Similarly, Bob combines Alice's contribution y with
his own to complete the key, resulting in a full 3/3, or the entire, key.
- Although the keys in Alice's and Bob's possession appear to have di2erent
orderings of the parts (Alice: gyx and Bob: gxy,they are mathematically
equivalent due to the commutative property: gxy=gyx.
- Despite the keys being the same, Alice cannot determine the exact value
of y used by Bob, as the calculation is done modulo p . Alice only receives
gy mod p from Bob, not gy. To find the value of y , Alice would need to solve
the discrete logarithm problem, which is computationally di2icult.

Security of DiSie-Hellman:

A)Discrete Logarithm Attack:

• The security of the key exchange is based on the difficulty of the discrete
logarithm problem.
• Eve can intercept R1 and R2. If she can find x from R1 = gx mod p and y from
R2 = gy mod p, then she can calculate the symmetric key K = gxy mod p. The
secret key is not secret anymore.
• To make Diffie-Hellman safe from the discrete logarithm attack, the following
are recommended:
o The prime p must be very large (more than 300 decimal digits).
o The prime p must be chosen such that p − 1 has at least one large
prime factor (more than 60 decimal digits).
o The generator must be chosen from the group <Zp*, × >.
o Bob and Alice must destroy x and y after they have calculated the
symmetric key. The values of x and y must be used only once.

B) Man-in-the-Middle Attack:
The protocol has another weakness. Eve does not have to find the value of x and
y to attack the protocol. She can fool Alice and Bob by creating two keys: one
between herself and Alice, and another between herself and Bob. situation.

The following can happen:

o Alice chooses x, calculates R1 = gx mod p, and sends R1 to Bob.

o Eve, the intruder, intercepts R1. She chooses z, calculates R2 = gz
mod p, and sends R2 to both Alice and Bob.
o Bob chooses y, calculates R3 = gy mod p, and sends R3 to Alice. R3
is intercepted by Eve and never reaches Alice.
o Alice and Eve calculate K1 = gxz mod p, which becomes a shared
key between Alice and Eve. Alice, however, thinks that it is a key
shared between Bob and herself.
o Eve and Bob calculate K2 = gzy mod p, which becomes a shared
key between Eve and Bob. Bob, however, thinks that it is a key
shared between Alice and himself.

In other words, two keys, instead of one, are created: one between Alice and Eve,
one between Eve and Bob. When Alice sends data to Bob encrypted with K1
(shared by Alice and Eve), it can be deciphered and read by Eve. Eve can send the
message to Bob encrypted by K2 (shared key between Eve and Bob); or she can
even change the message or send a totally new message. Bob is fooled into
believing that the message has come from Alice. A similar scenario can happen
to Alice in the other direction.
B. Station-to-Station Key Agreement:

The station-to-station protocol is a method based on Di2ie-Hellman. It uses

digital signatures with public-key certificates to establish a session key between
Alice and Bob, as shown in Figure 15.12.

The following shows the steps:

o After calculating R1, Alice sends R1 to Bob (steps 1 and 2 in Figure 15.12).
o After calculating R2 and the session key, Bob concatenates Alice’s ID, R1,
and R2. He then signs the result with his private key. Bob now sends R2,
the signature, and his own public-key certificate to Alice. The signature is
encrypted with the session key (steps 3, 4, and 5 in Figure 15.12).
o After calculating the session key, if Bob’s signature is verified, Alice
concatenates Bob’s ID, R1, and R2. She then signs the result with her own
private key and sends it to Bob. The signature is encrypted with the
session key (steps 6, 7, and 8 in Figure 15.12).
o If Alice’s signature is verified, Bob keeps the session key (step 9 in Figure
15.12).

Security of Station-to-Station Protocol

The station-to-station protocol prevents man-in-the-middle attacks. After

intercepting R1, Eve cannot send her own R2 to Alice and pretend it is coming
from Bob because Eve cannot forge the private key of Bob to create the signature
the signature cannot be verified with Bob’s public key defined in the certificate. In
the same way, Eve cannot forge Alice’s private key to sign the third message sent
 by Alice. The certificates, as we will see in the next section, are trusted because
they are issued by trusted authorities.

4. PUBLIC-KEY DISTRIBUTION
In public-key cryptography, everyone has access to everyone’s public key; public
keys are available to the public.
Public keys, like secret keys, need to be distributed to be useful.

DiSerent way to distribute public keys:

• Public Announcement:

The naive approach to public key distribution involves publicly announcing

public keys, such as Bob posting his public key on his website or in a newspaper.
However, this method is inherently insecure and susceptible to forgery:

• Forgery Vulnerability:
o Eve could maliciously announce her own public key as Bob's,
potentially fooling Alice into sending confidential messages to Eve
instead of Bob.
o Eve could also forge documents by signing them with a
corresponding forged private key, leading others to believe they
were signed by Bob.

• Interception and Substitution:

o If Alice directly requests Bob's public key, Eve could intercept
Bob's response and substitute her own forged public key for Bob's
legitimate public key.
• Trusted Center:

o A more secure approach is to have a trusted center retain a directory of

public keys.
o 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.
o The center requires that each user register in the center and prove his or
her identity.
o The directory can be publicly advertised by the trusted center. The center
can also respond to any inquiry about a public key.

• Controlled Trusted Center:

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

• Certification Authority:

o The previous approach can create a heavy load on the center if the
number of requests is large.
o The alternative is to create public-key certificates. Bob wants two things;
he wants people to know his public key, and he wants no one to accept a
forged public key as his.
o 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.
o 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.
o To prevent the certificate itself from being forged, the CA signs the
certificate with its private key. Now Bob can upload the signed certificate.
o Anyone who wants Bob’s public key downloads the signed certificate and
uses the center’s public key to extract Bob’s public key.
• X.509:

§ Side-ESect of CA:
o The use of CAs resolves the issue of public-key fraud but
introduces a new problem: the inconsistency in certificate
formats.
o Di2erent CAs may issue certificates with varying formats, making it
challenging for users like Alice to programmatically handle and
process them.
o Certificates may di2er in key placement, line arrangement, and
overall structure, complicating automated retrieval and
processing.

§ Solution - X.509:
o To address this issue, the International Telecommunication Union
(ITU) developed X.509, a recommendation adopted by the Internet
community with modifications.
o X.509 standardizes certificate formats, providing a structured
description of certificates.
o It utilizes ASN.1 (Abstract Syntax Notation 1), a protocol familiar to
C programmers, to define fields and organize certificate
information consistently.

§ By implementing X.509, the ITU aimed to establish a universal format for

certificates, streamlining their handling and ensuring compatibility across
di2erent systems and applications.

Certificate:
A certificate has the following fields:

§ 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. This field defines a number assigned to each certificate.
The value is 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.
§ Issuer name. This field 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. This field defines the earliest time (not before) and the
latest time (not after) the certificate is valid.
§ Subject name. This field defines the entity to which the public key
belongs. It is also a hierarchy of strings. Part of the field defines what is
called the common name, which is the actual name of the beholder of the
key.
§ 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 di2erent.
§ Subject unique identifier. This optional field allows two di2erent
subjects to have the same subject field value, if the subject unique
identifiers are di2erent.
§ 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.

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. The process is like the
renewal of credit cards by a credit card company; the credit card holder normally
receives a renewed credit card before the one expires.
Certificate Revocation:

In some cases a certificate must be revoked before its expiration. Here are some
examples:

a. The user’s (subject’s) private key (corresponding to the public key listed in the
certificate) 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.

The revocation is done by periodically issuing a certificate revocation list (CRL).

The list contains all revoked certificates that are not expired on the date the CRL
is issued. 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.

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

Delta Revocation :

To make revocation more e2icient, 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.

• Public-Key Infrastructures (PKI):

Public-Key Infrastructure (PKI) is a model for creating, distributing, and revoking
certificates based on the X.509. The Internet Engineering Task Force (see
Appendix B) has created the Public-Key Infrastructure X.509 (PKIX).

Duties:
Several duties have been defined for a PKI
o Certificates’ issuing, renewal, and revocation. These are duties defined
in the X.509. Because the PKIX is based on X.509, it needs to handle all
duties related to certificates.
o Keys’ storage and update. A PKI should be a 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.
o Providing services to other protocols. As we see will in the next few
chapters, some Internet security protocols, such as IPSec and TLS, are
relying on the services by a PKI.
o Providing access control. A PKI can provide di2erent 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.

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.

a.) 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. Figure 15.20 shows a trust model of this kind
with three hierarchical levels. The number of levels can be more than three in
a real situation.
The figure shows that 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:
X<<Y>>

b.) 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.
Figure 15.21 shows that the 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.