MODULE 3

Applications of Cryptographic Hash functions, Two simple Hash functions,

Key management and distribution: Symmetric key distribution using
symmetric encryption, Symmetric key distribution using asymmetric
encryption, Distribution of public keys, X.509 Certificates, Public Key
Infrastructures.

 A hash function takes a variable-length input (M) and produces a fixed-size output (h = H(M))
that appears random and is evenly distributed.
 Its main goal is to ensure data integrity, as even a tiny change in the input will likely produce
a very di erent hash value.
 A cryptographic hash function is a secure type of hash function that makes it
computationally infeasible to find an input that maps to a specific hash (one-way property)
or two di erent inputs that produce the same hash (collision-free property).
 Inputs are padded to a fixed block size (e.g., 1024 bits) and include the original message
length, which increases resistance against attacks.
 Due to their properties, cryptographic hash functions are widely used to check if data has
changed.

Applications of Cryptographic Hash functions

Cryptographic hash functions are widely used in various security applications and Internet protocols
due to their e iciency and reliability.
1. Message Authentication
Cryptographic hash functions are widely used for message authentication, which ensures that the data
received is exactly as sent — with no modifications, insertions, deletions, or replay. The sender
computes a message digest (hash value) and sends it along with the message. The receiver
recalculates the hash and compares it with the received digest. A mismatch indicates that the message
was altered.
To secure the hash from attackers, several techniques are used:
  (a) Encrypt the message and hash using symmetric encryption — ensures authenticity and
confidentiality.
 (b) Encrypt only the hash — saves computation when confidentiality is not required.
 (c) Share a secret value between sender and receiver, compute hash on the message plus secret
— secure even without encryption.
 (d) Encrypt the message and hash in method (c) for added confidentiality.

Another common method is the use of Message Authentication Codes (MACs), also known as keyed
hash functions. A MAC takes a secret key and data block to produce a fixed-size value. If the message
is changed by an attacker, they cannot reproduce the correct MAC without knowing the key. This
ensures both data integrity and the identity of the sender.
2. Digital Signatures
A digital signature is similar to a MAC but uses public-key cryptography. The sender hashes the
message and encrypts the hash with their private key. The recipient uses the sender’s public key to
verify the hash, thus confirming the message’s integrity and the sender’s identity. If confidentiality is
also needed, the message and encrypted hash can be further encrypted using symmetric encryption.

3. Other Applications
 One-Way Password Storage:
Instead of storing actual passwords, systems store a hash of the password. When a user logs in,
the entered password is hashed and compared to the stored value. This makes it impossible for
hackers to retrieve the original password even if they access the password file.
 Intrusion and Virus Detection:
Systems can store hash values of files securely (e.g., on a CD-R). Later, the hash of a file can be
recalculated and compared. If the values di er, it indicates that the file has been changed.
Attackers cannot modify the file and reproduce the original hash without being detected.
  Pseudorandom Function and Key Generation:
Cryptographic hash functions are used to build pseudorandom functions (PRFs) or
pseudorandom number generators (PRNGs). A key application is the secure generation of
symmetric keys, which is further discussed in later chapters.

Two Simple Hash Functions

To understand how secure hash functions work, two simple and insecure hash functions are discussed.
The first method is a basic XOR (exclusive-OR) operation. In this method, the input message is divided
into blocks of fixed size (n-bit blocks), and each corresponding bit from all blocks is XORed together to
form the hash value. This is called a longitudinal redundancy check. It works fine for random data and
helps check if any data has changed. The chance of an error going undetected is very small — 1 in 2^n.
But for more predictable data, like normal text files, it’s less e ective. For example, if each character's
highest bit is always 0, the e ectiveness of the function drops. A 128-bit hash may behave more like a
112-bit one in such cases.
The second method improves the first one by adding a bit rotation step. After processing each block,
the current hash value is rotated left by one bit, and then XORed with the next block. This helps to mix
the data better and makes it harder to find patterns. However, even this method is not secure enough
for cryptographic use. An attacker can still easily create a fake message that produces the same hash
value.

