Cryptography and Public Key Infrastructure

Introduction

Cryptography is the disciplined use of mathematical techniques to protect information and establish trust in digital systems. It supports confidentiality, integrity, authentication, and non-repudiation. These objectives are essential because modern organizations exchange information across networks that may be monitored, manipulated, or impersonated by attackers.

Cryptography is not synonymous with encryption. Encryption is one cryptographic function concerned primarily with confidentiality. Hashing produces a fixed-length representation of data and is mainly used to support integrity and password protection. Digital signatures provide integrity, origin authentication, and evidence that a private key was used to approve a message. Digital certificates bind a public key to an identity through the attestation of a trusted certificate authority (CA).

This chapter introduces symmetric and asymmetric cryptography, cryptographic keys, hashing, digital signatures, certificates, public key infrastructure (PKI), Transport Layer Security (TLS), and protection of data at rest, in transit, and in use.

Learning Objectives

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

1. Distinguish encryption, hashing, digital signatures, and digital certificates.
2. Explain how symmetric and asymmetric cryptography operate and when each is appropriate.
3. Describe key generation, storage, distribution, rotation, revocation, and destruction.
4. Explain the components and trust relationships of a PKI.
5. Describe the principal stages of a TLS connection.
6. Select suitable protections for data at rest, in transit, and in use.
7. Recognize operational, legal, ethical, and implementation limitations of cryptography.

1. Security Services and the Role of Cryptography

A security control should be selected according to the security service required.

Cryptography cannot, by itself, guarantee that a user keeps a password secret, that a server is patched, or that an authorized administrator will not misuse access. It is part of a broader control system involving identity management, secure software, physical safeguards, monitoring, policy, and incident response.

A useful distinction is between a cryptographic primitive and a protocol. A primitive, such as a block cipher or hash function, performs a narrowly defined operation. A protocol, such as TLS, combines primitives with identity checks, key negotiation, message formatting, and error handling. Secure primitives can still be used insecurely in a flawed protocol.

2. Symmetric Cryptography

Symmetric cryptography uses the same secret key, or closely related secret keys, for encryption and decryption. The communicating parties must possess the key and protect it from every unauthorized party.

Conceptually, encryption can be represented as:

where P is plaintext, K is the secret key, E_K is the encryption operation using that key, and C is ciphertext. Decryption reverses the process:

The equations describe the intended relationship, assuming the algorithm is correctly implemented and the key is valid and secret. They do not imply that every encryption mode is automatically secure.

2.1 Block ciphers and authenticated encryption

A block cipher transforms fixed-size blocks using a key. AES is a widely deployed block cipher with 128-bit blocks and supported key sizes of 128, 192, and 256 bits. A block cipher normally requires a mode of operation to process messages longer than one block.

Modern applications should generally use authenticated encryption with associated data (AEAD), such as AES-GCM or ChaCha20-Poly1305. AEAD provides:

• Confidentiality for the protected plaintext.
• Integrity and authenticity for the ciphertext.
• Optional integrity protection for associated data, such as a message header that is not encrypted.

An authentication tag must be verified before plaintext is accepted. Applications must not continue processing data when tag verification fails.

A nonce, sometimes called an initialization value, is an input used by many encryption modes. For a given key, nonce requirements are mode-specific. In AES-GCM, nonce reuse with the same key is a serious failure that can expose plaintext relationships and undermine authentication. Nonces do not normally need to be secret, but they must satisfy the algorithm's uniqueness requirements.

2.2 Stream ciphers

A stream cipher generates a pseudorandom keystream that is combined with plaintext, commonly using an exclusive-or operation. Reusing the same keystream for two messages can reveal relationships between the plaintexts. Consequently, nonce and key management are fundamental rather than optional implementation details.

2.3 Strengths and limitations

Symmetric encryption is efficient and suitable for large amounts of data, including disk volumes, databases, backups, and network payloads. Its main difficulty is key distribution. If ten independent users must communicate privately with one another and each pair requires a unique key, the number of pairwise keys is:

where n is the number of participants and K is the number of pairwise keys. This formula assumes one distinct shared key for each unordered pair. For 10 users, K = 10 × 9 ÷ 2 = 45 keys are required. Centralized key-management systems reduce this administrative burden, but they introduce trusted services and operational dependencies.

3. Asymmetric Cryptography

Asymmetric, or public-key, cryptography uses a mathematically related key pair: a public key that may be distributed and a private key that must remain secret. A message encrypted with a public key is normally decrypted with the corresponding private key. A private key can also be used to create a digital signature that others verify with the public key.

Asymmetric cryptography solves important distribution problems, but its operations are generally slower and more computationally expensive than symmetric encryption. It is therefore commonly used for authentication, key establishment, and signatures rather than for encrypting entire large files.

3.1 Key exchange and key encapsulation

In a key agreement protocol, two parties derive shared secret material without directly transmitting the final symmetric key in plaintext. Diffie–Hellman and elliptic-curve Diffie–Hellman are examples of key agreement techniques. A key encapsulation mechanism (KEM) allows a sender to encapsulate a secret using a recipient's public key; the recipient decapsulates it using the private key.

A simplified hybrid-encryption design works as follows:

1. The sender generates a random symmetric data-encryption key.
2. The sender encrypts the data with an AEAD algorithm and that symmetric key.
3. The sender protects, or encapsulates, the symmetric key using the recipient's public key.
4. The recipient uses the private key to recover the symmetric key.
5. The recipient verifies the authentication tag before using the plaintext.

This combines the efficiency of symmetric cryptography with the distribution advantages of public-key cryptography.

3.2 Forward secrecy

A protocol provides forward secrecy when compromise of a long-term private key does not allow an attacker to decrypt previously captured sessions. Ephemeral Diffie–Hellman keys are commonly used to provide this property. Forward secrecy does not prevent compromise of a current session, but it limits the historical damage caused by later key theft.

3.3 Public-key assumptions

Public-key algorithms depend on computational assumptions. RSA security is related to the difficulty of factoring suitable large integers; elliptic-curve systems rely on the difficulty of particular elliptic-curve discrete-logarithm problems. These are assumptions about the infeasibility of attacks with currently known practical methods, not permanent mathematical guarantees.

Quantum computing may threaten widely deployed public-key systems based on factoring and discrete logarithms if sufficiently capable machines become available. Post-quantum cryptography seeks algorithms believed to resist such attacks. Migration requires inventory, testing, interoperability planning, and attention to cryptographic agility.

4. Hashing, Message Authentication, and Password Protection

A cryptographic hash function maps input of arbitrary length to a fixed-length digest. A simplified representation is:

where m is the input message, H is the hash function, and h is the resulting digest. The digest is not intended to be decrypted back into the original message.

A secure cryptographic hash is expected to provide:

• Preimage resistance: given a digest, finding a corresponding input should be computationally infeasible.
• Second-preimage resistance: given one input, finding a different input with the same digest should be infeasible.
• Collision resistance: finding any two different inputs with the same digest should be infeasible.

SHA-256 and SHA-3 are examples of modern cryptographic hash families. MD5 and SHA-1 should not be selected for collision-sensitive security applications.

A hash alone does not authenticate its source. Anyone can calculate a hash of a modified file. A message authentication code (MAC), such as HMAC, combines a secret key with a message and allows parties sharing that key to detect modification and authenticate the message as originating from a key holder. A digital signature provides similar integrity and origin properties using asymmetric keys and is more suitable where recipients should verify without sharing a signing secret.

Passwords require special treatment. A password should not be stored as a plain hash or with a fast general-purpose hash alone. Password storage should use a purpose-built, salted, adaptive password-hashing function such as Argon2id, scrypt, or bcrypt. A salt is a unique, non-secret value stored with the password record. It prevents identical passwords from producing identical stored values and makes precomputed rainbow-table attacks less useful. Work factors should be selected and periodically reviewed according to system performance and threat conditions.

5. Digital Signatures

A digital signature is created with a private signing key and verified using the corresponding public key. A practical signing process often hashes the message first and then signs the digest using a standardized signature scheme.

A signature can provide:

• Integrity: alteration normally causes verification to fail.
• Origin authentication: verification indicates that the holder of the private key authorized the signed content, subject to key protection and identity binding.
• Accountability and evidence: signatures can support non-repudiation, but legal non-repudiation also depends on identity proofing, access controls, procedures, and applicable law.

Encryption and signing have different purposes. Encrypting with a recipient's public key supports confidentiality for that recipient. Signing with the sender's private key supports verification of origin and integrity. A system may need both operations.

Private signing keys require strong protection. If an attacker obtains a private key, the attacker may create apparently valid signatures until the key is revoked or otherwise removed from trust. Signature algorithms and parameters must be used exactly as specified; improvised constructions can be insecure.

6. Digital Certificates and Public Key Infrastructure

A digital certificate is a structured statement that binds an identity or subject to a public key. X.509 certificates commonly include the subject, issuer, public key, validity period, permitted uses, serial number, and the CA's digital signature.

A certificate does not make a key inherently trustworthy. It provides evidence that a CA, operating under a defined policy, validated specified information and signed the binding. A relying party must decide whether to trust that CA and whether the certificate is valid for the intended purpose.

6.1 PKI components

A PKI is the set of people, policies, procedures, technologies, and services used to create, distribute, validate, renew, revoke, and manage certificates and keys. Common components include:

• Root CA: the trust anchor, usually kept highly protected and used sparingly.
• Intermediate or issuing CA: signs end-entity certificates and limits exposure of the root.
• Registration authority (RA): performs or supports identity validation.
• Certificate repository: publishes certificates and related information.
• Revocation services: provide certificate revocation lists (CRLs) or online status information such as OCSP.
• Relying parties: systems or users that validate certificates and make trust decisions.
• Certificate policy and practice statements: document assurance requirements and operating procedures.

A certificate chain may run from an end-entity certificate through one or more intermediates to a trusted root. During validation, software checks signatures in the chain, validity periods, intended key usage, name constraints where applicable, and whether the certificate is revoked or otherwise unacceptable.

6.2 Certificate lifecycle

A sound lifecycle includes:

1. Planning the identity, use, algorithm, validity period, and approval requirements.
2. Generating the key in an approved environment.
3. Creating a certificate signing request and validating the subject.
4. Issuing and deploying the certificate securely.
5. Monitoring expiration, use, and configuration.
6. Renewing before expiry.
7. Revoking when a key is compromised, a subject is no longer authorized, or certificate information is no longer reliable.
8. Archiving or destroying keys according to retention and recovery requirements.

Revocation is not a substitute for short validity periods, monitoring, or rapid incident response. Organizations must understand how their clients check revocation and what happens when status services are unavailable.

7. TLS and Protection of Data in Transit

TLS protects application traffic over networks that may be hostile. HTTPS is HTTP carried over TLS. TLS generally provides server authentication, confidentiality, integrity, and negotiated session keys. Mutual TLS can also authenticate the client with a certificate.

A simplified TLS connection involves:

1. The client proposes protocol versions and supported cryptographic options.
2. The server selects parameters and sends its certificate chain.
3. The client validates the certificate name, chain, dates, key usage, and applicable trust policy.
4. The parties perform an authenticated key exchange.
5. Both derive symmetric traffic keys.
6. Application data is protected using an AEAD cipher and integrity is verified on receipt.

Modern deployments should use current TLS versions, secure cipher suites, strong certificate practices, and appropriate configuration management. Older protocols, obsolete algorithms, weak keys, and certificate-validation bypasses create avoidable risks.

TLS protects data between the endpoints of a particular connection. It does not automatically protect data before encryption, after decryption, in logs, in browser memory, or at a terminating proxy. Organizations must identify every endpoint and intermediary in the data path.

8. Protecting Data at Rest, in Transit, and in Use

8.1 Data at rest

Data at rest includes files, databases, backups, removable media, and stored cloud objects. Appropriate controls may include full-disk encryption, database or column-level encryption, encrypted backups, access control, key separation, secure deletion, and hardware security modules (HSMs) for highly sensitive keys.

Full-disk encryption is valuable if a device is lost or stolen while powered off. It may not protect data from a logged-in user, malware operating with sufficient privileges, or an application that can read the mounted disk. Application-level encryption can reduce exposure but introduces key-management and recovery complexity.

