Key Management, PKI and Digital Trust

Introduction and Context

Public-key cryptography makes it possible for parties that have never met to communicate securely, authenticate one another, and establish shared secrets. However, cryptographic algorithms alone do not answer the operational questions that determine whether a system is trustworthy: Who generated a key? Where is it stored? How long may it be used? How can compromise be detected? How can relying parties decide whether a public key belongs to a particular organisation, device, person, or service?

Key management and public-key infrastructure (PKI) provide the operational and governance framework for answering these questions. They connect cryptographic objects with identities, authorisation policies, audit evidence, legal responsibilities, and incident-response procedures. In practice, many failures attributed to “broken cryptography” are actually failures of key lifecycle management, certificate validation, access control, or trust governance.

This chapter examines key lifecycles, certificates, certificate authorities, revocation, trust chains, hardware security modules, secrets management, timestamping, code signing, identity federation, and governance controls. The emphasis is on designing systems that remain trustworthy throughout their operational life rather than merely generating keys successfully.

Learning Objectives

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

• distinguish encryption keys, signing keys, wrapping keys, credentials, and secrets;
• design a controlled cryptographic key lifecycle;
• explain X.509 certificates, certificate authorities, trust anchors, and chain validation;
• compare certificate revocation lists and the Online Certificate Status Protocol;
• select suitable controls involving HSMs, key vaults, backups, and separation of duties;
• analyse code-signing, timestamping, and identity-federation architectures;
• evaluate PKI risks, governance requirements, and incident-response options;
• design a practical trust architecture for an enterprise or service ecosystem.

1. The Key-Management Problem

A cryptographic key is sensitive information whose possession or authorised use enables a cryptographic operation. The security objective depends on the key’s purpose. A confidentiality key protects data from unauthorised disclosure; a signing key supports integrity and authentication; a key-encryption key protects other keys; and a token-signing key enables a federation service to assert identities.

A key should therefore be treated as an asset with a defined owner, purpose, sensitivity, permitted algorithms, validity period, storage location, recovery policy, and destruction condition. Reusing one key for unrelated purposes increases the consequences of compromise and can create subtle protocol failures. For example, using a signing key as an encryption key may violate algorithm assumptions and make audit interpretation difficult.

Security properties of managed keys

Key management seeks to preserve several properties:

• Confidentiality: unauthorised parties cannot obtain private or secret key material.
• Integrity: keys cannot be altered, substituted, or associated with the wrong identity.
• Availability: authorised operations remain possible when needed.
• Authenticity: users can determine the origin and intended purpose of a key.
• Accountability: key use can be attributed to an authorised principal or service.
• Cryptoperiod control: a key is used only for an approved period or volume of data.

A key’s cryptoperiod is not simply the period printed in a certificate. It may be shorter because of algorithmic risk, business policy, data sensitivity, usage volume, personnel changes, or suspected compromise. A certificate may remain technically valid while policy requires the associated private key to be retired.

2. The Cryptographic Key Lifecycle

A defensible lifecycle contains the following stages.

2.1 Planning and specification

The organisation first defines the business purpose, threat model, algorithm, key length or security level, owner, users, interfaces, and retention requirements. Algorithms should be selected from current standards and approved organisational profiles. The design should also identify dependencies: certificate issuance, backup, disaster recovery, revocation, logging, and application rotation support.

2.2 Generation

Keys must be generated using an approved cryptographically secure random-number generator. Private keys should normally be generated within an HSM or an approved operating-system cryptographic service so that plaintext key material does not unnecessarily appear in application memory or administrator workstations. Entropy sources, generation events, and key identifiers should be auditable without recording secret key material.

2.3 Registration and binding

A public key becomes useful only when it is bound to an identity or purpose. This may occur through a certificate, a managed inventory record, a cloud key identifier, or a federation metadata document. The binding process must verify the applicant and authorisation. Automated domain validation, organisational validation, device attestation, and in-person identity verification provide different assurance levels and should not be treated as equivalent.

2.4 Distribution and activation

