Key Management and Public Key Infrastructure

Introduction

Cryptography is effective only when cryptographic keys are protected throughout their entire life cycle. Strong algorithms cannot compensate for a stolen private key, an expired certificate, an unrecoverable encryption key, or an uncontrolled administrator account. Key management therefore connects cryptographic theory with operational security. It includes generating, registering, distributing, storing, using, rotating, backing up, recovering, revoking, archiving, and destroying keys.

Public Key Infrastructure (PKI) provides the organisational and technical framework for managing public-key identities. It uses certificate authorities, digital certificates, registration processes, validation rules, revocation mechanisms, and trust policies to support secure communication and authentication. PKI is used in web security, virtual private networks, secure email, software signing, identity cards, cloud services, and enterprise access control.

This chapter presents the key lifecycle and explains how PKI establishes trust without requiring every communicating party to meet in advance.

Learning Objectives

By the end of this chapter, a learner should be able to:

• describe the cryptographic key lifecycle;
• distinguish symmetric keys, public keys, private keys, and certificates;
• explain the roles of certificate authorities and registration authorities;
• validate certificate chains and identify common trust failures;
• compare certificate revocation lists and the Online Certificate Status Protocol;
• explain the role of hardware security modules;
• design practical procedures for key rotation, backup, recovery, escrow, and destruction;
• evaluate governance, operational, and ethical risks in key management.

1. The Key Management Problem

A cryptographic key is sensitive information whose secrecy, authenticity, integrity, availability, and correct use must be controlled. Key management is broader than key storage. It includes policy, people, processes, technology, and audit evidence.

The main security objectives are:

A useful distinction is between cryptographic compromise and administrative compromise. Cryptographic compromise occurs when an attacker obtains or derives a key. Administrative compromise occurs when a legitimate key is misused, such as when an operator signs an unauthorised certificate or decrypts information without proper authority.

2. Types of Cryptographic Keys

Symmetric keys

A symmetric key is used by the same cryptographic system for encryption and decryption, or for related operations such as message authentication. Symmetric cryptography is efficient and suitable for bulk data. Its principal management difficulty is secure distribution: communicating parties need access to the same secret without exposing it.

Examples include keys used by authenticated encryption algorithms such as AES-GCM or ChaCha20-Poly1305. A unique nonce or initialization value is normally required for each encryption operation, according to the algorithm’s rules. Nonces are not necessarily secret, but accidental reuse can seriously weaken security.

Public and private keys

An asymmetric key pair contains a public key and a mathematically related private key. The public key may be distributed openly; the private key must be protected. Depending on the algorithm, a public key may be used to verify signatures or encrypt data, while the private key is used to create signatures or decrypt data.

Public-key cryptography reduces the key-distribution problem but introduces an identity problem: how can a user know that a public key actually belongs to the claimed subject? Certificates and PKI address this problem.

Key-encryption keys and data-encryption keys

A data-encryption key (DEK) encrypts application data. A key-encryption key (KEK) protects another key, commonly by encrypting the DEK. This hierarchy limits exposure and simplifies rotation. For example, many database records may use separate DEKs, while a centrally controlled KEK protects those DEKs.

Signing, encryption, and authentication keys

Keys should have a defined purpose. A signing key should not normally be reused for encryption, and an encryption key should not normally be used to sign documents. Separating purposes reduces the consequences of compromise and makes policy enforcement clearer. Certificates often express key usage constraints through extensions such as Key Usage and Extended Key Usage.

3. The Cryptographic Key Lifecycle

A professional lifecycle normally contains the following stages:

1. Planning and policy – Define purpose, algorithm, permitted use, ownership, retention, recovery, and destruction requirements.
2. Generation – Generate keys using approved algorithms, secure random-number generation, and trusted equipment.
3. Registration and association – Record the owner, system, purpose, validity period, and identifier. For public keys, establish the subject’s identity.
4. Distribution or installation – Deliver keys through authenticated and protected channels. Private keys should not be transmitted unnecessarily.
5. Activation and use – Enforce authorised uses, usage limits, separation of duties, and logging.
6. Rotation or renewal – Replace keys before expiry or when policy, risk, or cryptographic developments require it.
7. Suspension or revocation – Stop trust in a key when it is compromised, misused, or no longer associated with its subject.
8. Archival and recovery – Retain keys only when required for lawful access, historical verification, or decryption of retained data.
9. Destruction – Securely erase key material and verify that recoverable copies do not remain.