At one point, a similar idea was used in combination with CBC (Cipher Block Chaining) encryption.
The message was split into 64-bit blocks, XORed to create a hash block, and then the whole message
plus hash was encrypted using CBC. But this also turned out to be insecure. Since XOR allows
reordering, attackers could rearrange the encrypted blocks without changing the final hash, and this
manipulation would go undetected.
In summary, while these simple methods can help check for basic errors, they are not suitable for
secure cryptographic applications, especially if used alone or with weak encryption methods.
Symmetric Key Distribution Using Symmetric Encryption
For symmetric encryption to work, both parties (say A and B) must share the same secret key, and this
key must be kept safe from others. It’s also recommended to change keys frequently so that if a key
is ever compromised, only a small amount of data is a ected.
The security of the entire cryptographic system mainly depends on how securely the keys are
distributed between users. Key distribution refers to the method by which two parties can receive a
secret key without anyone else getting access to it.
There are four main ways to distribute keys:
1. A selects a key and physically delivers it to B.
2. A third party selects the key and delivers it to both A and B.
3. If A and B already share a key, one can send a new key encrypted with the old key.
4. If A and B both have encrypted links with a trusted third party C, then C can securely send
a key to both.
Options 1 and 2 involve manual delivery of keys, which can work for link encryption (where two
devices directly communicate), but is not practical for end-to-end encryption across a large network,
since devices may need to communicate with many others over time. Therefore, in large or wide-area
networks, keys must be provided dynamically.
The number of keys required depends on the communication model:
 For host-to-host encryption, if there are N hosts, then [N(N – 1)]/2 keys are needed.
 For application-level encryption, the number of keys is even higher, as each user or process
may need a unique key with others.
Option 3 (using an old key to send a new one) is helpful, but if one key is compromised, then all future
keys are at risk. Also, this still doesn't solve the problem of the initial key distribution on a large scale.
To address this, Option 4 is widely used in end-to-end encryption through a Key Distribution Center
(KDC).
 Each user shares a unique master key with the KDC.
 When two users need to communicate, the KDC generates a temporary session key and
securely sends it to both users.
 This session key is encrypted using the master key shared between the user and the KDC.
 The session key is used for the duration of a single logical session.
This approach vastly reduces the complexity. For N entities, only N master keys are needed, one for
each entity, while session keys are generated as needed. This setup makes key management more
scalable and secure.
A Key Distribution Scenario
The key distribution concept can be deployed in several ways. A typical scenario assumes that each
user shares a unique master key with the key distribution centre (KDC).
Let user A wish to establish a logical connection with user B and requires a one-time session key to
protect the data. A has a master key Ka, known only to A and the KDC. Similarly, B shares master key
Kb with the KDC.
The steps are:
1. A sends a request to the KDC for a session key to connect to B. The message includes:
o Identity of A and B
o A unique nonce (N1) for the transaction
(Nonce: number used only once — may be a timestamp, counter, or random number)
2. KDC replies with a message encrypted using Ka, containing:
o The session key (Ks)
o The original request including nonce N1, allowing A to match it with the request
o Another part encrypted with Kb, meant for B, containing:
 Session key Ks
 Identifier of A (IDA)
3. A stores the session key and sends to B the encrypted part from the KDC:
E(Kb, [Ks || IDA]). B receives this and knows:
o The session key (Ks)
o The other party is A (from IDA)
o The message is from the KDC (because encrypted with Kb)
At this point, the session key has been securely delivered to A and B, and they may begin
communication.
For additional steps:
4. B sends a nonce N2 to A, encrypted using Ks.
5. A responds with f(N2), where f is a transformation (like adding one).
Steps 4 and 5, along with step 3, perform an authentication function.
Key distribution involves steps 1 through 3.

Hierarchical Key Control

 It is not necessary to limit the key distribution function to a single KDC, especially in very large
networks.
 A hierarchy of KDCs can be established as an alternative.
 Example: Local KDCs handle a small domain such as a single LAN or building.
 For communication within the same domain, the local KDC handles key distribution.
 If two entities are in di erent domains, their respective local KDCs communicate through a
global KDC.
 Any one of the three KDCs (two local and one global) can select the session key.
 The hierarchy can be extended to three or more levels, based on user population and network
size.
 This structure reduces the e ort needed for master key distribution since most keys are shared
between local KDCs and users.
 It also limits the damage caused by a faulty or subverted KDC to its local area only.

Session Key Lifetime

 Frequent exchange of session keys increases security, as the attacker has less ciphertext to
analyze per key.
 However, distributing session keys adds delay and uses network resources, a ecting
performance.
 The security manager must balance security and e iciency when deciding the lifetime of a
session key.
  For connection-oriented protocols:
o Use the same session key as long as the connection is open.
o If the connection lasts very long, the key should be changed periodically, e.g., when the
PDU sequence number cycles.
 For connectionless protocols:
o There is no connection setup or end, so key changes are less obvious.
o The most secure method is to use a new key for every exchange.
o But this removes the low-overhead benefit of connectionless communication.
o A better method is to use a fixed session key for a limited time or a set number of
transactions.

Transparent Key Control Scheme

 This scheme provides end-to-end encryption at the network or transport level and is
transparent to end users.
 It is designed for connection-oriented protocols like TCP.
 A Session Security Module (SSM) is used, which handles end-to-end encryption and
requests session keys from the KDC.
 The connection process involves these steps:
1. Host A sends a connection request packet to Host B.
2. SSM intercepts the packet and requests permission from the KDC, using a master key
shared between the SSM and KDC.
3. If approved, the KDC generates a session key and delivers it to both SSMs, using
unique permanent keys.
4. The SSM releases the request, and a connection is established.
All user data is then encrypted using the session key by the respective SSMs.
 ]
Decentralized Key Control (Simplified Line-by-Line)
 Using a KDC (Key Distribution Center) requires that it must be trusted and well-protected.
 This requirement can be avoided by using fully decentralized key distribution.
 Full decentralization is not practical for large networks using only symmetric encryption.
 However, it may be useful in small or local setups.
 In this approach, every system must be able to securely communicate with any other system
to distribute session keys.
 For n systems, up to [n(n - 1)]/2 master keys may be needed.
 The steps to establish a session key are:
1. A sends a request to B, including a nonce N₁.
2. B replies with an encrypted message that includes the session key, B’s ID, f(N₁), and
a new nonce N₂.A sends back f(N₂) to B, encrypted using the new session key.
 So, each node needs to store at most (n - 1) master keys, but can create as many session keys
as nee

Controlling Key Usage (5 Marks)

 Key hierarchies and automated distribution reduce the need for manual key management.

 However, it is important to control how keys are used, especially session keys.

 Based on usage, session keys may be categorized as:

o Data-encrypting key – for general communication

o PIN-encrypting key – for use in transactions like EFT and POS

o File-encrypting key – for securing files in public locations

Solution 1: Key Tagging (Using DES extra bits)

 Tags are added using the 8 non-key bits in a 64-bit DES key.

 Bits indicate:

o If the key is a session or master key

o If it is allowed for encryption or decryption

 Advantages: Tag is encrypted with the key, ensuring security

 Drawbacks: Only 8 bits available, limiting control, Tag is only usable after decryption, limiting
flexibility

Solution 2: Control Vector Method

 A control vector defines rules and restrictions for each session key.

 Control vector is hashed to match the key size, then XORed with the master key to encrypt the
session key.

 At delivery: The control vector is sent in clear ,The session key can be decrypted only using both
the master key and control vector

Advantages:

1. No length restriction → supports complex key control

2. Control vector is in clear form, enabling control at multiple points

SYMMETRIC KEY DISTRIBUTION USING ASYMMETRIC ENCRYPTION

Simple Secret Key Distribution – 5 Marks

 This protocol was proposed by Merkle [MERK79] and is a very basic method of establishing a
secret session key (Kₛ) between two users, A and B.

Protocol Steps:

1. A generates a public/private key pair (PUₐ, PRₐ) and sends PUₐ along with A’s identifier (IDₐ) to
B.

2. B generates a random session key Kₛ and sends it to A, encrypted with A’s public key, i.e.,
E(PUₐ, Kₛ).

3. A decrypts the message using its private key, computing D(PRₐ, E(PUₐ, Kₛ)) to recover Kₛ.

4. After this exchange, both parties discard their key pairs, and can now use the session key Kₛ
to securely communicate with conventional encryption.

5. At the end of the session, Kₛ is also discarded, ensuring no long-term key exists before or after
communication.

Advantages:

 No prior keys are required.

 Keys exist temporarily, reducing risk of compromise.

 The communication is secure against passive eavesdropping.

Man-in-the-Middle (MITM) Vulnerability:

 This protocol is insecure against an attacker who can intercept and alter messages (MITM
attack).
MITM Attack:

1. A sends PUₐ and IDₐ to B, but attacker D intercepts it.

2. D creates its own key pair (PUd, PRd) and sends PUd to B pretending to be A.

3. B encrypts Kₛ using PUd and sends E(PUd, Kₛ).

4. D decrypts using PRd to get Kₛ, and then re-encrypts Kₛ using PUₐ, sending it to A.

5. Now A and B communicate using Kₛ, unaware that D also knows Kₛ and can silently
eavesdrop.

