MODULE 3

Key management fundamentals

Key management is the process of creating, storing, distributing, using, and disposing of
cryptographic keys securely.

Cryptographic keys are used to encrypt and decrypt data to ensure confidentiality, integrity,
and authentication.

Cryptographic keys are used to encrypt and decrypt data to ensure confidentiality, integrity, and
authentication.

Key management is critical for secure encryption. Without proper key management, even
the strongest encryption becomes useless. A good key management system ensures:

 Keys are secure

 Access is controlled
 Lifecycle is managed properly

Main Goals of Key Management

1. Confidentiality – Keep the key secret from unauthorized people.

2. Integrity – Ensure the key is not changed or tampered with.
3. Availability – The key should be available when needed.
4. Authentication – Ensure the key belongs to the right person/system.

Types of Cryptographic Keys

Type Description Example Use

Symmetric
Same key for encryption and decryption AES
Key

Asymmetric
Uses key pair: Public + Private key RSA, ECC
Key

Key Lifecycle (Key Management Phases)

1. Key Generation
o Keys are created using secure algorithms.
o Must use good randomness.
2. Key Distribution
o Share the key with authorized users securely.
o For symmetric keys, this is a big challenge.
3. Key Storage
o Store keys in a secure place:
🔸 Hardware Security Module (HSM)
🔸 Encrypted software vault
🔸 Secure keychain (in apps)
4. Key Usage
o Use the key to encrypt/decrypt data, sign, verify, etc.
o Should happen in a controlled environment.
 5. Key Rotation
o Periodically change keys to reduce risk.
o Old keys are archived or destroyed.
6. Key Expiry and Revocation
o Keys should have an expiry date.
o Revoke keys if compromised or no longer needed.
7. Key Destruction
o Securely delete keys when no longer in use.
o Prevent recovery by any means.

Key Management Tools & Technologies

 KMS (Key Management Service) – AWS KMS, Azure Key Vault, Google KMS
 HSM (Hardware Security Module) – Secure hardware device for key storage
 PKI (Public Key Infrastructure) – Manages certificates and key pairs

Key Lengths and Lifetimes

Key Lengths:

Key length (also referred to as key size) is the number of bits used in a cryptographic key. The
security of most cryptographic algorithms depends on the key length — longer keys are harder
to break via brute-force attacks, but they also require more computational power and memory.

Common Algorithms and Recommended Key Lengths

Minimum Recommended Key
Algorithm Type Security Level
Length

AES Symmetric 128, 192, or 256 bits High

RSA Asymmetric 2048 bits (3072–4096 preferred) Moderate-High

ECC (e.g., ECDSA, Very High (per

Asymmetric 256 bits (P-256 or P-384)
ECDH) bit)

Note: As computing power increases, the required key lengths for secure encryption also increase.

Trade-Offs

 Security vs Performance: Longer keys improve security but slow down encryption/decryption
processes.
 Compatibility: Not all systems support extremely long keys.

Example:

 AES-256 is commonly used in military-grade and financial applications.

 RSA-2048 is used in most SSL/TLS certificates for websites.
 ECC-P256 is used in mobile devices for faster, efficient secure communications.

Key Lifetimes
Key lifetime refers to how long a key should be used before it must be rotated or retired.
 Factors Affecting Key Lifetime:

 Sensitivity of data being protected

 Volume of data encrypted with the key
 Exposure to threats
 Regulatory and compliance requirements

Typical Key Lifetimes:

Key Type Typical Lifetime

Symmetric Session Keys Minutes to Hours

Symmetric Master Keys Weeks to Months

Asymmetric Public/Private Keys 1 to 3 Years

Root Certificate Keys 10 to 25 Years

Example: Symmetric Session Key: Secure web session (TLS/HTTPS)

Temporary key used for one browser session, e.g., when you log in to an online banking
website. Key is discarded after session ends.

Key Generation
Definition:

Key generation is the process of creating cryptographic keys using secure algorithms and
sufficient randomness.

Key Requirements:

 Must be generated using a Cryptographically Secure Pseudo-Random Number Generator

(CSPRNG).
 The algorithm used must be approved by recognized standards (e.g., NIST, ISO).
 The key must be unique, non-predictable, and fit for purpose (encryption, signing, etc.).