Public keys can generally be distributed widely, but their authenticity must be protected. Private keys and shared secrets require controlled delivery, access authentication, and, where possible, non-exportable storage. Activation may require dual control, an approval workflow, or a service identity rather than a human password.

2.5 Use and monitoring

Key use should be restricted by role, operation, application, algorithm, and environment. HSM policies may allow a key to sign but not export, or to decrypt but not wrap another key. Logs should record key identifier, operation, caller, time, result, and policy decision. Logging must avoid exposing plaintext secrets or sensitive payloads.

2.6 Rotation and renewal

Rotation replaces a key according to a defined schedule or event. Renewal often means obtaining a new certificate for a new or existing key, whereas rekeying generates a new key pair. Rekeying is stronger when compromise is possible; certificate renewal alone does not replace a compromised private key.

Rotation must account for overlap. During a transition, verifiers may need the old public key to validate previously generated signatures, while producers use the new key for new signatures. Protocols and applications should support multiple active verification keys and explicit key identifiers.

2.7 Revocation, suspension, and recovery

A key or certificate may need to be revoked because of compromise, mis-issuance, loss of control, role change, or policy violation. Suspension, where supported, is temporary and must not be confused with revocation. Recovery procedures should define who can restore encrypted backups, how recovered keys are reauthorised, and how compromise of a backup is detected.

2.8 Destruction and evidence retention

At the end of its cryptoperiod, a key should be securely destroyed or rendered unusable. Destruction may involve deletion from HSM slots, destruction of backup copies, cryptographic erasure of storage-encryption keys, and removal of authorisation records. Some public certificates, signatures, and audit logs must be retained for legal or forensic reasons even after private keys are destroyed.

A useful lifecycle control is a key record containing: key identifier, purpose, owner, algorithm, creation time, activation time, expiry, location, exportability, related certificate, backup status, rotation schedule, and destruction evidence.

3. Certificates and Public-Key Infrastructure

A PKI is a system of technology, policies, procedures, people, and governance that establishes, distributes, validates, revokes, and audits public-key bindings. It is not merely a certificate server.

3.1 X.509 certificates

An X.509 certificate normally contains a subject identity, issuer identity, public key, serial number, validity interval, signature algorithm, issuer signature, and extensions. Important extensions include:

• Basic Constraints: indicates whether the subject may act as a certification authority and may limit path length.
• Key Usage: constrains operations such as digital signature, key encipherment, or certificate signing.
• Extended Key Usage: identifies purposes such as server authentication, client authentication, code signing, or email protection.
• Subject Alternative Name: identifies DNS names, email addresses, IP addresses, or other permitted name forms.
• Subject Key Identifier and Authority Key Identifier: assist key and issuer identification.
• Certificate Policies: communicate policy identifiers and assurance information.

A certificate does not prove that its subject is honest or that a service is safe. It states that a trusted issuer made a particular identity-to-public-key assertion under specified policy conditions.

3.2 Certification authorities

A certification authority (CA) signs certificates. A root CA is a trust anchor whose public key is distributed independently, commonly through operating systems, browsers, enterprise configuration, or application settings. Root private keys should be exceptionally protected and used rarely.

An intermediate CA is signed by a root or another intermediate and issues end-entity certificates. This hierarchy permits operational separation: an online issuing CA can be limited in scope while the root remains offline. A registration authority may verify identity and approve requests without signing certificates itself.

The CA must protect its signing keys, verify certificate requests, enforce naming rules, publish revocation information, maintain accurate time, and preserve audit evidence. CA compromise can permit fraudulent certificates and undermine every relying party that trusts the CA.

3.3 Certificate-path validation

A relying party validates more than the final certificate signature. It constructs a path to a trusted anchor and checks each link. Typical checks include:

1. the chain signatures are mathematically valid;
2. the certificate is within its validity interval, subject to clock policy;
3. issuer and subject relationships are appropriate;
4. Basic Constraints and path-length limits are respected;
5. Key Usage and Extended Key Usage match the intended operation;
6. the requested name matches the Subject Alternative Name;
7. policy constraints are acceptable;
8. revocation status is acceptable;
9. the trust anchor is explicitly trusted by the relying-party environment.