A key’s status should be explicit. Typical states include generated, pending activation, active, suspended, revoked, expired, archived, and destroyed. Status transitions should be authorised and auditable.

Key generation

Generation should occur in a trusted cryptographic module or operating environment using a cryptographically secure random number generator. Predictable random values can make apparently strong keys guessable. Generation procedures should define algorithm, key size or security level, intended use, owner, creation date, and expiry date.

Keys should not be generated by copying a template value, using a human-chosen password as raw key material, or relying on an ordinary pseudo-random function. Password-based keys require a password-based key derivation function with a salt and an appropriate work factor.

Distribution and installation

Key distribution depends on the key type. A public key can be published, but its authenticity must be established. A symmetric key or private key requires confidentiality and integrity during transport. Suitable mechanisms include authenticated key-wrapping, secure provisioning channels, and hardware-backed enrolment.

A key should be installed only on an identified device or service. The installation record should identify the recipient, approving authority, time, method, and resulting key status.

Rotation and renewal

Rotation replaces a key, generally because of time, usage volume, policy, or risk. Renewal often means issuing a new certificate or extending a service relationship, possibly with a new key. Rotation limits the amount of information protected by one key and reduces the time available for an attacker to exploit a compromise.

Rotation intervals should be risk-based. Important factors include algorithm strength, exposure, data sensitivity, number of users, volume of protected data, compromise indicators, regulatory requirements, and operational cost. Rotation must include a transition plan: new encryption, decryption of older data, certificate deployment, rollback, and retirement of the old key.

Backup and recovery

A backup of a key is itself sensitive key material. Backups should be encrypted or held in a protected hardware or escrow system, access should require authorisation, and restoration should be tested. A backup that has never been restored is only an assumption of recoverability.

Recovery procedures should specify who approves recovery, how identity is verified, how access is divided among personnel, how the event is logged, and when recovered keys are returned to protected storage. Recovery must not become an uncontrolled method of bypassing normal access controls.

4. Public Key Infrastructure

PKI is a system of policies, roles, procedures, hardware, software, and certificates used to manage public keys and digital identities. Its principal components are:

• Certificate Authority (CA): issues, signs, renews, and revokes certificates.
• Registration Authority (RA): verifies identity and approves or rejects certificate requests on behalf of a CA.
• Certificate repository: publishes certificates and, where applicable, revocation information.
• Relying party: uses a certificate and decides whether to trust the subject’s public key.
• Certificate policy and certification practice statement: define what the PKI promises, how identity is verified, and how operations are controlled.

A CA does not magically prove that a person or server is trustworthy in every sense. It asserts that, according to its policy, a particular public key is associated with a named subject. Relying parties must still evaluate whether that subject is authorised for the intended transaction.

Root and subordinate CAs

A root CA is a trust anchor whose public key is distributed through a trusted mechanism, such as an operating-system or browser trust store. A root may issue certificates directly, but it commonly signs one or more subordinate or intermediate CAs. Intermediate CAs issue end-entity certificates for servers, people, devices, or software.

This hierarchy limits exposure of the root private key. The root can remain offline and be used rarely, while an intermediate CA performs routine issuance. If an intermediate CA is compromised, it can be revoked without necessarily replacing every root trust anchor.

Digital certificates

A digital certificate binds a subject identity to a public key through a CA’s digital signature. Modern Internet certificates commonly follow the X.509 format. Important fields include:

• subject and issuer names;
• subject public-key information;
• serial number;
• validity period;
• signature algorithm and CA signature;
• Basic Constraints;
• Key Usage and Extended Key Usage;
• Subject Alternative Name;
• Authority Key Identifier;
• revocation-information locations.

The Subject Alternative Name is particularly important for modern TLS hostname validation. A certificate’s common name alone is not sufficient where the applicable validation rules require a matching SAN entry.

5. Trust Chains and Certificate Validation

A certificate chain normally consists of an end-entity certificate, zero or more intermediate certificates, and a trusted root. The end-entity certificate is validated using the issuer’s public key; the intermediate is validated by its issuer; and the final issuer must terminate at a locally trusted root.

Validation should include at least:

