|| Jai Sri Gurudev ||

Sri Adichunchanagiri Shikshana Trust (R)

SJB INSTITUTE OF TECHNOLOGY

Reference Notes
Module 3
Subject Name: Cryptography & Network Security
Subject Code: BCS703
Faculty
Dr. Roopa M J, Associate Professor
Mrs. Shilpashree S, Assistant Professor

Semester: VII

Department of Computer Science & Engineering

Aca. Year: Odd Sem /2025-26
Cryptography and Network Security - BCS703​ ​ ​ ​ Module 3

​ ​ ​ ​ ​ Module 3

Cryptographic Hash Functions

A hash function H takes a variable-length block of data M as input and produces a fixed-size output
h=H(M), which is called a hash value or hash code. A "good" general hash function aims to produce
outputs that are evenly distributed and appear random when applied to a large set of inputs. Its primary
purpose is data integrity, meaning that even a small change to the input M should, with high probability,
result in a different hash value.

The specific kind of hash function required for security applications is called a cryptographic hash
function. This type of algorithm has properties that make it computationally infeasible (meaning no
attack is significantly more efficient than brute force) to achieve certain goals:

●​ (a) One-way property (Preimage Resistance): Given a hash result h, it is computationally

infeasible to find any input data object M such that H(M)=h.
●​ (b) Collision-free property (Collision Resistance): It is computationally infeasible to find two
different input data objects M1​and M2​such that H(M1​)=H(M2​).

These characteristics make cryptographic hash functions ideal for determining whether data has been
altered.

Figure 11.1 (Diagram of a Cryptographic Hash Function)

Department of CSE, SJBIT​ ​ ​ ​ ​ ​ ​ ​ ​ 94

Cryptography and Network Security - BCS703​ ​ ​ ​ Module 3

●​ Typically, the input message M is padded to become an integer multiple of a fixed block length
(e.g., 1024 bits).
●​ This padding usually includes the value of the original message's length in bits. This length field
is a crucial security measure that increases the difficulty for an attacker to create an alternative
message that produces the same hash value.

This chapter will first explore the diverse applications of cryptographic hash functions, then detail their
security requirements, examine how cipher block chaining can be used to implement them, and finally,
focus on the Secure Hash Algorithm (SHA) family, which is the most widely used.

3.1 APPLICATIONS OF CRYPTOGRAPHIC HASH FUNCTIONS

Cryptographic hash functions are highly versatile cryptographic algorithms used in a broad range of
security applications and Internet protocols. Understanding their various applications helps to grasp their
requirements and security implications.

Message Authentication

●​ Purpose: Message authentication is a mechanism or service designed to verify the integrity of a

message. It ensures that the received data is exactly as sent (i.e., no unauthorized modification,
insertion, deletion, or replay has occurred).
●​ Sender Identity: In many scenarios, the authentication mechanism also needs to confirm the
purported identity of the sender.
●​ Terminology: When a hash function is used for message authentication, the hash value is
frequently referred to as a message digest.
●​ Basic Principle:
1.​ The sender calculates a hash value h=H(M) for the message M.
2.​ The sender transmits both the message M and its hash value h.
3.​ The receiver independently performs the same hash calculation H(M′) on the received
message M′.
4.​ The receiver compares the newly computed hash value H(M′) with the received hash
value h. If they match, the message's integrity is verified.

Department of CSE, SJBIT​ ​ ​ ​ ​ ​ ​ ​ ​ 95

Cryptography and Network Security - BCS703​ ​ ​ ​ Module 3

Vulnerability without Protection: If a hash value is simply transmitted alongside the message without
protection, an adversary can easily perform a "man-in-the-middle" attack (Figure 11.2b). In this scenario,
Alice sends a message M and its hash H(M). Darth intercepts M, alters it to M′, calculates a new hash
H(M′), and replaces H(M) with H(M′). Bob receives M′ and H(M′), computes H(M′) himself, finds a
match, and remains unaware of the alteration.

●​ Necessity of Hash Value Protection: To prevent such attacks, the hash value must be protected
in a way that makes it infeasible for an adversary to alter it alongside the message.

Department of CSE, SJBIT​ ​ ​ ​ ​ ​ ​ ​ ​ 96

Cryptography and Network Security - BCS703​ ​ ​ ​ Module 3

Figure 11.3: Simplified Examples of the Use of a Hash Function for Message Authentication
illustrates several ways to protect the hash value and provide message authentication:

Department of CSE, SJBIT​ ​ ​ ​ ​ ​ ​ ​ ​ 97

Cryptography and Network Security - BCS703​ ​ ​ ​ Module 3

a. Encrypting Message + Hash (Symmetric Encryption):

○​ The message M is concatenated with its hash H(M) (M∣∣H(M)).

○​ The entire concatenated block is then encrypted using a symmetric secret key K shared
between sender (A) and receiver (B): E(K,[M∣∣H(M)]).
○​ Authentication: Only A and B share K, so only A could have generated this encrypted
block, ensuring authenticity. The hash provides integrity by detecting any alteration to M.
○​ Confidentiality: Since the entire message is encrypted, confidentiality is also provided.

b. Encrypting Only the Hash (Symmetric Encryption):

○​ Only the hash value H(M) is encrypted using a symmetric secret key K: E(K,H(M)).

Department of CSE, SJBIT​ ​ ​ ​ ​ ​ ​ ​ ​ 98

Cryptography and Network Security - BCS703​ ​ ​ ​ Module 3

○​ The message M is sent in plaintext alongside the encrypted hash.

○​ Benefit: Reduces computational burden for applications that do not require message
confidentiality.
○​ Authentication: Similar to (a), only A and B share K, ensuring A's authenticity. Integrity
is provided by comparing the decrypted hash.

c. Using a Shared Secret Value (No Encryption):

○​ The two communicating parties (A and B) share a common secret value S.

○​ Sender A computes the hash over the concatenation of the message and the secret:
H(M∣∣S).
○​ A appends this resulting hash value to M and sends M∣∣H(M∣∣S).
○​ Receiver B, possessing S, can recompute H(M′∣∣S) and verify against the received hash.
○​ Authentication & Integrity: Since S is secret and not transmitted, an opponent cannot
modify the message and generate a valid new hash. This provides both integrity and
sender authentication.
○​ No Confidentiality: The message M itself is sent in plaintext.

d. Adding Confidentiality to Method (c):

○​ Combines method (c) with symmetric encryption.

○​ The entire message M plus the hash calculated with the shared secret H(M∣∣S) is
encrypted using a symmetric secret key K: E(K,[M∣∣H(M∣∣S)]).
○​ Benefits: Provides both confidentiality and the strong authentication/integrity derived
from the secret-keyed hash.

Advantages of Avoiding Encryption for Authentication (Method c vs. a/b/d): There has been
increasing interest in techniques like Figure 11.3c that avoid full message encryption for authentication.
Reasons [TSUD92] include:

●​ Slower Encryption Software: Encryption, even for small data, can be slow, which is an issue for
continuous message streams.
●​ Non-negligible Hardware Costs: Implementing encryption hardware at all network nodes can be
costly.
●​ Encryption Hardware Optimization: Encryption hardware is often optimized for large data
sizes, leading to high initialization overhead for small blocks.
●​ Patent/Licensing Costs: Encryption algorithms may be patented, incurring licensing fees.
●​ Message Authentication Code (MAC) / Keyed Hash Function:
○​ More commonly, message authentication is achieved using a Message Authentication
Code (MAC), also known as a keyed hash function.
○​ A MAC function takes a secret key and a data block as input, producing a fixed-size hash
value (the MAC) associated with the message.
○​ Integrity Check: The receiver applies the same MAC function to the message using the
shared secret key and compares the result with the received MAC.

Department of CSE, SJBIT​ ​ ​ ​ ​ ​ ​ ​ ​ 99

Cryptography and Network Security - BCS703​ ​ ​ ​ Module 3

○​ Security: An attacker without knowledge of the secret key cannot alter the message and
produce a valid MAC, thus protecting integrity.
○​ Authentication: The verifying party also knows the sender's identity because only that
sender (and the receiver) possess the secret key.
○​ Relationship to Encryption+Hashing: The combination E(K,H(M)) (Figure 11.3b) is
functionally a MAC. However, dedicated MAC algorithms are generally more efficient
than general encryption algorithms. (MACs are discussed in Chapter 12).

Digital Signatures

●​ Similarity to MACs: Digital signatures are a crucial application similar to message

authentication.
●​ Key Difference (Asymmetric Cryptography): Instead of symmetric encryption or a
shared secret key (as in MACs), the hash value of a message is encrypted with the
sender's private key (using public-key encryption).
●​ Verification: Anyone who knows the sender's public key can decrypt the hash value and
verify it against a newly computed hash of the message.
●​ Security: An attacker needs the sender's private key to alter the message and forge a
valid digital signature.
●​ Implications: Digital signatures provide non-repudiation (proof of origin that the sender
cannot later deny), which goes beyond simple message authentication (Chapter 14).

Figure 11.4: Simplified Examples of Digital Signatures

Department of CSE, SJBIT​ ​ ​ ​ ​ ​ ​ ​ ​ 100

Cryptography and Network Security - BCS703​ ​ ​ ​ Module 3

a. Encrypting Hash with Sender's Private Key:

○​ The hash code H(M) is encrypted using the sender's private key PRa​: E(PRa​,H(M)).
○​ The message M is sent in plaintext, accompanied by the encrypted hash.
○​ Authentication & Digital Signature: Only the sender (A) has PRa​, so only A could
have produced E(PRa​,H(M)). This verifies the sender's authenticity and provides a
non-forgeable digital signature.
○​ Verification: Any party can use A's public key PUa​ to decrypt the hash
D(PUa​,E(PRa​,H(M)))=H(M), then compute H(M′) from the received message and
compare.

b. Adding Confidentiality to Digital Signatures:

○​ If confidentiality is also desired, the entire message M plus the private-key-encrypted

hash code E(PRa​,H(M)) are encrypted using a symmetric secret key K:
E(K,[M∣∣E(PRa​,H(M))]).
○​ This is a common and robust technique, combining digital signature for
authentication/non-repudiation with symmetric encryption for confidentiality.

Other Applications of Hash Functions

●​ One-Way Password File:

○​ Instead of storing actual passwords, operating systems store a hash of each user's
password.
○​ When a user attempts to log in, the system hashes the entered password and
compares it to the stored hash value.
○​ Security: If a hacker gains access to the password file, they retrieve only hash
values, not the actual passwords, making it extremely difficult to recover the
original passwords due to the one-way property of cryptographic hash functions.
(Chapter 24 discusses this in detail).
●​ Intrusion Detection and Virus Detection:
○​ A system can store the hash value H(F) for each critical file F (e.g., system files,
application executables). These hash values must be securely stored (e.g., on a
read-only medium like a CD-R).
○​ To detect modifications, the system can periodically recompute H(F) for each file
and compare it with the stored secure hash.
○​ Detection: Any mismatch indicates a modification. An intruder or virus would
need to alter the file without changing its hash, which is computationally
infeasible for a strong cryptographic hash function.
●​ Pseudorandom Function (PRF) / Pseudorandom Number Generator (PRNG)
Construction:
○​ Cryptographic hash functions can be used as a building block for constructing
PRFs or PRNGs.
○​ A common application for hash-based PRFs is the generation of symmetric keys.

Department of CSE, SJBIT​ ​ ​ ​ ​ ​ ​ ​ ​ 101

Cryptography and Network Security - BCS703​ ​ ​ ​ Module 3

3.2 TWO SIMPLE HASH FUNCTIONS

To understand the security requirements of cryptographic hash functions, it's helpful to examine simple,
insecure examples. All hash functions generally operate by processing an input (message, file, etc.) as a
sequence of n-bit blocks, one block at a time, in an iterative fashion, to produce an n-bit hash value.

1. Bit-by-Bit Exclusive-OR (XOR)

●​ Operation: This is one of the simplest hash functions. It computes the bit-by-bit XOR of every
block of the input.
○​ Ci​=bi1​⊕bi2​⊕⋯⊕bim​
○​ Where:
■​ Ci​=ith bit of the hash code (for 1≤i≤n)
■​ m=number of n-bit blocks in the input
■​ bij​=ith bit in jth block
■​ ⊕=XOR operation
●​ Result: This operation produces a simple parity bit for each bit position. It is also known as a
longitudinal redundancy check (LRC).
●​ Effectiveness for Random Data: It is reasonably effective as a data integrity check for truly
random data. Each n-bit hash value is equally likely. The probability that a data error will result in
an unchanged hash value is 2−n.
●​ Effectiveness for Predictable Data: Less effective for predictably formatted data. For example,
in many text files, the most significant bit (high-order bit) of each octet (byte) is always zero. If a
128-bit hash value is used, and 16 bits are derived from each octet's high-order bit, then the
effectiveness for this specific kind of data reduces from 2−128 to 2−112 (as 16 bits are always
zero, effectively reducing the hash size).

2. XOR with One-Bit Circular Shift (Rotated XOR - RXOR)

Department of CSE, SJBIT​ ​ ​ ​ ​ ​ ​ ​ ​ 102

Cryptography and Network Security - BCS703​ ​ ​ ​ Module 3

●​ Improvement: A simple way to improve the basic XOR hash is to perform a one-bit circular
shift (rotation) on the current hash value after each input block is processed.
●​ Procedure:
1.​ Initialize the n-bit hash value to zero.
2.​ For each successive n-bit block of data: a. Rotate the current hash value to the left by one
bit. b. XOR the current data block into the rotated hash value.
●​ Effect: This procedure aims to "randomize" the input more completely and overcome regularities
in the input data, making the hash function appear more robust. (Figure 11.5 illustrates both
simple XOR and RXOR).

Why These Simple Hash Functions Are Insecure for Data Security

Even with the rotation, these simple hash functions are virtually useless for data security applications,
especially when an encrypted hash code is used with a plaintext message (as in Figures 11.3b and 11.4a,
where only the hash is encrypted or signed).

Department of CSE, SJBIT​ ​ ​ ​ ​ ​ ​ ​ ​ 103

Cryptography and Network Security - BCS703​ ​ ​ ​ Module 3