Key Generation Techniques:

 Symmetric Keys: Generated randomly using CSPRNG.

 Asymmetric Key Pairs: Generated using mathematical algorithms (e.g., RSA, ECC).
 y2=x3+ax+b (mod p)

Tools:

 OpenSSL (Software: Open Secure Sockets Layer)

 Hardware Security Modules (HSMs) (Hardware)
 Cloud KMS platforms (AWS KMS, Azure Key Vault, Google Cloud KMS)

Example:

Generate a 256-bit AES key using a cryptographically secure random number generator.
Tool:

 OpenSSL (command-line tool)

Command: # Generate a 256-bit (32 bytes) AES key in hexadecimal format (openssl rand -hex 32)

Output Example:
9f2c4e8d391afc81a09e3e9f99aa08c6e8b8491eae3e37f6c23f14d7384e782f

Key Establishment
Definition:

Key establishment refers to the process of securely distributing or agreeing upon cryptographic
keys between two or more parties.

There are two major approaches:

Key Transport:

 One party generates the key and transmits it securely to the other.
 Usually done using asymmetric encryption.
 Example: RSA encryption used to send a symmetric key.

Key Agreement:

 Both parties contribute to the generation of a shared key.

 The key is never transmitted; it is derived independently at both ends.
 Example: Diffie-Hellman (DH) or Elliptic Curve Diffie-Hellman (ECDH).

Mathematics involved:

 Diffie–Hellman Key Exchange:

o Based on the discrete logarithm problem:

 𝑔𝑎 mod p and 𝑔𝑏 mod p => 𝑔𝑎𝑏 mod p

Example Use Case:

In TLS (HTTPS):

 A server and client use ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) for key
agreement.
 A session key is established and used for AES encryption during the web session.

Key establishment must ensure confidentiality, authenticity, and integrity of the keys exchanged.

Example in real life:

 When you connect to a WPA2 Wi-Fi network, your device and router share a PSK (your Wi-Fi
password).
 Both sides use this key to encrypt and decrypt data to keep your connection secure.
Key Storage

Key storage is the secure preservation of cryptographic keys to prevent unauthorized access,
modification, or loss.

Storage Options:
Storage Method Description

Hardware Security Modules Physical devices that securely generate, store, and use keys within a tamper-
(HSMs) proof environment.

Secure files or databases (e.g., Java KeyStore, Windows DPAPI) with

Software Key Stores
encryption and access control.

Managed services that offer secure key generation, storage, and rotation (e.g.,
Cloud KMS
AWS KMS, Azure Key Vault).

Key Storage Best Practices:

 Encrypt keys at rest using other keys (Key Encryption Keys - KEK).
 Apply strict access controls (role-based access).
 Separate keys from encrypted data.
 Enable logging and auditing of all key accesses.

Example:

A financial application stores AES (Advanced Encryption Standard) keys in an HSM (Hardware
Security Module) and uses a separate key to encrypt customer data. Only the application server has
access to the key via a secure API call.

Key Usage

Key usage refers to how cryptographic keys are applied in operations such as:

 Encryption / Decryption
 Digital Signing / Verification
 Authentication
 Key Wrapping / Unwrapping

Each key should have defined usage permissions and be used only for its intended purpose.

Examples of Key Usage Flags (in X.509 certificates):

 keyEncipherment
 digitalSignature
 keyAgreement
 dataEncipherment

Best Practices:

 Implement the principle of least privilege: Only authorized systems or users should access
specific keys.
  Avoid key reuse across systems or different purposes.
 Log and monitor all key usage.
 Apply FIPS 140-2(Federal Information Processing Standard Publication 140-2) or FIPS 140-3
validated cryptographic modules when required.

Governing Key Management

Governing key management involves establishing and enforcing policies, procedures, roles, and
controls that define how cryptographic keys are managed throughout their lifecycle.

Key Governance Components:

Component Description

Documents organizational rules for key generation, storage, rotation, and

Key Management Policy
destruction.

Roles and Responsibilities Clearly defined roles for key custodians, security admins, auditors, etc.

Key Lifecycle
Procedures to manage keys from creation to destruction.
Management

Access Controls Enforce least-privilege access to key material.

Audit and Monitoring Record all key-related events and access attempts.