8.2 Data in transit

Use authenticated secure protocols such as TLS for network services. Avoid relying on network location, such as an internal IP address, as proof of trust. Segment networks, authenticate services, monitor certificate use, and protect administrative interfaces. Encryption should be applied across all relevant links, including service-to-service and backup-transfer connections.

8.3 Data in use

Data in use is present in memory or actively processed. Traditional encryption normally requires plaintext during computation. Controls include least privilege, process isolation, endpoint security, access logging, secure coding, memory protection, confidential-computing technologies, and minimizing the amount and duration of plaintext exposure.

Trusted execution environments and memory-encryption technologies may reduce exposure in specialized systems, but they have deployment, attestation, performance, and side-channel considerations. They should complement rather than replace sound access control and application security.

9. Key Management

Key management is often more difficult than selecting an algorithm. A lifecycle should address generation, distribution, activation, storage, backup, rotation, recovery, revocation, archival, and destruction.

9.1 Key-management principles

• Generate keys using approved cryptographic random-number generators.
• Use algorithms and key sizes appropriate to the risk and current standards.
• Separate keys by purpose; do not reuse a signing key for encryption.
• Apply least privilege to key access.
• Store high-value keys in HSMs, key-management services, or equivalent protected systems.
• Maintain auditable key ownership and usage records.
• Plan recovery without creating uncontrolled copies.
• Rotate keys according to risk, algorithm limits, exposure, and organizational policy.
• Revoke or destroy keys promptly when compromise or unauthorized use is suspected.
• Test restoration and key-recovery procedures before an emergency.

Key rotation does not repair data that has already been exfiltrated, and it can make historical data inaccessible if old keys are destroyed prematurely. Retention policies must therefore connect data lifecycle decisions with cryptographic lifecycle decisions.

9.2 Threats to keys

Key threats include weak random generation, hard-coded secrets, accidental publication in source repositories, excessive administrator access, insecure backups, endpoint compromise, insider misuse, and poor certificate renewal. Secrets-management systems can reduce exposure, but their master credentials and administrative interfaces become high-value targets.

10. Illustrative Case: Protecting a Healthcare Web Portal

This is a fictional illustrative case.

Background

A healthcare provider operates a patient portal that stores appointments, clinical messages, and billing information. The portal uses a web application, several internal services, and cloud backups.

Problem

A security review discovers that the web server uses HTTPS externally, but internal service calls use unencrypted HTTP. Database backups are stored without encryption, application passwords are hashed with unsalted SHA-256, and the TLS certificate is renewed manually. Administrators also share one database encryption key.

Analysis

The external TLS connection protects only the browser-to-front-end segment. Traffic between internal services can be observed or altered by a compromised host or misconfigured network device. Unencrypted backups create a major confidentiality risk. Fast unsalted password hashing permits efficient offline guessing and reveals whether users share passwords. Shared encryption-key access prevents meaningful attribution and increases the impact of one administrator compromise.

Approach and solution

The provider adopts a layered design:

1. TLS is required for external and internal service connections, with certificate validation and service identity controls.
2. The portal uses a current AEAD configuration and automated certificate inventory and renewal.
3. Backups are encrypted with a dedicated backup key managed by a centralized key-management service.
4. Database encryption keys are separated by environment and purpose, with restricted access and audit logging.
5. Passwords are reprocessed using Argon2id with unique salts and a reviewed work factor.
6. Administrative access uses individual accounts, multifactor authentication, privileged-access management, and separate duties.
7. Key compromise, certificate expiry, and failed validation events generate alerts.
8. Recovery exercises verify that encrypted backups can be restored without exposing keys.

Outcome

The revised design reduces exposure during network interception, device loss, backup theft, and credential compromise. It also improves accountability and operational resilience. It does not eliminate risk: compromised application hosts may still access plaintext during authorized processing, and stolen user sessions require additional controls.

Learning points

Encryption must be applied to the complete data path, not merely the most visible network boundary. Password hashing is distinct from general data encryption. Key separation, automation, monitoring, and recovery are essential parts of practical cryptography.