●​ Vulnerability to Chosen Message Attack: Given a desired hash code (or even just the original
message), it's extremely easy for an attacker to produce a new message that yields that same hash
code.
○​ Method: The attacker can prepare their desired alternate message. They then simply
append an n-bit block (the final block) that, when XORed into the hash of the preceding
blocks, forces the overall hash of the new message plus this final block to equal the target
hash code. This directly violates the collision-resistant property required for
cryptographic hash functions.
●​ Vulnerability Even with Full Encryption (Figure 11.3a - CBC Mode Example):
○​ One might think that if the message and the hash code are fully encrypted (e.g., using
Cipher Block Chaining (CBC) mode, as proposed by the National Bureau of Standards
for a 64-bit block XOR hash), security would hold.
○​ Scheme (NBS Proposal):
■​ Message M is split into 64-bit blocks X1​,X2​,…,XN​.
■​ Hash code h=XN+1​=X1​⊕X2​⊕⋯⊕XN​.
■​ The entire message plus hash (X1​,…,XN​,XN+1​) is then encrypted using CBC
mode to produce ciphertext Y1​,Y2​,…,YN+1​.
○​ Vulnerability (as pointed out by [JUEN85]): The ciphertext of this message can be
manipulated without detection by this simple hash code due to properties of CBC mode
and XOR.
■​ Recall CBC decryption: Xi​=Yi−1​⊕D(K,Yi​) (and X1​=IV⊕D(K,Y1​)).
■​ The hash code is XN+1​=X1​⊕X2​⊕⋯⊕XN​.
■​ Substituting the CBC decryption formula into the hash formula:
XN+1​=[IV⊕D(K,Y1​)]⊕[Y1​⊕D(K,Y2​)]⊕⋯⊕[YN−1​⊕D(K,YN​)]
■​ Problem: Because XOR is associative and commutative, the terms in the
expression for XN+1​ can be reordered. This means that if the ciphertext blocks
(Y1​,Y2​,…,YN​) are permuted by an attacker, the calculated hash code XN+1​
would not change. The receiver would decrypt the permuted blocks, compute
the hash, and find it matches the (unchanged) XN+1​, leading to undetected
alteration of the message's block order. This is a critical failure for integrity.

3.3 SYMMETRIC KEY DISTRIBUTION USING

SYMMETRIC ENCRYPTION
For symmetric encryption to function, two communicating parties must share an identical secret key, and
this key must be protected from unauthorized access. Frequent key changes are often desirable to limit the
potential damage if a key is compromised. The security of any cryptographic system heavily relies on the
key distribution technique, which refers to the methods used to deliver a key securely to two parties
wishing to exchange data.

Methods of Key Distribution:

Department of CSE, SJBIT​ ​ ​ ​ ​ ​ ​ ​ ​ 104

Cryptography and Network Security - BCS703​ ​ ​ ​ Module 3

1.​ Physical Delivery by A: User A selects a key and physically delivers it to B.

2.​ Physical Delivery by Third Party: A trusted third party selects the key and physically delivers it
to both A and B.
3.​ Encrypted Transmission with Old Key: If A and B have previously (and recently) shared a key,
one party can transmit a new key to the other, encrypted using the old key.
4.​ Third Party (KDC) Delivery over Encrypted Links: If A and B each have an encrypted
connection to a trusted third party C (a Key Distribution Center), C can deliver a key to A and B
over these encrypted links.

Challenges with Key Distribution:

●​ Manual Delivery (Options 1 & 2):

○​ Feasible for Link Encryption: Suitable for link encryption, where devices only
communicate with a single partner.
○​ Awkward for End-to-End Encryption: Highly impractical for end-to-end encryption in
large, distributed networks where any host/terminal might need to communicate with
many others dynamically.
●​ Scale of the Problem: The number of required keys grows significantly with the number of
communicating entities.
○​ If there are N hosts, the number of required keys for pairwise communication is
N(N−1)/2.
○​ For 1000 network nodes doing node-level encryption, this could be half a million keys.
○​ For 10,000 applications doing application-level encryption, it could be 50 million keys.
(Figure 14.1 illustrates this magnitude).

Department of CSE, SJBIT​ ​ ​ ​ ​ ​ ​ ​ ​ 105

Cryptography and Network Security - BCS703​ ​ ​ ​ Module 3

●​ Cascading Compromise (Option 3): If an attacker compromises even one key, all subsequent
keys transmitted using that compromised key will also be revealed. Additionally, the initial
distribution of potentially millions of keys remains an issue.

Key Distribution Center (KDC) Approach (Option 4)

A common and widely adopted solution for end-to-end encryption is using a Key Distribution Center
(KDC).

●​ Mechanism: A KDC is responsible for distributing session keys to pairs of users (hosts,
processes, applications) as needed. Each user (or end system) must share a unique master key
with the KDC.
●​ Key Hierarchy (Figure 14.2): This approach relies on a two-level key hierarchy:

Department of CSE, SJBIT​ ​ ​ ​ ​ ​ ​ ​ ​ 106

Cryptography and Network Security - BCS703​ ​ ​ ​ Module 3

○​ Session Keys: Temporary keys used for encrypting communication between end systems.
They are typically used for the duration of a logical connection (e.g., a frame relay or
transport connection) and then discarded.
○​ Master Keys: Long-lasting keys shared between an end system/user and the KDC.
Session keys are transmitted in encrypted form, using the relevant master key.
●​ Reduced Distribution Problem: The scale of master key distribution is significantly reduced.
For N entities, only N master keys are needed (one per entity shared with the KDC), compared to
N(N−1)/2 session keys. These master keys can be distributed via non-cryptographic, physical
means.

A Key Distribution Scenario (Figure 14.3)

This scenario illustrates a typical key distribution process where each user shares a unique master key
with the KDC.

Department of CSE, SJBIT​ ​ ​ ​ ​ ​ ​ ​ ​ 107

Cryptography and Network Security - BCS703​ ​ ​ ​ Module 3

Assumptions:

●​ User A has master key Ka​(shared with KDC).

●​ User B has master key Kb​(shared with KDC).
●​ Alice (A) wants to establish a logical connection with Bob (B) and needs a one-time session key
(Ks​).

Steps:

1.​ A to KDC (Request): A sends a request to the KDC: IDA || IDB || N1.
○​ IDA, IDB: Identities of A and B.
○​ N1: A unique identifier (nonce) for this transaction (e.g., timestamp, counter, random
number). It must be difficult for an opponent to guess to prevent masquerade and replay
attacks.
2.​ KDC to A (Response): The KDC generates a session key Ks​ and sends a message encrypted
with A's master key Ka​: E(Ka, [Ks || IDA || IDB || N1]) || E(Kb, [Ks || IDA]).
○​ For A:
■​ Ks: The one-time session key.

Department of CSE, SJBIT​ ​ ​ ​ ​ ​ ​ ​ ​ 108

Cryptography and Network Security - BCS703​ ​ ​ ​ Module 3

■​ IDA || IDB || N1: The original request message (including nonce), allowing A to
verify the response against the request and detect replays.
○​ For B (encrypted with Kb​):
■​ Ks: The one-time session key.
■​ IDA: Identifier of A.
○​ This entire message ensures A knows it's from the KDC and gets its Ks​. The second part
is for A to forward to B.
3.​ A to B (Forwarding K_s): A stores Ks​and forwards the part intended for B: E(Kb, [Ks || IDA]).
○​ Since it's encrypted with Kb​, only B can decrypt it.
○​ B now knows Ks​, knows the other party is A (from IDA), and trusts the origin (KDC, due
to encryption with Kb​).