A valid chain does not automatically mean that the certificate is appropriate for every use. For example, a certificate intended for server authentication should not be accepted for code signing merely because its signature chain is valid.

3.4 Trust models

The hierarchical model uses a root and subordinate CAs. A cross-certified or bridge model connects independent PKIs. A web-of-trust model allows users to make distributed endorsements, as historically used by some email-security systems. A trust-store model places selected anchors into software or devices. Federated trust often relies on metadata and contractual relationships rather than a universal CA hierarchy.

Each model has a different failure domain. A global root store offers broad interoperability but creates concentration risk. A private enterprise PKI offers control but creates operational responsibility for every managed endpoint and application.

4. Revocation and Status Checking

Certificate expiry is a scheduled event; revocation is an unscheduled response to changed trust. A certificate may be revoked before its expiry when a private key is compromised, a CA made an error, identity information changes materially, or the certificate was used outside policy.

A certificate revocation list (CRL) is a signed list of revoked certificate serial numbers, usually published periodically. CRLs are simple and cacheable but can become large and may not reflect the latest event immediately.

The Online Certificate Status Protocol (OCSP) allows a relying party to query status for a certificate. It can provide more current information but introduces network dependency, privacy concerns, responder availability issues, and possible performance overhead. Stapling allows a server to provide a signed status response to clients, reducing direct client queries.

Revocation design must specify fail-open or fail-closed behaviour. Failing open preserves availability but may accept a revoked certificate; failing closed improves security but may deny legitimate service when status infrastructure is unavailable. The appropriate decision depends on the transaction’s risk, compensating controls, and operational requirements.

5. Hardware Security Modules and Secrets Management

An HSM is a tamper-resistant or tamper-evident device that generates, stores, and uses cryptographic keys. It commonly provides non-exportable private keys, controlled cryptographic operations, role separation, secure backup mechanisms, and audit logging. HSMs are appropriate for root and issuing CA keys, payment keys, high-value signing keys, and other assets whose compromise would have systemic consequences.

An HSM does not solve every problem. A compromised application may still ask an HSM to perform an authorised signing operation. Consequently, applications need authorisation controls, transaction validation, rate limits, anomaly detection, and separation of duties. HSM availability, clustering, backup, firmware assurance, vendor dependence, and recovery ceremonies must be included in the design.

A secrets-management system stores and delivers passwords, API tokens, database credentials, private keys, and other sensitive configuration. Good practice includes:

• short-lived credentials where feasible;
• automatic rotation and lease expiry;
• policy-based access using workload identity;
• encryption in transit and at rest;
• versioning and controlled rollback;
• audit logs and alerting;
• separation between development, test, and production;
• prevention of secrets in source code, images, and build logs.

Envelope encryption is frequently used: a data-encryption key protects data, while a key-encryption key protects the data-encryption key. This limits the amount of data directly processed by a high-value master key and supports scalable rotation. The data key, key-encryption key, and wrapping metadata must still be managed as a coherent lifecycle.

6. Timestamping, Code Signing, and Long-Term Validation

A trusted timestamp authority (TSA) provides a signed assertion that a digital object existed at or before a specified time. The TSA should obtain time from controlled sources, protect its signing key, and include a cryptographic hash of the object or signature-related data. Timestamping is valuable when a signing certificate later expires or is revoked, because it can support the claim that a signature was created while the signing credential was valid. It does not prove that the software or document was safe or truthful.

Code signing binds software to a signing identity and supports integrity verification. A mature code-signing process includes:

1. controlled build inputs and reproducible or attestable builds;
2. signing in a protected service or HSM;
3. release approval and separation of development from signing authority;
4. signature verification by deployment systems;
5. timestamping and retention of certificates and verification evidence;
6. rapid revocation or blocklisting when a signing key is compromised;
7. protection against malicious updates and downgrade attacks.