11. Challenges, Governance, and Ethical Considerations

Cryptographic controls can conflict with usability, availability, performance, lawful access requirements, and business continuity. If keys are lost, encrypted information may be permanently inaccessible. If recovery mechanisms are too broad, they may become an avenue for abuse.

Organizations should document who may issue certificates, approve key recovery, access HSMs, and change cryptographic configurations. Dual control and separation of duties are appropriate for high-impact operations. Cryptographic decisions should be reviewed against privacy law, records-retention requirements, sector regulation, contractual obligations, and cross-border restrictions.

Security professionals should avoid weakening encryption for convenience or creating hidden bypasses. Exceptional access mechanisms can introduce concentrated points of failure and may undermine users' expectations of confidentiality. Where lawful access is required, it should be governed by clear authority, proportionality, auditability, and independent oversight.

Cryptography also has an equity dimension. Poorly designed certificate warnings, inaccessible authentication mechanisms, or irreversible account-recovery processes can exclude legitimate users. Security controls should be usable, documented, and tested with the communities affected by them.

12. Best Practices Checklist

• Use encryption for confidentiality and authenticated encryption for tamper detection.
• Use hashes for integrity-related comparison and password-hashing functions for passwords.
• Use digital signatures when recipients must verify origin without sharing a signing secret.
• Validate certificate chains, names, dates, key usage, and revocation status according to policy.
• Prefer hybrid designs: asymmetric cryptography for authentication or key establishment and symmetric cryptography for bulk data.
• Never reuse nonces where the selected algorithm forbids reuse.
• Protect private keys more carefully than public keys.
• Automate certificate discovery, renewal, and alerting.
• Maintain an inventory of algorithms, keys, certificates, dependencies, and data flows.
• Plan for compromise, rotation, revocation, backup, recovery, and eventual post-quantum migration.
• Test configurations and failure behavior; never silently bypass certificate or authentication errors.

Chapter Summary

Cryptography provides mechanisms for confidentiality, integrity, authentication, and key establishment, but it operates within a larger system of people, processes, software, and governance. Symmetric cryptography is efficient for bulk data but requires secure key distribution. Asymmetric cryptography supports authentication, key establishment, and digital signatures, but it is more computationally expensive. Hybrid encryption combines the strengths of both.

Hash functions produce fixed-length digests and are not encryption. MACs authenticate messages using shared secrets, while digital signatures use private keys and can be verified with public keys. Certificates bind identities to public keys, and PKI supplies the policies, authorities, repositories, and lifecycle processes needed to operate that trust model.

TLS protects authenticated network connections, but protection ends at the relevant endpoints and does not automatically secure data in memory, logs, or poorly protected backups. Effective security therefore requires protection of data at rest, in transit, and in use, supported by disciplined key management, certificate lifecycle automation, least privilege, monitoring, recovery planning, and ethical governance.

Key Terms

Cryptography: The practice of protecting information and communications using cryptographic techniques.

Encryption: Transforming plaintext into ciphertext to restrict disclosure.

Decryption: Recovering plaintext from ciphertext using an appropriate key.

Symmetric cryptography: Cryptography using a shared secret key for related encryption and decryption operations.

Asymmetric cryptography: Cryptography using related public and private keys.

Block cipher: An algorithm that transforms fixed-size blocks of data using a key.

AEAD: Authenticated encryption with associated data; encryption that also provides integrity and authentication.

Nonce: A value used by a cryptographic operation, subject to algorithm-specific uniqueness requirements.

Hash function: A function that maps arbitrary input to a fixed-length digest.

MAC: A keyed message authentication code used to detect alteration and authenticate a message to key holders.

Digital signature: A private-key-generated value that supports integrity and origin verification.

Digital certificate: A signed data structure binding a public key to a subject or identity.

Certificate authority: An entity that issues and signs certificates under defined policies.

PKI: The people, policies, procedures, and technologies used to manage certificates and public-key trust.

TLS: A protocol that protects communications between authenticated endpoints.

Key management: The lifecycle management of cryptographic keys, including generation, storage, use, rotation, and destruction.

Forward secrecy: A property limiting the effect of later long-term key compromise on earlier sessions.