1. signature verification for each certificate;
2. validity-period checking using reliable time;
3. chain construction to an accepted trust anchor;
4. Basic Constraints and path-length checking for CA certificates;
5. Key Usage and Extended Key Usage checking;
6. subject-name or SAN matching for the intended service;
7. revocation-status checking where required or supported;
8. algorithm and policy compliance;
9. prevention of unacceptable name constraints or policy violations.

A valid signature alone is insufficient. An attacker may present a correctly signed certificate for a different hostname, an expired certificate, or a certificate issued for a purpose unrelated to the transaction.

A simplified trust decision can be represented as:

Here, ∧ means logical AND. The expression is a conceptual model, not a complete standards implementation. A relying party should accept a certificate only when every applicable condition is satisfied.

Certificate issuance process

A typical process is:

1. A subject generates a key pair, preferably locally so the private key need not leave the subject’s environment.
2. The subject creates a certificate signing request containing a public key and requested identity information.
3. The RA or CA verifies identity and authorisation.
4. The CA applies policy, generates a serial number, sets extensions and validity, and signs the certificate.
5. The certificate is delivered or published.
6. The subject installs it with the corresponding private key.
7. Relying parties validate the chain and status during use.

Private keys should not be included in certificate signing requests. The request contains the public key and a proof of possession, normally a signature made with the corresponding private key.

6. Revocation and Status Checking

A certificate may need revocation before its scheduled expiry. Reasons include private-key compromise, inaccurate identity information, unauthorised use, or termination of the subject’s relationship with the organisation.

A Certificate Revocation List (CRL) is a signed list containing revoked certificate serial numbers and related dates. CRLs can be large and may not provide the most current status if they are published periodically.

The Online Certificate Status Protocol (OCSP) allows a client to request the status of a certificate, commonly receiving a response such as good, revoked, or unknown. OCSP can provide fresher information, but it introduces availability, privacy, and responder-trust considerations. Some systems use OCSP stapling, in which the server supplies a recent signed status response during a TLS connection.

Revocation checking has difficult operational trade-offs. If a status service is unavailable, strict failure can block legitimate services, while soft failure can allow use of a compromised certificate. The correct approach depends on risk, policy, protocol requirements, and the consequences of false acceptance or false rejection.

7. Hardware Security Modules

A Hardware Security Module (HSM) is a specialised device that generates, stores, and uses cryptographic keys while limiting exposure of private key material. HSMs may provide tamper resistance, authenticated administration, secure backup functions, role separation, audit logging, and cryptographic acceleration.

Common uses include protecting CA signing keys, payment keys, code-signing keys, database master keys, and cloud service root keys. An HSM does not eliminate all risk. Misconfigured access policies, compromised authorised applications, poor backup procedures, and insecure administrator ceremonies can still cause serious incidents.

Important HSM controls include:

• dual control, requiring two or more authorised people for sensitive operations;
• split knowledge, ensuring no single person knows an entire backup or activation secret;
• least privilege for operators and applications;
• tamper detection and appropriate response;
• independent audit logs;
• tested disaster recovery;
• secure firmware and configuration management.

An HSM should be selected according to the required algorithms, performance, certification, availability architecture, integration interfaces, geographic resilience, and operational skill of the organisation.

8. Escrow, Archival, and Secure Destruction

Key escrow places a key or a recovery capability under the control of a designated trusted party. Escrow may support business continuity, legal obligations, or recovery of encrypted organisational records. It also creates a high-value target and can weaken confidentiality if access is too broad.

Escrow should therefore be governed by documented authority, purpose limitation, multi-person approval, evidence preservation, access logging, periodic review, and a defined end date. Escrow is generally more suitable for selected encryption keys than for signing keys, because uncontrolled recovery of a signing key could enable fraudulent signatures.

Archival preserves keys needed to validate historical signatures or decrypt retained data. Archived keys should be inaccessible for ordinary operational use and should have clear retention and retrieval rules.

Secure destruction means rendering key material unusable and removing recoverable copies from active systems, backups, caches, logs, test environments, and removable media. For hardware, approved sanitisation or physical destruction may be required. Destruction should produce an auditable record identifying the key, authority, method, date, and verification result.

9. Governance, Ethics, and Professional Practice

Key management is a governance responsibility, not merely an engineering task. An organisation should maintain a key-management policy, certificate policy, incident-response procedure, and documented responsibilities. Separation of duties is particularly important: the person requesting a certificate should not be the sole person approving identity, issuing the certificate, and auditing the event.