A signed program can still contain vulnerabilities or malicious logic. Consumers must evaluate publisher identity, provenance, vulnerability evidence, update policy, and execution context in addition to signature validity.

7. Identity Federation and Digital Trust

Identity federation allows one domain to rely on authentication assertions issued by another. In a typical arrangement, an identity provider authenticates a user and issues a signed assertion or token to a service provider. Trust depends on metadata, signing keys, audience restrictions, issuer validation, time conditions, nonce or replay protection, and contractual governance.

Federation reduces password duplication and supports single sign-on, but it concentrates risk in identity providers and federation administrators. A stolen token-signing key can allow forged assertions; a misconfigured audience or redirect endpoint can cause assertion disclosure or misuse. Token-signing keys therefore require rotation, overlap for verification, emergency revocation or metadata update, and careful monitoring.

Federation should implement least privilege. Authentication answers “Who is this?” while authorisation answers “What may this subject do?” Claims should be minimal, accurate, purpose-limited, and protected from inappropriate correlation. Privacy-preserving designs avoid sending unnecessary identity attributes to every service.

8. Governance, Risk, and Compliance Controls

PKI governance should be documented in a certificate policy and certification practice statement, or equivalent internal documents. Governance should define assurance levels, identity proofing, permitted names, algorithms, key sizes, cryptoperiods, approval roles, audit requirements, revocation reasons, incident notification, and dispute handling.

Important controls include:

• asset inventory and ownership for every high-value key;
• separation of duties between request, approval, issuance, and audit;
• dual control for root-key ceremonies and recovery;
• documented certificate templates and automated linting;
• continuous monitoring for anomalous issuance and key use;
• independent audits and penetration testing;
• tested disaster recovery and compromise playbooks;
• vendor and supply-chain assessment;
• privacy review of identity data and certificate contents;
• algorithm-agility planning for future cryptographic migration.

Governance must also address legal and ethical issues. A CA may process personal data in subject names, email addresses, device identifiers, and audit records. Collection should be proportionate, retention should be justified, and access should be controlled. Administrators with power to issue certificates or retrieve secrets possess exceptional authority and require screening, supervision, and accountability.

9. Applied Case: Enterprise Software Signing PKI

Background

An international organisation distributes desktop software and container images to customers. Its development teams previously stored a signing key in a shared build server. The key was copied among administrators, certificates were renewed manually, and customers received inconsistent revocation information.

Problem

A malicious intruder who obtained build-server access could sign a fraudulent update. The organisation also could not reliably determine which employee or pipeline authorised a release. Certificate renewal did not consistently replace the underlying private key.

Analysis

The principal weaknesses were excessive key exportability, insufficient separation of duties, weak provenance of build inputs, incomplete audit trails, and inadequate emergency response. The certificate itself was not the main weakness; the lifecycle and authorisation controls surrounding the private key were.

Approach and solution

The organisation created an offline root and a restricted issuing CA for code-signing certificates. Signing keys were generated in an HSM and configured as non-exportable. A build service received a short-lived workload identity and could submit only approved release artifacts. A separate release-approval group authorised production signing. The signing service recorded artifact hash, source revision, pipeline identity, approver, time, certificate identifier, and result.

The organisation introduced timestamping, dual verification by deployment systems, key-overlap procedures, customer-facing status information, and an incident playbook. Emergency procedures included disabling the signing key, publishing revocation information, blocking affected versions, notifying customers, and generating a replacement key pair rather than merely renewing the old certificate.

Outcome

The new design reduced the number of people and systems able to invoke signing, improved attribution, and made emergency replacement practicable. It did not eliminate software vulnerabilities; instead, it made provenance and integrity claims more reliable and auditable.

Learning points

The case demonstrates that digital trust is socio-technical. HSMs protect key material, but governance determines who may cause a signature. Certificates establish a binding, but verification policy determines whether the binding is accepted. Timestamping preserves evidence, but does not establish software quality. Effective trust therefore requires layered controls.