Conclusion:

 While simple and elegant, this scheme is only secure in environments where eavesdropping
is the only threat.

 It fails in hostile networks due to its vulnerability to MITM attacks.

Secret Key Distribution with Confidentiality and Authentication

Figure below, provides protection against both active and passive attacks.

The following steps occur.

1. A uses B’s public key to encrypt a message to B containing an identifier of A (IDₐ) and a nonce
(N₁), which is used to identify this transaction uniquely.

2. B sends a message to A encrypted with PUₐ and containing A’s nonce (N₁) as well as a new nonce
generated by B (N₂). Because only B could have decrypted message (1), the presence of N₁ in
message (2) assures A that the correspondent is B.

3. A returns N₂, encrypted using B’s public key, to assure B that its correspondent is A.

4. A selects a secret key Kₛ, and sends M = E(PUᵦ, E(PRₐ, Kₛ)) to B. Encryption of this message with
B’s public key ensures that only B can read it; encryption with A’s private key ensures that only A
could have sent it.

5. B computes D(PUₐ, D(PRᵦ, M)) to recover the secret key.

The result is that this scheme ensures both confidentiality and authentication in the exchange of
a secret key.
A Hybrid Scheme

 This scheme uses both symmetric and public-key techniques.

 A Key Distribution Center (KDC) shares a secret master key with each user and distributes
session keys encrypted with that master key.

 A public-key method is used only to distribute the master keys.

Rationale for the Hybrid (Three-Level) Approach:

• Performance:

 In many transaction-oriented applications, session keys change often.

 Using public-key encryption for frequent session key exchanges can reduce system
performance due to its high computational cost.

 In this hybrid model, public-key encryption is only used occasionally—to update the master key
between a user and the KDC.

• Backward Compatibility:

 This model can be added on top of existing KDC-based systems with minimal software changes.

 The public-key layer allows secure and e icient distribution of master keys, especially useful in
networks with many distributed users.

Distribution of Public Keys

Several methods exist for distributing public keys, grouped into four main schemes:
1. Public Announcement

 Each user can broadcast their public key openly.

 For example, PGP users may attach their public key in public messages.

 Weakness: Anyone can forge a public announcement.

o An attacker can pretend to be user A and send a fake public key.

o Others might unknowingly send encrypted data to the attacker.

o Until the forgery is discovered, the attacker can read and misuse the messages.

2. Publicly Available Directory

 A trusted entity maintains a dynamic directory with {name, public key} entries.

 Each user registers their public key securely with the authority.

 Users can replace old keys if needed.

 The directory is electronically accessible under secure and authenticated communication.

 Advantage: More secure than public announcement.

 Risk: If the authority’s private key is compromised, an attacker can:

o Distribute fake keys,

o Impersonate users, and

o Eavesdrop on messages.

3. Public-Key Authority
  A central authority holds the directory and has its own public-private key pair.

 Each user knows the authority’s public key.

Steps:

1. A sends a timestamped request to the authority for B’s public key.

2. The authority replies with a message encrypted using its private key containing:

o B’s public key (PUb),

o The original request,

o The timestamp (to prevent replay attacks).

3. A verifies and stores PUb, then sends B an encrypted message using it with A’s ID and a nonce
N₁.
4-5. B obtains A’s public key similarly and uses it to:

4. Reply with an encrypted message containing N₁ and a new nonce N₂.

5. A sends back N₂ encrypted with B’s public key.

 Total messages: 7.

 Caching can be used to save known public keys and reduce repetition.

 Drawbacks:

o The authority may become a bottleneck.

o Its directory is still vulnerable to tampering.

Public-Key Certificates

 Certificates allow participants to exchange public keys without direct contact with a public-key
authority, while still ensuring reliability.

 A certificate contains:

o A public key,
 o The owner’s identity,

o A digital signature by a trusted certificate authority (CA).

 The certificate authority is a trusted third party, like a government or financial institution.

 Users securely submit their public key to the CA and receive a signed certificate.

 Any participant needing someone’s public key:

o Can obtain and read their certificate.

o Can verify it was created by the trusted authority using the CA’s public key.

Requirements:

1. Anyone can read the certificate to get the owner’s name and public key.

2. Anyone can verify that the certificate is genuine and from the CA.

3. Only the certificate authority can create or update certificates.

4. Anyone can check if the certificate is still valid.

Certificate Verification Steps:

 The certificate is encrypted with the CA’s private key (PRₐᵤₜₕ).

 The recipient decrypts it using the CA’s public key (PUₐᵤₜₕ).

 This confirms the certificate’s authenticity.

 It includes:

o IDA (owner’s name),

o PUₐ (owner’s public key),

o T (timestamp).

Purpose of Timestamp:

 Prevents attacks using old compromised certificates.

 If a certificate is too old, it is treated as expired.

 The X.509 standard defines a universal format for certificates.

 X.509 is widely used in TLS, IP security, and S/MIME.

X.509 Certificates

 X.509 is an ITU-T recommendation from the X.500 series, which defines a directory service
storing user info like name-to-address mappings.

 It provides a framework for authentication services via the X.500 directory and serves as a
repository for public-key certificates.

 Each certificate contains a user’s public key, signed by the private key of a trusted certification
authority.

 First issued in 1988; revised in 1993, 1995, and 2000.

 Based on public-key cryptography and digital signatures; hash function use is assumed; RSA is
the recommended algorithm.
Certificates

 The core of the X.509 scheme is the public-key certificate created by a trusted Certification
Authority (CA) and placed in the directory by the CA or user.

 The directory only stores certificates; it does not create public keys or perform certification.

 The general format of a certificate includes:

1. Version: Identifies format version;

o v1: default,

o v2: includes issuer/subject unique IDs,

o v3: includes extensions.

2. Serial Number: Unique integer per certificate from issuing CA.

3. Signature Algorithm ID: Algorithm and parameters used for signing.

4. Issuer Name: X.500 name of the CA that issued the certificate.

5. Period of Validity: Start and end dates of certificate validity.

6. Subject Name: X.500 name of the certificate holder (public key owner).

7. Subject's Public Key Info: Public key, usage algorithm, and parameters.

8. Issuer Unique ID (optional): Bit string to uniquely identify the CA.

9. Subject Unique ID (optional): Bit string to uniquely identify the subject.

10. Extensions: Extra fields (v3 only) for additional certificate attributes.

11. Signature: Hash of all fields encrypted with CA's private key, includes signature algorithm ID.

The standard uses the following notation to define a certificate:

CA V A W = CA {V, SN, AI, CA, UCA, A, UA, Ap, TA}
Where:
 Y VXW = the certificate of user X issued by certification authority Y
 Y {I} = the signing of I by Y. It consists of I with an encrypted hash code appended
 V = version of the certificate
 SN = serial number of the certificate
 AI = identifier of the algorithm used to sign the certificate
 CA = name of certificate authority
 UCA = optional unique identifier of the CA
 A = name of user A
 UA = optional unique identifier of the user A
 Ap = public key of user A
 TA = period of validity of the certificate
Obtaining a User’s Certificate

 Certificates signed by a trusted CA allow any user with the CA’s public key to verify another user’s
public key securely.

 Since certificates are unforgeable, they can be placed in directories without requiring
protection.

 If all users trust the same CA, they can easily obtain each other’s certificates from the directory
or via direct exchange.

 In large communities with multiple CAs, users may not trust the same CA. Hence, certificate
chains are used.

 Suppose A has a certificate from CA X1 and B from CA X2:

o A obtains X2’s certificate signed by X1 using X1’s public key.

o A then gets B’s certificate signed by X2.

o This enables A to verify B’s public key through the chain: X1 ⟶ X2 ⟶ B.

 Similarly, B can get A’s public key using the reverse chain: X2 ⟶ X1 ⟶ A.

 Chains can include more than two CAs, e.g., X1 ⟶ X2 ⟶ X3 ⟶ ... ⟶ B.

 X.509 recommends a hierarchy of CAs for simpler certificate path discovery.

  Each CA’s directory contains:

o Forward certificates: Certificates of the CA issued by others.

o Reverse certificates: Certificates issued by the CA to other CAs.

Revocation of Certificates

 Each X.509 certificate has a validity period (like a credit card).

Normally, a new certificate is issued before the current one expires.

 Early revocation may be required in the following cases:

1. The user's private key is believed to be compromised.

2. The user is no longer certified by the CA (e.g., name change, policy violation, certificate
error).

3. The CA's own certificate is assumed to be compromised.

 Each Certification Authority (CA) must maintain a list of revoked but not expired certificates,
called a Certificate Revocation List (CRL).

 The CRL is posted in the public directory, digitally signed by the issuing CA, and includes the CA’s
name, issue date of the CRL, next update date, and a list of revoked certificates with their unique
serial numbers and revocation dates.

 When a user receives a certificate, it must check the CRL to verify if the certificate is revoked.
 To avoid delays in checking the directory, users may maintain a local cache of certificates and