Compliance Requirements Align with standards such as NIST, ISO/IEC 27001, PCI-DSS, HIPAA, GDPR.

Incident Response Define steps to take if a key is suspected to be compromised.

Public-Key Management

Public-Key Cryptography forms the foundation of modern secure communication systems. Proper
management of public and private keys is essential to ensure the integrity, confidentiality, and
authenticity of digital communication.

Public-Key Management refers to the methods and systems used to securely distribute, verify, and
manage public keys in a cryptographic system.

This topic is broadly divided into the following areas:

1. Certification of Public Keys

2. Certificate Lifecycle
3. Public-Key Management Models
4. Alternative Approaches to Key Management
1. Certification of Public Keys
Need for Certification

In Public-Key Cryptography, each user or entity has a pair of cryptographic keys: a public key
(which is openly shared) and a private key (which is kept secret). For the system to work securely,
users must be confident that a public key truly belongs to the individual or organization claiming it.

Digital Certificates

A digital certificate is an electronic document used to prove ownership of a public key. It includes
identifying information and is digitally signed by a trusted entity known as a Certificate Authority
(CA).

1. Components of a Digital Certificate (e.g., X.509 format):

 Subject Name – The identity of the user, system, or organization (e.g., domain name, person’s
name).
 Subject’s Public Key – The public key being certified.
 Serial Number – A unique identifier assigned by the CA.
 Issuer – The name of the CA issuing the certificate.
 Validity Period – Start and end date of the certificate’s validity.
 Signature Algorithm – The algorithm used to sign the certificate.
 CA’s Digital Signature – A signature over the certificate data using the CA’s private key.

Certificate Authority (CA)

A Certificate Authority is a trusted third party that is responsible for:

 Verifying the identity of entities requesting certificates.

 Issuing, signing, and revoking certificates.
 Maintaining a secure infrastructure to protect its own keys.

Examples of well-known CAs include DigiCert, Let’s Encrypt, GlobalSign, etc.

🔹 Certificate Signing Process

1. The entity creates a key pair (public and private).

2. It creates a Certificate Signing Request (CSR) containing the public key and identifying
information.
3. The CSR is submitted to a CA.
4. The CA verifies the identity of the applicant (e.g., through domain ownership, documentation).
5. The CA issues a signed certificate that binds the identity to the public key.

2. Certificate Lifecycle

A public key certificate goes through several stages during its lifetime. Understanding this lifecycle
helps ensure proper handling, usage, and revocation of certificates.
1. Certificate Creation and Issuance

 The user generates a key pair (public and private key).

 A Certificate Signing Request (CSR) is generated and sent to a CA.
 The CA performs necessary identity verification.
 Once verified, the CA signs and issues the certificate.

The issued certificate can now be shared with others, who can trust it based on the CA’s signature.

2. Certificate Usage

 The certificate is used in secure communications.

 Examples:
o SSL/TLS – Website uses a certificate to establish secure HTTPS connections.
o Email encryption – Certificates ensure secure email via S/MIME.
o Digital signatures – Ensure message authenticity and integrity.

The recipient of a message or connection request verifies the certificate and checks:

 It is issued by a trusted CA.

 It has not expired.
 It has not been revoked.
 It matches the domain or identity it claims.

3. Certificate Expiry

 All certificates are valid only for a specific period.

 Typical duration: 1 to 2 years (Let’s Encrypt issues 90-day certificates).
 After expiry, the certificate is no longer trusted and must be renewed or replaced.

4. Certificate Revocation

Sometimes a certificate must be revoked before its expiry date, such as when:

 The private key is compromised or lost.

 The user’s identity has changed.
 There was a mistake in the certificate.
 The CA is no longer trusted.

Revocation is essential to prevent misuse of invalid or compromised certificates.

5. Revocation Mechanisms
a. Certificate Revocation List (CRL):

 A list of revoked certificates published by the CA.

 Regularly updated and distributed.
 Clients check CRL to see if a certificate has been revoked.
 Peer-to-Peer Trust Models

 Every entity is equally responsible for key management.

 Trust decisions are made locally.
 Suitable for small groups or ad hoc networks.

Real-time protocol to query the revocation status of a certificate.

 More efficient and timely than downloading full CRLs.

3. Public-Key Management Models

Public-key management models define how trust is established and maintained between entities.