10. Limitations and Contemporary Developments

PKI remains difficult because it combines cryptography with distributed administration, uncertain identity data, legacy systems, and human decision-making. Revocation may be unreliable in disconnected environments. Certificate stores may contain stale or excessive trust anchors. Automated issuance can scale errors as efficiently as it scales legitimate operations. Cloud services simplify infrastructure but may create concentration, portability, and jurisdictional concerns.

Post-quantum migration is an important strategic issue. Public-key algorithms currently deployed for key establishment and signatures may eventually require replacement or hybrid operation. Organisations should inventory cryptographic dependencies, identify long-lived confidential data, select standards-based migration paths, and design certificates, protocols, HSMs, and applications for algorithm agility. Migration should not involve untested proprietary algorithms or indiscriminate replacement without compatibility and assurance analysis.

Automation and AI can assist certificate discovery, anomaly detection, expiry forecasting, policy linting, and incident triage. However, automated issuance or revocation decisions require explainability, strong policy boundaries, human oversight for exceptional cases, and protection against poisoned telemetry or adversarial manipulation. An AI system should never receive unrestricted access to high-value signing keys merely because it can detect patterns.

Best-Practice Design Checklist

A practical design should answer the following questions:

1. What is each key’s exact purpose and owner?
2. Where is it generated, and can it be exported?
3. Which identities and processes may use it?
4. How are requests approved and logged?
5. What are the activation, rotation, expiry, and destruction rules?
6. How will previously generated signatures remain verifiable?
7. How will compromise be detected and contained?
8. What happens if revocation services are unavailable?
9. How are backups protected and recovery tested?
10. Which trust anchors are installed, and who governs them?
11. What personal data is collected in certificates and logs?
12. How will the design migrate to stronger algorithms in the future?

Chapter Summary

Key management is a lifecycle discipline covering planning, generation, identity binding, distribution, use, monitoring, rotation, revocation, recovery, and destruction. PKI provides the policies, authorities, certificates, repositories, validation rules, and governance needed to associate public keys with identities and purposes. Certificate-path validation requires more than checking a signature: it includes trust anchors, validity, constraints, name matching, intended usage, policies, and status.

CRLs, OCSP, and stapling offer different revocation trade-offs. HSMs protect high-value keys but must be combined with application authorisation, monitoring, availability planning, and dual control. Secrets-management systems reduce exposure through workload identity, short-lived credentials, rotation, and auditing. Timestamping supports long-term evidence, while code signing supports provenance and integrity but does not prove software safety. Federation extends trust across organisational boundaries and therefore requires careful token validation, key rotation, privacy controls, and governance.

The central lesson is that digital trust is not created by an algorithm or certificate alone. It emerges from technically sound cryptography, controlled key lifecycles, accurate identity processes, resilient operations, accountable governance, and tested responses to compromise.

Key Terms

Key lifecycle: The controlled stages through which a cryptographic key passes from specification to destruction.

Cryptoperiod: The approved period or usage scope during which a key may be used.

PKI: The people, policies, processes, technologies, and governance supporting public-key trust.

X.509 certificate: A structured, signed assertion binding a public key to an identity or purpose.

Certificate authority: An entity authorised to issue and sign certificates.

Root CA: A trust anchor whose public key is independently trusted.

Intermediate CA: A subordinate CA that issues certificates under a parent CA.

Trust anchor: A public key or certificate accepted without validation from a higher authority.

Certificate path: The ordered chain from an end-entity certificate to a trust anchor.

Revocation: The withdrawal of trust in a certificate before its scheduled expiry.

CRL: A signed list of revoked certificate serial numbers.

OCSP: A protocol for obtaining certificate-status information.

HSM: A hardware security module that protects and performs operations with cryptographic keys.

Secrets management: Controlled storage, delivery, rotation, and auditing of sensitive credentials.

Envelope encryption: Protecting data keys with a separate key-encryption key.

Timestamp authority: A trusted service that signs evidence of an object’s existence at a time.

Code signing: Applying a digital signature to software or release artifacts.