CRLs. (draw above page 18 diagram b)
X.509 Version 3

 X.509 Version 2 lacks necessary information for modern design and implementation.
 Limitations of Version 2:
1. Subject field is too short to clearly identify the key owner.
2. It does not support identification via email, URL, or internet-related formats.
3. Cannot indicate security policy information required by functions like IPSec.
4. Lacks constraints to limit the impact of a faulty or malicious CA.
5. Cannot distinguish different keys used by the same owner at different times (needed for key
lifecycle management).
 To solve these issues, a more flexible approach was adopted in Version 3:
o It adds optional extensions to the Version 2 format.
o Each extension contains:
 an extension identifier,
 a criticality indicator, and
 an extension value.
o If the criticality indicator is TRUE, and the extension is unrecognized, the certificate must
be treated as invalid.

Certificate Extensions (X.509 v3) fall into three categories:

1. Key and Policy Information

2. Subject and Issuer Attributes

3. Certification Path Constraints

1. Key and Policy Information

These convey extra info about subject/issuer keys and certificate policies.

 Certificate policy: Rules that define certificate use for a group or app (e.g., EDI transactions
within a price range).

Includes:

 Authority key identifier: Identifies the public key for verifying this certificate or CRL;
distinguishes CA keys.

 Subject key identifier: Identifies the public key being certified; useful for key updates or
multiple purposes (e.g., signing, encryption).

 Key usage: Lists purposes allowed: digital signature, key/data encryption, key agreement,
nonrepudiation, CA signature verifications.

 Private-key usage period: Specifies valid time for using private key (often shorter than the
public key’s validity).

 Certificate policies: Lists policies the certificate supports, with optional qualifiers.

 Policy mappings: (For CA certificates) Maps issuer policies to equivalent subject CA policies.
2. Subject and Issuer Attributes

Provide alternative names and extra details for identification.

Includes:

 Subject alternative name: Alternate identifiers (e.g., email, IP address, DNS) for the subject.

 Issuer alternative name: Alternate identifiers for the issuer.

 Subject directory attributes: Extra X.500 attributes like address, job title, or image to aid user
confidence.

3. Certification Path Constraints

These limit or control certificate issuance down a certification chain.

Includes:

 Basic constraints: Indicates if subject is a CA; may include path length limit.

 Name constraints: Limits namespace for subject names in later certificates.

 Policy constraints: May enforce policy ID use or inhibit policy mapping along the chain.

PKIX Model (Based on X.509)

PKIX is a widely adopted model for deploying certificate-based architectures on the Internet. It defines
the following key elements:

 End Entity:

o Can be users, devices, or any identifiable entity.

o Uses or supports PKI-related services.

 Certification Authority (CA):

o Issues certificates and usually Certificate Revocation Lists (CRLs).

o May handle admin tasks or delegate to other components.

 Registration Authority (RA):

o Optional component that helps with administrative functions like end entity registration.

o Works on behalf of the CA.

 CRL Issuer:

o Optional component delegated by the CA to publish revocation lists.

 Repository:

o Any storage system (e.g., database, directory) that allows users to retrieve certificates
and CRLs.
PKIX Management Functions:

1. Registration:

o Initial step where a user registers with a CA (directly or via RA).

o Involves authentication and enrollment into PKI.

2. Initialization:

o Client systems are initialized with trusted CA public keys and required info.

o Ensures secure certificate validation.

3. Certification:

o CA issues certificates for a user's public key and either returns it to the user or stores it in
a public repository.

4. Key Pair Recovery:

o Mechanism to restore lost decryption keys from a backup.

o Handles forgotten credentials or hardware failures.

5. Key Pair Update:

o Old key pairs are replaced with new ones and certificates are renewed.

o Necessary upon expiration or revocation.

6. Revocation Request:

o CA is notified of a need to revoke a certificate.

 o Possible reasons: key compromise, name change, or role change.

7. Cross Certification:

o Two CAs certify each other’s public keys.

o Enables interoperability between separate PKIs.

PKIX Management Protocols:

1. Certificate Management Protocol (CMP):

o Flexible protocol supporting various PKI models.

o Manages enrollment, renewal, revocation, and other operations.

2. Certificate Management over CMS (CMC):

o Built on Cryptographic Message Syntax (CMS).

o Defines request/response messages for certificate handling.

o Ensures compatibility and secure communication among PKI entities.