Authentication Steps (Optional but Desirable, using the new Ks​):

4.​ B to A: B sends a new nonce N2, encrypted with the new session key Ks​: E(Ks, N2). This assures
A that B has the correct session key and is live.
5.​ A to B: A responds with f(N2), encrypted with Ks​: E(Ks, f(N2)), where f is a simple
transformation (e.g., adding one). This assures B that A has the correct session key and is live,
and that step 3 was not a replay.
●​ Key Distribution: Steps 1-3.
●​ Authentication: Steps 3-5 (Step 3 authenticates the KDC to B and A to B; Steps 4-5 mutually
authenticate A and B using the new session key).

Hierarchical Key Control

●​ Scalability: For very large networks, a single KDC might not be practical. A hierarchy of KDCs
can be established (e.g., local KDCs for domains, a global KDC for inter-domain
communication).
●​ Benefits:
○​ Minimizes Master Key Distribution: Most master keys are local to a KDC and its
entities.
○​ Limits Damage: A compromised KDC's impact is limited to its local domain.

Session Key Lifetime

●​ Security vs. Performance: More frequent session key exchange increases security (less
ciphertext for an opponent per key) but introduces overhead and delays. A balance is needed.
●​ Connection-Oriented Protocols: Typically, a new session key per connection. For long-lived
connections, changing the key periodically (e.g., after a PDU sequence number cycle) is prudent.
●​ Connectionless Protocols: No explicit connection. New key for each exchange is most secure
but adds overhead. A better approach is to use a key for a fixed period or a certain number of
transactions.

A Transparent Key Control Scheme (Figure 14.4)

Department of CSE, SJBIT​ ​ ​ ​ ​ ​ ​ ​ ​ 109

Cryptography and Network Security - BCS703​ ​ ​ ​ Module 3

This approach provides end-to-end encryption at the network or transport layer, transparent to end users,
for connection-oriented protocols (e.g., TCP). It uses a Session Security Module (SSM).

●​ SSM Function: An SSM (e.g., a protocol layer component) handles end-to-end encryption and
obtains session keys for its host/terminal.
●​ Connection Establishment Steps:
1.​ Host A sends connection-request packet.
2.​ SSM buffers packet. SSM asks KDC for a session key (communication encrypted with
master key shared between SSM and KDC).
3.​ KDC distributes session key. If approved, KDC generates and securely delivers the
session key to both communicating SSMs.
4.​ Buffered packet transmitted. The requesting SSM releases the buffered packet, and the
connection is set up.
●​ Ongoing Communication: All user data is then encrypted by the respective SSMs using the
one-time session key.
●​ Benefit: Provides dynamic and flexible key distribution for many users and hosts.

Decentralized Key Control (Figure 14.5)

This approach avoids reliance on a single, trusted KDC.

Department of CSE, SJBIT​ ​ ​ ​ ​ ​ ​ ​ ​ 110

Cryptography and Network Security - BCS703​ ​ ​ ​ Module 3

●​ Requirement: Each end system must be able to securely communicate with all potential partner
end systems for session key distribution. This implies each node needs to maintain (N−1) master
keys (one for each potential partner), or N(N−1)/2 master keys for the entire system.
●​ Session Key Establishment (between A and B):
1.​ A to B (Request): A sends IDA || N1 (nonce) to B.
2.​ B to A (Response): B generates a session key Ks​ and sends a message encrypted with
their shared master key Km​: E(Km, [Ks || IDA || IDB || f(N1) || N2]).
■​ Ks: Session key chosen by B.
■​ IDA, IDB: Identities.
■​ f(N1): Transformation of A's nonce (for anti-replay).
■​ N2: B's nonce.
3.​ A to B (Confirmation): A decrypts the message, gets Ks​, and sends E(Ks, f(N2)) to B
(using the new Ks​).
●​ Benefits: Avoids the single point of failure/trust of a KDC. Short messages exchanged using
master keys make cryptanalysis difficult.
●​ Drawbacks: Requires a large number of master keys for each node in a large network.

Controlling Key Usage

Beyond key hierarchy, it's desirable to control how automatically distributed keys are used.

●​ Key Types: Different session keys can be defined based on their purpose:
○​ Data-encrypting key: For general network communication.
○​ PIN-encrypting key: For PINs in financial transactions.
○​ File-encrypting key: For files in public storage.
●​ Risk of Misuse: If a master key is accidentally used or imported as a data-encrypting key, it
could expose plaintext session keys.
●​ Control Mechanisms:

Department of CSE, SJBIT​ ​ ​ ​ ​ ​ ​ ​ ​ 111

Cryptography and Network Security - BCS703​ ​ ​ ​ Module 3

○​ Embedded Tag (e.g., DES extra 8 bits):

■​ An 8-bit tag embedded in the 64-bit DES key (using parity bits).
■​ Bits could indicate: master/session key, encryption/decryption use.
■​ Pros: Tag is encrypted with the key, offering protection.
■​ Cons: Limited tag length (8 bits), tag only usable at decryption point (limits
control in transit).
○​ Control Vector ([MATY91a and b]):
■​ Each session key has an associated control vector (CV), a variable-length field
specifying uses and restrictions.
■​ Cryptographic Coupling: At the KDC, the CV is passed through a hash
function h(). The hash value H=h(CV) is XORed with the master key Km​to form
a unique key input: Key Input = Km XOR H. This "key input" is then used to
encrypt the session key Ks​: Ciphertext = E(Km XOR H, Ks).
■​ Decryption: To recover Ks​, the recipient uses their Km​ and the received
clear-form CV to re-derive Key Input = Km XOR h(CV) and then decrypt the
ciphertext. This ensures the correct CV is used with the key.
■​ Pros: No restriction on CV length (arbitrary complexity), CV is available in clear
form (allowing control at multiple points).

Department of CSE, SJBIT​ ​ ​ ​ ​ ​ ​ ​ ​ 112

Cryptography and Network Security - BCS703​ ​ ​ ​ Module 3

3.4 SYMMETRIC KEY DISTRIBUTION USING

ASYMMETRIC ENCRYPTION
Public-key cryptosystems are generally inefficient for directly encrypting large blocks of data. Their
primary use is often limited to encrypting relatively small blocks, most importantly for the distribution of
secret keys. This section explores general principles and typical approaches for this use.