HSM: A hardware security module designed to protect and perform operations involving sensitive keys.

Revocation: The process of declaring a certificate or key no longer trustworthy before its normal expiry.

Review Questions

Short Answer Questions

1. What is the primary difference between encryption and hashing?
2. Why are symmetric algorithms commonly used for bulk data encryption?
3. What does a digital certificate bind together?
4. Name two checks performed when validating a TLS certificate.
5. Why should passwords not be stored using a fast unsalted general-purpose hash alone?

Long Answer Questions

1. Explain the differences among symmetric encryption, asymmetric encryption, and hybrid encryption.
2. Describe the main components and lifecycle processes of a public key infrastructure.
3. Explain how digital signatures provide integrity and authentication, and why they do not automatically guarantee legal non-repudiation.
4. Discuss the security requirements for protecting data at rest, in transit, and in use.
5. Explain why key management is a central operational challenge in cryptographic systems.

Analytical / Application Questions

1. An organization encrypts its database but sends application-to-database traffic over unencrypted internal connections. Analyze the remaining risks and recommend controls.
2. A certificate is valid in date and signed by a trusted CA, but its subject name does not match the server being contacted. Should the client accept it? Explain your reasoning.
3. A company loses access to an encryption key after an administrator leaves. Propose a key-lifecycle and recovery design that reduces both data loss and unauthorized access risk.

Multiple Choice Questions with Answers

Question 1

Which cryptographic mechanism is primarily designed to provide confidentiality for bulk data?

A. Symmetric encryption

B. A cryptographic hash

C. A digital certificate

D. A certificate revocation list

Correct Answer: A. Symmetric encryption

Question 2

What is the main purpose of a salt in password storage?

A. To encrypt the password reversibly

B. To make identical passwords produce different stored values

C. To replace the need for a password-hashing function

D. To allow the password to be recovered by an administrator

Correct Answer: B. To make identical passwords produce different stored values

Question 3

Which statement best describes a digital signature?

A. It encrypts a message so only the sender can read it

B. It binds a disk to a symmetric encryption key

C. It supports integrity and verification of the signer's private-key use

D. It makes a certificate authority unnecessary

Correct Answer: C. It supports integrity and verification of the signer's private-key use

Question 4

In a hybrid-encryption design, what is normally encrypted with the asymmetric mechanism?

A. The entire large data file

B. The symmetric data-encryption key

C. The recipient's private key

D. The authentication tag only

Correct Answer: B. The symmetric data-encryption key

Question 5

For 10 participants using one distinct shared symmetric key for each pair, how many pairwise keys are required?

A. 10

B. 20

C. 45

D. 100

Correct Answer: C. 45

Question 6

What is the role of a certificate authority in a PKI?

A. It stores every user's plaintext password

B. It signs certificates that bind public keys to validated subjects

C. It decrypts all TLS traffic for network administrators

D. It generates a new private key for every browser request

Correct Answer: B. It signs certificates that bind public keys to validated subjects

Question 7

Why is nonce reuse particularly dangerous in some authenticated-encryption modes such as AES-GCM?

A. It automatically shortens the key

B. It can undermine confidentiality and authentication

C. It makes the public certificate expire

D. It prevents the recipient from knowing the sender's name

Correct Answer: B. It can undermine confidentiality and authentication

Question 8

Which property means that compromise of a long-term private key does not normally reveal previously captured sessions?

A. Forward secrecy

B. Collision resistance

C. Certificate pinning

D. Data compression

Correct Answer: A. Forward secrecy

Question 9

What does TLS certificate validation include?

A. Checking only whether the certificate is colorful and readable

B. Checking the chain, name, validity, and permitted use as applicable

C. Decrypting the server's private key

D. Replacing all application access controls

Correct Answer: B. Checking the chain, name, validity, and permitted use as applicable

Question 10

Which control is most appropriate for protecting a highly sensitive cryptographic key from ordinary host administrators?

A. Publishing the key in a source repository

B. Storing the key in an HSM with restricted audited access

C. Using the same key for every purpose

D. Disabling key rotation permanently

Correct Answer: B. Storing the key in an HSM with restricted audited access