Identity federation: Reliance by one domain on authenticated assertions from another domain.

Trust store: A collection of trusted certificates or public keys maintained by software or an organisation.

Separation of duties: Dividing sensitive actions among different people or systems to reduce abuse.

Review Questions

Short Answer Questions

1. What is the difference between certificate renewal and key rekeying?
2. Why should a root CA private key usually be kept offline?
3. What information does an X.509 certificate bind together?
4. State two limitations of OCSP.
5. Why does a valid digital signature not prove that software is safe?

Long Answer Questions

1. Explain the complete cryptographic key lifecycle and identify controls appropriate to each stage.
2. Describe certificate-path validation, including trust anchors, constraints, intended usage, and revocation.
3. Compare hierarchical PKI, web-of-trust, and federation-based trust models.
4. Explain how HSMs and secrets-management systems complement rather than replace governance.
5. Discuss the security and privacy risks of identity federation and propose mitigating controls.

Analytical / Application Questions

1. An issuing CA’s private key is suspected to be compromised. Design an incident-response plan covering containment, revocation, replacement, customer communication, and forensic evidence.
2. Design a code-signing architecture for a cloud-native software company, specifying key storage, approval workflow, timestamping, rotation, logging, and emergency release blocking.
3. An organisation wants to fail open whenever revocation services are unavailable. Analyse when this may be acceptable, when it is dangerous, and what compensating controls could reduce the risk.

Multiple Choice Questions with Answers

Question 1

Which lifecycle stage binds a public key to an identity or approved purpose?

A. Key destruction

B. Registration and binding

C. Cryptographic erasure

D. Backup restoration

Correct Answer: B. Registration and binding

Question 2

What is the primary role of a root CA in a hierarchical PKI?

A. To act as an independently trusted anchor

B. To store every end-user password

C. To provide application-level authorisation

D. To replace all HSMs

Correct Answer: A. To act as an independently trusted anchor

Question 3

Which certificate extension indicates whether a certificate subject may act as a CA?

A. Subject Alternative Name

B. Extended Key Usage

C. Basic Constraints

D. Authority Key Identifier

Correct Answer: C. Basic Constraints

Question 4

What is the main difference between rekeying and certificate renewal?

A. Renewal always revokes the certificate

B. Rekeying generates a new key pair, while renewal may retain the key

C. Rekeying applies only to symmetric keys

D. Renewal never changes certificate validity

Correct Answer: B. Rekeying generates a new key pair, while renewal may retain the key

Question 5

Which technology is specifically designed to protect and use high-value private keys without routinely exporting them?

A. DNS cache

B. HSM

C. CRL

D. Load balancer

Correct Answer: B. HSM

Question 6

What does a certificate revocation list contain?

A. Private keys awaiting activation

B. A list of revoked certificate serial numbers

C. All trusted root certificates

D. Encrypted application data

Correct Answer: B. A list of revoked certificate serial numbers

Question 7

What does a trusted timestamp primarily support?

A. Proof that an object existed no later than a stated time

B. Proof that software contains no vulnerabilities

C. Automatic recovery of a lost private key

D. Replacement of identity verification

Correct Answer: A. Proof that an object existed no later than a stated time

Question 8

In identity federation, which party commonly authenticates the user and issues an assertion?

A. Identity provider

B. Certificate revocation list

C. Offline backup operator

D. Timestamp cache

Correct Answer: A. Identity provider

Question 9

Which control most directly reduces the risk of a signing key being copied from a build server?

A. Using a longer certificate subject name

B. Using a non-exportable key in an HSM

C. Disabling all certificate expiry dates

D. Publishing the private key publicly

Correct Answer: B. Using a non-exportable key in an HSM

Question 10

Why is separation of duties valuable in a PKI?

A. It ensures every administrator has unrestricted access

B. It divides sensitive actions to reduce unilateral misuse

C. It eliminates the need for audit logs

D. It prevents all certificate rotation

Correct Answer: B. It divides sensitive actions to reduce unilateral misuse