Privacy must also be considered. Certificate subject names, email addresses, device identifiers, and OCSP requests may reveal personal or operational information. Organisations should collect only necessary identity data and protect certificate databases and logs.

Legal requirements may affect retention, lawful access, electronic signatures, data protection, sector-specific controls, and cross-border transfer. A technical recovery mechanism should not be introduced solely because it is convenient; its proportionality, authorisation, transparency, and abuse resistance must be assessed.

Artificial intelligence can assist with certificate inventory, anomaly detection, expiry prediction, and identification of unusual issuance patterns. It should not independently approve sensitive certificate requests or revoke production identities without controlled authorisation. Automated recommendations require explainability, reliable data, human oversight, and a safe rollback process.

10. Illustrative Case: Certificate Failure in a Managed Service

Background

A fictional online retailer operates customer-facing web services, internal APIs, and a payment-processing gateway. Its certificates are issued by an intermediate CA. The organisation has several hundred certificates but no complete inventory.

Problem

A TLS certificate for a payment API expires during a weekend. Monitoring detects the failure only after transactions begin to fail. Investigation also discovers that an old private key remains in a backup directory accessible to several administrators.

Analysis

The immediate issue is certificate expiry, but the underlying problem is weak lifecycle governance. There is no single owner for certificates, no automated renewal, no documented private-key destruction process, and excessive access to backups. The certificate chain itself is valid, so ordinary chain validation does not prevent the outage.

Approach and solution

The organisation establishes a central certificate inventory containing subject, SANs, owner, issuer, expiry, environment, key type, and renewal status. Automated alerts are configured at 60, 30, and 7 days before expiry. Renewal is tested in a staging environment and deployed through controlled automation. Private keys are generated on the destination service or in an HSM, and old keys are removed after a documented transition period.

Access to backups is reduced using least privilege and multi-person approval. The organisation also creates an incident procedure for suspected key compromise, including immediate certificate revocation, replacement, log preservation, and customer-impact assessment.

Outcome

The new process prevents future expiry outages, reduces private-key exposure, and provides evidence for audits. It also reveals that some certificates were issued for unnecessary hostnames, allowing the organisation to reduce its attack surface.

Learning points

Certificate management must be treated as an operational lifecycle. Automation is valuable, but it must be combined with ownership, inventory accuracy, secure private-key handling, validation testing, and incident response.

11. Best-Practice Checklist

• Maintain an authoritative inventory of keys and certificates.
• Assign every key an owner, purpose, environment, and expiry date.
• Use approved cryptographic algorithms and secure random generation.
• Keep private keys in hardware-backed or otherwise strongly protected storage.
• Separate signing and encryption purposes.
• Use offline or strongly protected roots where feasible.
• Validate complete certificate chains, identity, usage, time, and status.
• Automate renewal while preserving approval and rollback controls.
• Test backup restoration and disaster recovery.
• Apply dual control to high-impact operations.
• Revoke promptly after suspected compromise.
• Destroy obsolete keys and document the destruction.
• Review access, logs, algorithms, and certificate inventories regularly.

Chapter Summary

Key management governs the complete life of cryptographic keys, from policy and secure generation through distribution, use, rotation, recovery, revocation, archival, and destruction. Symmetric keys provide efficient data protection but require secure shared-secret management. Asymmetric key pairs support scalable authentication and secure exchange, while certificates bind public keys to identities.

PKI uses CAs, RAs, repositories, policies, and relying parties to create managed trust relationships. Certificate validation requires more than signature verification: the chain, time, identity, permitted usage, algorithms, and revocation status must all be considered. CRLs, OCSP, and OCSP stapling provide different approaches to status checking.

HSMs protect high-value keys, but they must be supported by role separation, dual control, auditing, and recovery testing. Rotation, backup, escrow, and destruction must be risk-based and governed. Effective key management combines cryptographic controls with operational ownership, privacy protection, compliance, automation, and incident response.

Key Terms

Key management: Governance and technical control of keys throughout their lifecycle.

Symmetric key: A secret key used by the same cryptographic system for related encryption and decryption operations.

Asymmetric key pair: A mathematically related public key and private key.

Private key: Secret key material that must be protected from unauthorised access.

Data-encryption key: A key used to encrypt application data.

Key-encryption key: A key used to protect another cryptographic key.

Certificate: A signed binding between an identity and a public key.

Public Key Infrastructure: Policies, people, processes, and technologies for managing public-key trust.