Simple Secret Key Distribution (Merkle's Scheme) - Figure 14.7

A very simple protocol proposed by Merkle [MERK79]:

1.​ A generates keys & sends public key to B: Alice (A) generates a public/private key pair
(PUa​,PRa​) and sends her public key PUa​along with her identifier IDA​to Bob (B).
2.​ B generates secret key & sends encrypted to A: Bob generates a secret (symmetric) key Ks​and
encrypts it using Alice's public key: E(PUa​,Ks​). Bob transmits this encrypted message to A.
3.​ A recovers secret key: Alice decrypts the message using her private key: D(PRa​,E(PUa​,Ks​)) to
recover Ks​. Since only Alice possesses PRa​, only A and B know Ks​.
4.​ A & B discard keys: Alice discards PUa​and PRa​, and Bob discards Ks​(used for transmission
only).
●​ Pros: Simplicity, no pre-existing keys required, keys are ephemeral (discarded after use), making
compromise risk minimal. Communication is secure from eavesdropping.
●​ Cons: Insecure against Man-in-the-Middle (MITM) Attack [RIVE84]: This protocol is
vulnerable if an adversary (E) can intercept, relay, or substitute messages.

MITM Attack Scenario (Darth/Eve):

1.​ Alice sends PUA​∣∣IDA​to Bob.

2.​ Eve intercepts. Eve creates her own public/private key pair (PUE​,PRE​). Eve transmits
PUE​∣∣IDA​to Bob (impersonating Alice by using Alice's ID).
3.​ Bob generates Ks​& encrypts with Eve's key (thinking it's Alice's). Bob generates a secret key
Ks​and transmits E(PUE​,Ks​).
4.​ Eve intercepts & learns Ks​. Eve decrypts E(PUE​,Ks​) using her private key PRE​to obtain Ks​.

Department of CSE, SJBIT​ ​ ​ ​ ​ ​ ​ ​ ​ 113

Cryptography and Network Security - BCS703​ ​ ​ ​ Module 3

5.​ Eve re-encrypts with Alice's key & sends to Alice. Eve encrypts Ks​with Alice's original public
key E(PUA​,Ks​) and transmits it to Alice.
6.​ Alice receives & learns Ks​. Alice decrypts E(PUA​,Ks​) using her PRA​to obtain Ks​.
●​ Result: Both Alice and Bob believe they share Ks​, but Eve also knows Ks​. Alice and Bob will
communicate using Ks​, unaware that Eve can decrypt all their messages.
●​ Conclusion: This simple protocol is only secure against eavesdropping; it provides no protection
against active MITM attacks.

Secret Key Distribution with Confidentiality and Authentication

(Needham-Schroeder Style)

This approach [NEED78] provides protection against both passive (eavesdropping)

and active (MITM) attacks. It assumes that Alice (A) and Bob (B) have already
exchanged their public keys via a secure method (e.g., using a Public Key
Infrastructure with certificates, discussed later).
Steps:

1.​ A to B (Request for Shared Secret): A uses B's public key PUB​to encrypt a message containing
A's identifier IDA​and a nonce N1​(to uniquely identify the transaction and prevent replays):
E(PUB​,[N1​∣∣IDA​]).
2.​ B to A (Confirmation & New Nonce): B decrypts message (1). B sends a message to A
encrypted with A's public key PUA​, containing A's nonce N1​(to assure A that B received the
correct message) and a new nonce N2​generated by B: E(PUA​,[N1​∣∣N2​]).
○​ Authentication: The presence of N1​in message (2) assures A that the correspondent is
indeed B, because only B could have decrypted message (1) to retrieve N1​.
3.​ A to B (Confirmation of B's Nonce): A returns N2​(received from B) to B, encrypted using B's
public key PUB​: E(PUB​,N2​).

Department of CSE, SJBIT​ ​ ​ ​ ​ ​ ​ ​ ​ 114

Cryptography and Network Security - BCS703​ ​ ​ ​ Module 3

○​ Authentication: This assures B that its correspondent is A, because only A could have
correctly decrypted message (2) and retrieved N2​.
4.​ A to B (Secret Key Distribution): Alice selects a secret key Ks​. She then sends it to B,
encrypted with both B's public key and her own private key (for signature/authentication):
E(PUB​,E(PRA​,Ks​)).
○​ Confidentiality: Encryption with PUB​ensures only B can read Ks​.
○​ Authentication: Encryption with PRA​ensures only A could have sent the message,
providing a digital signature.
5.​ B recovers secret key: Bob decrypts the message: first with his private key PRB​to get
E(PRA​,Ks​), then with Alice's public key PUA​to recover Ks​.
●​ Result: This scheme securely exchanges Ks​with both confidentiality and authentication.

A Hybrid Scheme (IBM Mainframes Approach)

This approach combines elements of KDC-based symmetric key distribution with public-key encryption
for master key distribution, creating a three-level hierarchy.

●​ Traditional KDC Core: Retains a Key Distribution Center (KDC) that shares a secret master key
with each user. The KDC distributes symmetric session keys encrypted with these master keys (as
in the previous section).
●​ Public-Key Layer for Master Keys: A public-key scheme is used specifically for the
distribution and periodic update of these master keys.
●​ Rationale for Three-Level Approach:
○​ Performance: Public-key encryption is computationally intensive. For applications with
frequent session key changes, directly using public-key encryption for every session key
would degrade performance. By using public-key encryption only occasionally to update
master keys, and symmetric encryption for frequent session keys, efficiency is
maintained.
○​ Backward Compatibility: This hybrid scheme can be easily integrated into existing
KDC infrastructures with minimal disruption or software changes.
●​ Advantage: This provides a secure and efficient means of distributing master keys, especially
beneficial for configurations where a single KDC serves a widely distributed set of users.

3.5 DISTRIBUTION OF PUBLIC KEYS

Several techniques exist for distributing public keys, which are essential for asymmetric encryption.
These methods can generally be categorized into four schemes:

●​ Public announcement
●​ Publicly available directory
●​ Public-key authority
●​ Public-key certificates

Department of CSE, SJBIT​ ​ ​ ​ ​ ​ ​ ​ ​ 115

Cryptography and Network Security - BCS703​ ​ ​ ​ Module 3

Public Announcement of Public Keys (Figure 14.9)

●​ Concept: The simplest approach is for individuals to simply broadcast or announce their public
key to anyone. Given that public keys are designed to be public, this seems intuitive. For
example, PGP users often append their public key to messages sent to public forums like Usenet
newsgroups or mailing lists.
●​ Weakness: This method is highly insecure due to the lack of authentication.
○​ Forgery: Anyone can generate a public/private key pair and pretend to be another user
(e.g., User A). They can then announce this forged public key as if it belongs to User A.
○​ Consequences: Until the real User A discovers the forgery and alerts others, the impostor
can:
■​ Read all encrypted messages intended for the real User A (by encrypting with the
forged public key).
■​ Use the forged keys to digitally sign messages, impersonating User A for
authentication purposes.

Publicly Available Directory (Figure 14.10)

Department of CSE, SJBIT​ ​ ​ ​ ​ ​ ​ ​ ​ 116

Cryptography and Network Security - BCS703​ ​ ​ ​ Module 3

●​ Concept: To enhance security, a trusted entity or organization maintains a dynamic, publicly

available directory of public keys.
●​ Elements:
○​ Directory Maintenance: The authority holds a directory with {name, public key}
entries for each participant.
○​ Registration: Participants register their public key with the authority. This registration
must be secure and authenticated (e.g., in person or via secure communication).
○​ Key Replacement: Participants can update their key at any time (e.g., due to extensive
use, or if their private key is compromised).
○​ Electronic Access: Participants can access the directory electronically. This access must
be secure and authenticated from the authority to the participant.
●​ Vulnerabilities: While more secure than public announcements, this scheme still has weaknesses:
○​ Directory Authority Compromise: If an adversary compromises the directory
authority's private key, or manages to tamper with the records in the directory, they could:
■​ Distribute counterfeit public keys to users, impersonating any participant.
■​ Eavesdrop on messages intended for any participant by replacing their legitimate
public key with a key known to the adversary.

Public-Key Authority

Department of CSE, SJBIT​ ​ ​ ​ ​ ​ ​ ​ ​ 117

Cryptography and Network Security - BCS703​ ​ ​ ​ Module 3

●​ Concept: This method provides tighter control over public key distribution from a central
directory, offering stronger security. It assumes each participant reliably knows the public key of
the central authority, and only the authority knows its corresponding private key.
●​ Scenario (Request-Response Protocol):
1.​ A to Authority: Alice (A) sends a timestamped message to the public-key authority,
requesting Bob's (B's) current public key. (Request || T1)
2.​ Authority to A: The authority responds with a message encrypted using its private key
(PRauth​).
■​ E(PR_auth, [PU_b || Request || T1])
■​ Authentication: A decrypts this using the authority's public key (PUauth​),
assuring A that the message originated from the trusted authority.
■​ Contents: Includes B's public key (PUb​), the original request (for A to match the
response and verify no alteration), and the timestamp T1​(to ensure currency and
prevent replay of old keys).
3.​ A to B (Initiating Communication): A stores B's public key and encrypts a message for
B containing A's identifier (IDA​) and a nonce N1​: E(PU_b, [IDA || N1]).

Department of CSE, SJBIT​ ​ ​ ​ ​ ​ ​ ​ ​ 118

Cryptography and Network Security - BCS703​ ​ ​ ​ Module 3

4.​ B to Authority: B retrieves A's public key from the authority in the same manner as A
did for B (steps 1 & 2 for B and A respectively): (Request || T2), followed by
E(PR_auth, [PU_a || Request || T2]).
●​ Mutual Authentication (Desired Additional Steps): Once both A and B have each other's
public keys: 6. B to A: B sends a message to A, encrypted with A's public key (PUa​), containing
A's nonce N1​and a new nonce N2​generated by B: E(PU_a, [N1 || N2]). *
Authentication: Only B could have decrypted message (3) to get N1​, so A is assured the
correspondent is B. 7. A to B: A returns N2​, encrypted using B's public key (PUb​): E(PU_b,
N2). * Authentication: This assures B that its correspondent is A.
●​ Efficiency: A total of seven messages are required for a first-time secure exchange. However,
public keys can be cached for future use, reducing subsequent exchanges to steps 3, 6, and 7.
Users should periodically request fresh copies to ensure currency.