🔹 1. Hierarchical Trust Model

 This is the most widely used model, especially in web security.

 Involves a Root Certificate Authority (Root CA) that is universally trusted.
 Intermediate CAs are certified by the Root CA, creating a chain of trust.
 End-entity certificates are issued by intermediate or leaf CAs.
 e.g., [Link]
 Issued by the Intermediate CA.
 Used by the actual website to establish secure HTTPS connections.

Why It’s Hierarchical:

 Trust is passed down from the Root CA → Intermediate CA → End-Entity Certificate.

 If the root is trusted, and each link in the chain is valid, the end certificate is trusted.

2. Advantages:

 Structured and scalable.

 Clear trust relationships.
 Efficient certificate management and revocation.

3. Disadvantages:
 Single point of failure – Compromise of Root CA breaks the entire trust chain.
 Complex and costly to manage at scale.

2. Web of Trust

 Popularized by PGP (Pretty Good Privacy).

 There is no central authority.
 Users sign each other’s keys based on personal trust.
 Trust is transitive – if you trust Alice and Alice trusts Bob, you may trust Bob.
4. Advantages:

 Fully decentralized.
 Suitable for small communities or informal groups.

5. Disadvantages:

 Not scalable.
 Complex trust evaluation.
 Not suitable for commercial or enterprise use.

🔹 3. Bridge CA Model

 Used to connect multiple PKIs (Public Key Infrastructure) together.

 A Bridge CA acts as a neutral party, allowing separate PKIs to interoperate.
 Common in government or cross-organization scenarios.

4. Mesh or Cross-Certification

 Each CA directly certifies other trusted CAs.

 No central root; instead, CAs cross-certify one another.

Pros:

 Flexible and fault-tolerant.

 Decentralized model.

Cons:

 Complex trust relationships.

 Harder to manage revocations and updates.

4. Alternative Approaches to Public-Key Management

With growing concerns over traditional PKI (e.g., centralization, trust issues), several alternative
models have emerged.

🔹 1. Blockchain-Based PKI

 Uses blockchain as a tamper-proof ledger to store public keys and certificates.

 Examples: Namecoin, Ethereum-based identity systems, CertCoin.

6. Advantages:

 Decentralized trust.
 Resistant to tampering and fraud.
 Transparent and auditable.
7. Disadvantages:

 High computational and storage overhead.

 Scalability issues.
 Dependency on blockchain infrastructure.

🔹 2. DANE (DNS-Based Authentication of Named Entities)

 DANE is an internet security protocol that allows digital certificates (e.g., for HTTPS, email)
to be securely published in DNS using DNSSEC (Domain Name System Security Extensions).
 Ties public keys to DNS names using DNSSEC.
 Certificates or public keys are stored in DNS records (TLSA records).

DANE Is Used For:

 HTTPS: Validating website certificates without relying solely on third-party CAs.

 Email Security: DANE + SMTP helps ensure mail is encrypted and sent to the correct server.
 XMPP, SIP, and other TLS-based protocols.

8. Advantages:

 Reduces reliance on third-party CAs.

 Securely binds identity and public key at the DNS level.

9. Disadvantages:

 Requires DNSSEC support.

 Adoption still limited.

🔹 3. Identity-Based Encryption (IBE)

 Identity-Based Encryption (IBE) is a type of public-key encryption where a user's public

key is derived directly from a unique identifier such as their email address, phone number, or
username. This means that instead of generating and distributing a traditional public key, users
can use their identity as their public key.
 In IBE, the public key is derived from a known identifier, such as an email address.
 A trusted Private Key Generator (PKG) issues the corresponding private key.

10. Advantages:

 No need to distribute public keys.

 Simplified key management.

11. Disadvantages:

 PKG must be trusted completely.

 Key escrow problem – PKG can decrypt all messages.
 Not widely used in practice due to security concerns.
 4. Certificate Pinning

 Applications or browsers store the expected public key or certificate of a server.

 If the certificate presented during communication doesn’t match, the connection is blocked.

12. Advantages:

 Prevents MITM attacks via rogue CAs.( A malicious or compromised CA that issues fake
certificates to impersonate websites or services.)

 Increases security for high-value apps (e.g., banking).

13. Disadvantages:

 Hard to manage and update pins.

 Can lead to failures if pins are outdated.