Certificate Authority: An entity that issues and signs certificates.

Registration Authority: An entity that verifies identity or authorisation for certificate issuance.

Trust anchor: A locally trusted root public key or certificate.

Intermediate CA: A subordinate CA that normally issues end-entity certificates.

Certificate chain: An ordered path from an end-entity certificate to a trusted root.

CRL: A signed list of revoked certificate serial numbers.

OCSP: A protocol for obtaining certificate status information.

HSM: Hardware Security Module used to protect and operate on cryptographic keys.

Key rotation: Replacement of a key according to time, risk, usage, or policy.

Key escrow: Controlled placement of key-recovery capability with an authorised custodian.

Certificate revocation: Withdrawal of trust in a certificate before its normal expiry.

Secure destruction: Rendering key material and recoverable copies unusable.

Review Questions

Short Answer Questions

1. Why is key management broader than key storage?
2. What is the difference between a public key and a private key?
3. What role does a Registration Authority perform?
4. Why might an organisation use an intermediate CA?
5. State two reasons why a certificate may be revoked.

Long Answer Questions

1. Explain the stages of the cryptographic key lifecycle and the controls required at each stage.
2. Describe how a certificate chain is constructed and validated.
3. Compare CRLs and OCSP, including operational advantages and limitations.
4. Explain how HSMs protect keys and why an HSM does not remove the need for governance.
5. Discuss the security and ethical implications of key escrow and archival.

Analytical / Application Questions

1. A company discovers that a private TLS key has been copied to an employee laptop. Design an incident-response and key-replacement process.
2. An organisation has thousands of certificates and experiences repeated expiry outages. Propose a lifecycle-management architecture and explain how you would measure its effectiveness.
3. A regulator requires historical verification of signed records, while the organisation wants to destroy old signing keys. Analyse how archival, trust validation, retention, and secure destruction should be balanced.

Multiple Choice Questions with Answers

Question 1

Which component normally verifies an applicant’s identity before a certificate is issued?

A. Registration Authority

B. Relying party

C. Key-encryption key

D. Certificate repository

Correct Answer: A. Registration Authority

Question 2

What is the primary purpose of a certificate chain?

A. To compress certificate data

B. To connect an end-entity certificate to a trusted authority

C. To generate symmetric session keys

D. To replace private-key protection

Correct Answer: B. To connect an end-entity certificate to a trusted authority

Question 3

Which certificate field is especially important for modern TLS hostname matching?

A. Serial number

B. Subject Alternative Name

C. CRL size

D. Issuer locality

Correct Answer: B. Subject Alternative Name

Question 4

What is a major function of an HSM?

A. Publishing public web pages

B. Protecting and using cryptographic keys in a specialised device

C. Replacing all certificate policies

D. Providing user passwords in plaintext

Correct Answer: B. Protecting and using cryptographic keys in a specialised device

Question 5

Which event is an appropriate reason to revoke a certificate before expiry?

A. The certificate has been successfully validated

B. The associated private key is suspected to be compromised

C. The public key is published

D. The certificate contains a serial number

Correct Answer: B. The associated private key is suspected to be compromised

Question 6

What does a key-encryption key normally protect?

A. Another cryptographic key

B. A certificate subject name

C. A CA policy document only

D. A network cable

Correct Answer: A. Another cryptographic key

Question 7

Which statement about a root CA is most accurate?

A. It is always an end-entity server certificate

B. Its trust is normally established as a local trust anchor

C. It must expose its private key to every client

D. It cannot sign intermediate CAs

Correct Answer: B. Its trust is normally established as a local trust anchor

Question 8

Why is key rotation useful?

A. It guarantees that compromise is impossible

B. It limits exposure and supports replacement according to risk or policy

C. It eliminates the need for certificate validation

D. It makes public keys secret

Correct Answer: B. It limits exposure and supports replacement according to risk or policy

Question 9

What is the main purpose of OCSP?

A. To request current certificate-status information

B. To generate random passwords

C. To encrypt an entire hard disk

D. To create a root trust store automatically

Correct Answer: A. To request current certificate-status information

Question 10

Which practice best supports recovery of backed-up keys?

A. Never testing restoration

B. Allowing one administrator unrestricted access

C. Encrypting backups, restricting access, and testing restoration

D. Storing unprotected copies beside production systems

Correct Answer: C. Encrypting backups, restricting access, and testing restoration