Public-Key Certificates

●​ Concept: This approach, first suggested by Kohnfelder [KOHN78], aims to overcome the
bottleneck and vulnerability of a centralized public-key authority. It uses certificates to allow
participants to exchange keys reliably without constant contact with the authority.
●​ What is a Certificate? A certificate essentially bundles a public key and its owner's identifier,
and this entire block is digitally signed by a trusted third party, typically a Certificate Authority
(CA) (e.g., a government agency or financial institution).
●​ Process:
○​ A user securely presents their public key to a CA and obtains a certificate.
○​ The user can then publish this certificate (e.g., on a website, in an email signature).

Department of CSE, SJBIT​ ​ ​ ​ ​ ​ ​ ​ ​ 119

Cryptography and Network Security - BCS703​ ​ ​ ​ Module 3

○​ Anyone needing this user's public key can obtain the certificate and verify its validity
using the CA's well-known public signature.
○​ A participant can also send their certificate directly to another participant.
●​ Requirements for a Certificate Scheme:
○​ Readability: Any participant can easily read a certificate to get the owner's name and
public key.
○​ Origin Verification: Any participant can verify that the certificate genuinely originated
from the CA and has not been tampered with.
○​ CA Exclusivity: Only the CA can create and update certificates.
●​ Additional Requirement (Denning [DENN83]): 4. Currency Verification: Any participant can
verify the currency (freshness/validity period) of the certificate. This is crucial to prevent replay
attacks with compromised old keys.
●​ Certificate Structure (Example):
○​ A CA provides a certificate of the form: Cert_A = E(PR_auth, [T || ID_A
|| PU_a])
○​ PRauth​: Private key of the Certificate Authority.
○​ T: Timestamp.
○​ IDA​: Identifier of User A.
○​ PUa​: Public key of User A.
●​ Verification:
○​ The recipient uses the CA's public key (PUauth​) to decrypt the certificate: D(PU_auth,
E(PR_auth, [T || ID_A || PU_a])).
○​ Successful decryption verifies the certificate's origin (only the CA could have signed it).
○​ ID_A and PUa​provide the owner's name and public key.
○​ The timestamp T validates the certificate's currency. This counters scenarios where a
private key is compromised, a new certificate is issued, but an attacker replays the old
(compromised) certificate. If the old certificate is used for encryption, the attacker can
still read messages. The timestamp acts like an expiration date.
●​ Standardization: The X.509 standard has become universally accepted for formatting
public-key certificates. X.509 certificates are widely used in network security applications like
IPsec, TLS, and S/MIME. The next section will delve into X.509.

3.6 X.509 CERTIFICATES

ITU-T Recommendation X.509 is part of the X.500 series, which defines a directory service. This
directory functions as a server (or a distributed set of servers) that maintains a database of user
information, including mappings from user names to network addresses, and other user attributes.

X.509 specifically defines a framework for authentication services provided by the X.500 directory to its
users. Crucially, the directory can serve as a repository for public-key certificates, similar to those
discussed in the previous section. Each certificate contains a user's public key and is digitally signed using
the private key of a trusted Certification Authority (CA). X.509 also outlines alternative authentication
protocols that leverage these public-key certificates.

Department of CSE, SJBIT​ ​ ​ ​ ​ ​ ​ ​ ​ 120

Cryptography and Network Security - BCS703​ ​ ​ ​ Module 3

Importance: X.509 is a cornerstone standard because its defined certificate structure and authentication
protocols are widely adopted in various security contexts, including S/MIME (email security), IP Security
(IPsec), and SSL/TLS (web security).

Evolution:

●​ Initially issued in 1988.

●​ Revised in 1993 to address security concerns identified by [IANS90] and [MITC90].
●​ Version 3 was issued in 1995 and revised in 2000.

Underlying Cryptography:

●​ X.509 relies on public-key cryptography and digital signatures.

●​ It does not mandate a specific algorithm but recommends RSA for public-key operations.
●​ The digital signature scheme necessitates a hash function. Again, X.509 does not dictate a
specific hash algorithm. (The 1988 version included a recommended hash algorithm that was later
found insecure and removed in the 1993 revision).

Figure 14.13: Public-Key Certificate Use (Generation and Verification)

Department of CSE, SJBIT​ ​ ​ ​ ​ ​ ​ ​ ​ 121

Cryptography and Network Security - BCS703​ ​ ​ ​ Module 3

This figure illustrates the process:

1.​ Unsigned Certificate: Contains user ID and the user's public key.
2.​ Generate Hash Code: A hash function (H) is applied to the unsigned certificate.
3.​ Encrypt Hash Code (Signature): The hash code is encrypted with the CA's private key (PRCA​)
to form the digital signature.
4.​ Signed Certificate: The signature is appended to the unsigned certificate.
5.​ Verification (Recipient Side):
○​ The recipient applies the same hash function to the received unsigned certificate.
○​ The recipient decrypts the received signature using the CA's public key (PUCA​) to
recover the original hash code.
○​ The recipient compares the newly computed hash code with the recovered hash code. If
they match, the signature is valid, and the recipient trusts the certificate's authenticity.

Certificates

The core of the X.509 scheme is the public-key certificate issued to each user.

●​ Certificates are assumed to be created by a trusted Certification Authority (CA).

●​ They are placed in a directory by the CA or the user.
●​ The directory server acts as a repository; it does not create public keys or perform certification
itself.

Figure 14.14a: X.509 Certificate General Format

Department of CSE, SJBIT​ ​ ​ ​ ​ ​ ​ ​ ​ 122

Cryptography and Network Security - BCS703​ ​ ​ ​ Module 3

A certificate includes the following essential elements:

●​ Version: Indicates the certificate format version (1, 2, or 3). Version 2 is required if unique
identifiers are present. Version 3 is required if extensions are present.
●​ Serial Number: An integer unique within the issuing CA, unambiguously identifying this
certificate.
●​ Signature Algorithm Identifier: Specifies the algorithm (e.g., RSA with SHA-256) used by the
CA to sign the certificate. (This information is redundant as it's repeated in the final signature
field).
●​ Issuer Name: The X.500 name of the CA that created and signed the certificate.
●​ Period of Validity: Consists of two dates: "Not Before" (start date) and "Not After" (end date),
defining the certificate's validity period.
●​ Subject Name: The X.500 name of the entity (user, host, etc.) whose public key is being certified
by this certificate.
●​ Subject's Public-Key Information: Contains the subject's public key, along with an identifier of
the algorithm it's intended for (e.g., RSA, DSA) and any associated parameters.

Department of CSE, SJBIT​ ​ ​ ​ ​ ​ ​ ​ ​ 123

Cryptography and Network Security - BCS703​ ​ ​ ​ Module 3

●​ Issuer Unique Identifier (Optional - Version 2+): A bit string to uniquely identify the issuing
CA if its X.500 name has been reused.
●​ Subject Unique Identifier (Optional - Version 2+): A bit string to uniquely identify the subject
if its X.500 name has been reused.
●​ Extensions (Version 3+): A set of one or more optional fields providing additional information.
These are discussed in detail below.
●​ Signature: A digital signature over all other fields of the certificate. It consists of a hash of the
other fields, encrypted with the CA's private key. This field also includes the signature algorithm
identifier.

X.509 Notation for a Certificate: Y≪A≫=CA{V,SN,AI,CA,UCA,A,UA,Ap,TA} Where:

●​ Y≪A≫: Certificate of user A issued by CA Y.

●​ CA{I}: The signing of information I by CA Y, meaning I with an encrypted hash code (signature)
appended.
●​ V: Version
●​ SN: Serial Number
●​ AI: Algorithm Identifier (signature)
●​ CA: Name of Certificate Authority
●​ UCA: Optional Unique Identifier of CA
●​ A: Name of User A (Subject Name)
●​ UA: Optional Unique Identifier of User A
●​ Ap: Public Key of User A
●​ TA: Period of Validity

Verification: If a user knows the CA's public key, they can verify a certificate signed by that CA. This is
the standard digital signature process.

Obtaining a User's Certificate

●​ Verifiability: Any user with access to the CA's public key can verify the public key contained
within the certificate.
●​ Integrity: No party other than the CA can modify the certificate without detection.
●​ Storage: Because certificates are unforgeable, they can be stored in a directory without special
protection.

Trust Model (Single CA): If all users trust the same CA, all user certificates can be placed in a directory
for common access. A user can also directly transmit their certificate to another. Once B has A's
certificate, B can confidently:

●​ Encrypt messages for A (confidentiality).

●​ Verify messages digitally signed by A (authenticity/non-repudiation).

Trust Model (Multiple CAs - Hierarchical Structure)

Department of CSE, SJBIT​ ​ ​ ​ ​ ​ ​ ​ ​ 124

Cryptography and Network Security - BCS703​ ​ ​ ​ Module 3

For large user communities, a single CA might be impractical. Multiple CAs can exist, each providing its
public key securely to a subset of users.

Certification Path (Chain of Certificates): If Alice (A) trusts CA1​and Bob (B) trusts CA2​, but A does
not directly trust CA2​, A can still obtain B's public key if CA1​ and CA2​ have securely exchanged their
public keys (i.e., issued certificates for each other).

Process (Chain CA1​→CA2​):

1.​ A gets CA2​'s certificate from CA1​: A obtains CA1​≪CA2​≫ from the directory. Since A
securely knows CA1​'s public key, A can verify the signature and trust CA2​'s public key.
2.​ A gets B's certificate from CA2​: A then obtains CA2​≪B≫ from the directory. Since A now
trusts CA2​'s public key, A can verify the signature and securely obtain B's public key.

Notation: This chain is expressed as: CA1​≪CA2​≫CA2​≪B≫. The reverse chain

(CA2​≪CA1​≫CA1​≪A≫) allows B to get A's public key.

●​ Arbitrary Length Chains: This scheme extends to chains of arbitrary length, e.g.,
X1​≪X2​≫X2​≪X3​≫…XN​≪B≫. Each pair of CAs in the chain must have cross-certified each
other.
●​ X.509 Hierarchy (Figure 14.15): X.509 suggests arranging CAs in a hierarchy for
straightforward navigation.

Department of CSE, SJBIT​ ​ ​ ​ ​ ​ ​ ​ ​ 125

Cryptography and Network Security - BCS703​ ​ ​ ​ Module 3

○​ A CA's directory entry includes:

■​ Forward certificates: Certificates of other CAs, signed by this CA (e.g.,
CAparent​≪CAchild​≫).
■​ Reverse certificates: Certificates generated by this CA, certifying other CAs
(e.g., CAchild​≪CAparent​≫).

Department of CSE, SJBIT​ ​ ​ ​ ​ ​ ​ ​ ​ 126

Cryptography and Network Security - BCS703​ ​ ​ ​ Module 3

○​ Users can "unwrap" a certification path by starting with a trusted CA, using its public key
to verify the next certificate in the chain, extracting the next CA's public key, and
repeating until the target user's public key is obtained.

Revocation of Certificates

Certificates have a period of validity. However, they may need to be revoked before expiration for reasons
like:

1.​ Compromised Private Key: The certificate owner's private key is believed to be compromised.
2.​ User No Longer Certified: The CA no longer certifies the user (e.g., name change, certificate
superseded, policy non-conformance).
3.​ CA Compromised: The CA's own certificate (and thus its signing private key) is believed to be
compromised.
●​ Certificate Revocation Lists (CRLs): Each CA maintains and publishes a Certificate
Revocation List (CRL).
○​ CRLs contain all revoked but not yet expired certificates issued by that CA (both user and
other CA certificates).
○​ CRLs are signed by the issuing CA and posted to the directory.
○​ CRL Format (Figure 14.14b): Includes the issuer's name, creation date, next scheduled
CRL issue date, and entries for each revoked certificate (serial number and revocation
date).
●​ User Behavior: When a user receives a certificate, they must check if it has been revoked. Users
typically maintain a local cache of certificates and CRLs to avoid constant directory lookups.

X.509 Version 3 Extensions

Version 2 of X.509 was found insufficient for new requirements. Version 3 introduced optional
extensions to provide flexibility.

●​ Each extension has an identifier, a criticality indicator (TRUE if unrecognized extensions make
the certificate invalid, FALSE if they can be safely ignored), and an extension value.

Categories of Extensions:

1.​ Key and Policy Information:

○​ Authority Key Identifier: Identifies the specific public key used by the CA to sign this
certificate/CRL (useful for CA key updates).
○​ Subject Key Identifier: Identifies the public key being certified (useful for subject key
updates, or when a subject has multiple key pairs for different purposes like signing vs.
encryption).
○​ Key Usage: Specifies the permitted purposes for the certified public key (e.g., digital
signature, non-repudiation, key encryption, data encryption, key agreement, certificate
signing, CRL signing).

Department of CSE, SJBIT​ ​ ​ ​ ​ ​ ​ ​ ​ 127

Cryptography and Network Security - BCS703​ ​ ​ ​ Module 3

○​ Private-Key Usage Period: Defines the validity period for the private key corresponding
to the public key, which may differ from the public key's validity.
○​ Certificate Policies: Lists the security policies that the certificate is recognized as
supporting (e.g., for specific transaction types).
○​ Policy Mappings: Used in CA certificates to indicate that one of the issuing CA's
policies is equivalent to a policy in the subject CA's domain.
2.​ Certificate Subject and Issuer Attributes:
○​ Provide alternative names or additional descriptive information for the subject or issuer.
○​ Subject Alternative Name: Allows multiple names or different formats (e.g., email
address, URL) for the subject, important for applications using non-X.500 identifiers.
○​ Issuer Alternative Name: Similar to subject alternative name, but for the issuer.
○​ Subject Directory Attributes: Conveys any desired X.500 directory attributes for the
subject (e.g., postal address, job title, picture).
3.​ Certification Path Constraints:
○​ Allow CAs to impose restrictions on certificates issued by subordinate CAs or on
subsequent certificates in a chain.
○​ Basic Constraints: Indicates if the subject of the certificate is a CA. If so, it can specify a
maximum path length for certificates issued by that CA (limits depth of hierarchy).
○​ Name Constraints: Defines a name space (e.g., a domain) within which all subject
names in subsequent certificates in a certification path must reside.
○​ Policy Constraints: Specifies constraints that may require explicit certificate policy
identification or inhibit policy mapping for the remainder of the certification path.

3.7 PUBLIC-KEY INFRASTRUCTURE (PKI)

Definition (RFC 2822 - Internet Security Glossary): A Public-Key Infrastructure (PKI) is "the set of
hardware, software, people, policies, and procedures needed to create, manage, store, distribute, and
revoke digital certificates based on asymmetric cryptography."

Principal Objective: To enable the secure, convenient, and efficient acquisition of public keys.

PKIX Working Group: The Internet Engineering Task Force (IETF) Public Key Infrastructure X.509
(PKIX) working group has been instrumental in establishing a formal, generic model based on X.509 for
deploying a certificate-based architecture on the Internet. This section details the PKIX model.

PKIX Architectural Model (Figure 14.16)

Department of CSE, SJBIT​ ​ ​ ​ ​ ​ ​ ​ ​ 128

Cryptography and Network Security - BCS703​ ​ ​ ​ Module 3

The PKIX model defines the interrelationships among several key elements:

●​ End Entity: A broad term for end users, devices (e.g., servers, routers), or any entity identifiable
in a public key certificate's subject field. End entities are the consumers and/or supporters of PKI
services.
●​ Certification Authority (CA): The core component responsible for issuing certificates and
typically Certificate Revocation Lists (CRLs). CAs may also handle administrative functions,
often delegating them to Registration Authorities.
●​ Registration Authority (RA): An optional component that can take on various administrative
functions from the CA. RAs are often involved in the end entity registration process, verifying
identities before a certificate is issued by the CA.

Department of CSE, SJBIT​ ​ ​ ​ ​ ​ ​ ​ ​ 129

Cryptography and Network Security - BCS703​ ​ ​ ​ Module 3

●​ CRL Issuer: An optional component to which a CA can delegate the task of publishing CRLs.
This offloads the CA's publication burden.
●​ Repository: A generic term for any mechanism (e.g., directory service, web server) used to store
certificates and CRLs, making them accessible for retrieval by end entities.

PKIX Management Functions

PKIX identifies several crucial management functions that require support through defined protocols:

●​ Registration: The initial process where a user makes themselves known to a CA (directly or via
an RA) before receiving a certificate. This involves mutual authentication, often through offline
or online procedures, and may result in the issuance of shared secret keys for subsequent
authentication. It's the starting point for enrolling in a PKI.
●​ Initialization: Before a client system can operate securely within the PKI, it must be securely set
up with necessary key materials. This typically involves securely installing the public key and
other verified information of trusted CA(s) to enable validation of certificate paths.
●​ Certification: The process where a CA issues a certificate for a user's public key. This certificate
can then be returned to the user's client system and/or published in a repository.
●​ Key Pair Recovery: For key pairs used for encryption/decryption, a mechanism is needed to
recover decryption keys if normal access (e.g., due to forgotten passwords, corrupted storage,
hardware token damage) is lost. This function allows end entities to restore their
encryption/decryption key pair from an authorized backup facility, usually the CA that issued the
certificate.
●​ Key Pair Update: All key pairs require regular updates (replacement with new pairs) and new
certificate issuance. Updates are necessary when a certificate's lifetime expires or if a certificate is
revoked.
●​ Revocation Request: An authorized individual or system requests a CA to revoke a certificate
due to abnormal situations. Common reasons include private-key compromise, changes in
affiliation, or name changes.
●​ Cross Certification: This function involves two CAs exchanging information to establish a
cross-certificate. A cross-certificate is a certificate issued by one CA to another CA, containing
the latter CA's signature key that it uses for issuing certificates. This builds trust paths between
different CA hierarchies.

PKIX Management Protocols

The PKIX working group has defined two primary alternative management protocols to support the
aforementioned functions:

●​ RFC 2510 - Certificate Management Protocols (CMP):

○​ CMP explicitly defines specific protocol exchanges for each PKIX management function.
○​ It is designed to be a flexible protocol, capable of accommodating various technical,
operational, and business models in PKI deployments.
●​ RFC 2797 - Certificate Management Messages over CMS (CMC):
○​ CMC leverages RFC 2630 (Cryptographic Message Syntax - CMS).

Department of CSE, SJBIT​ ​ ​ ​ ​ ​ ​ ​ ​ 130

Cryptography and Network Security - BCS703​ ​ ​ ​ Module 3

○​ It is built upon existing cryptographic message structures and aims to utilize existing
implementations.
○​ While it supports all PKIX functions, these functions do not always map directly to
specific, distinct protocol exchanges as they do in CMP.

Department of CSE, SJBIT​ ​ ​ ​ ​ ​ ​ ​ ​ 131