Cryptography and Key Management

Introduction

Databases contain credentials, personal information, financial records, intellectual property, and operational data. A stolen database can therefore be as damaging as a compromised application. Cryptography reduces this risk by transforming readable information (plaintext) into an unintelligible representation (ciphertext), or into a fixed-length digest used for verification. It also supports authentication, integrity, non-repudiation, and secure communication.

Cryptography is not a substitute for access control, secure coding, patching, backups, or monitoring. It is a security control whose effectiveness depends heavily on key management. A strong algorithm with a poorly protected key provides little protection. This chapter examines encryption at rest and in transit, hashing, salting, digital signatures, certificates, TLS, transparent database encryption, field-level encryption, tokenization, and the secure lifecycle of cryptographic keys.

Learning Objectives

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

• distinguish confidentiality, integrity, authentication, and non-repudiation;
• compare symmetric encryption, asymmetric cryptography, hashing, salting, and tokenization;
• explain encryption at rest and in transit;
• describe TLS, certificates, and digital signatures;
• compare transparent database encryption with field-level encryption;
• design a basic key lifecycle covering generation, storage, rotation, recovery, and destruction;
• identify common implementation failures and governance obligations; and
• select appropriate controls for practical database-security scenarios.

1. Cryptographic Foundations

1.1 Security services

Cryptographic mechanisms commonly provide four services:

Non-repudiation is stronger than simply proving that a key was used. It also requires trustworthy identity binding, secure private-key control, reliable records, and legal or organisational acceptance.

1.2 Kerckhoffs’s principle

A sound cryptosystem should remain secure even when its algorithms are public. Security should depend on the secrecy of keys, not on hiding the algorithm. This principle supports peer review, standardisation, interoperability, and timely vulnerability analysis.

1.3 Entropy and randomness

Keys, nonces, salts, and tokens require unpredictable random values. Cryptographic systems must use an approved cryptographically secure pseudorandom number generator (CSPRNG), normally seeded by an operating-system or hardware entropy source. Ordinary pseudo-random functions, timestamps, sequential identifiers, and user-selected passwords are unsuitable for generating secret keys.

A key’s nominal length is not the same as its effective security. Effective security may be reduced by weak randomness, brute-force attacks, implementation flaws, leaked keys, or cryptanalytic weaknesses.

2. Symmetric and Asymmetric Cryptography

2.1 Symmetric encryption

Symmetric encryption uses the same secret key for encryption and decryption. It is efficient for large amounts of data and is therefore the normal choice for database pages, files, backups, and application payloads.

Modern deployments should use authenticated encryption, such as AES-GCM or ChaCha20-Poly1305. Authenticated encryption produces ciphertext and an authentication tag. Decryption fails when ciphertext, associated metadata, nonce, or tag has been modified.

A nonce is a value intended not to repeat with the same key. In many authenticated-encryption modes, nonce reuse can seriously compromise confidentiality and integrity. A nonce need not always be secret, but its uniqueness requirements must be respected. Applications should use well-tested libraries rather than implementing modes themselves.

Electronic Codebook (ECB) mode should not be used for ordinary data because identical plaintext blocks produce identical ciphertext blocks, revealing patterns. CBC mode, where encountered in legacy systems, requires careful random initialisation vectors and separate integrity protection; authenticated encryption is generally preferable.

2.2 Asymmetric cryptography

Asymmetric cryptography uses a public-key and a mathematically related private-key. The public key may be distributed, while the private key must remain secret. It supports key establishment, signatures, and identity certificates, but is usually slower than symmetric encryption for bulk data.

In a hybrid design, asymmetric cryptography establishes or protects a temporary symmetric session key. Symmetric encryption then protects the actual data. TLS follows this general pattern.

RSA, elliptic-curve cryptography (ECC), and post-quantum algorithms are families rather than single configurations. Security depends on key sizes, curves, padding, protocol versions, implementation quality, and current standards. New systems should follow contemporary guidance from recognised standards bodies and avoid obsolete algorithms such as DES, 3DES, RC4, and small RSA keys.

2.3 Envelope encryption

Envelope encryption separates data encryption from key-encryption responsibilities. A randomly generated data-encryption key (DEK) encrypts the data. A key-encryption key (KEK), normally held by a key-management service or hardware security module, encrypts or “wraps” the DEK.

This arrangement limits exposure: the application or database can use DEKs while the KEK remains in a more strongly controlled service. Rotation of a KEK can often be achieved by rewrapping DEKs rather than re-encrypting every data record, although the exact process depends on the platform.

3. Hashing, Salting, and Password Protection

A cryptographic hash function maps input data to a fixed-length digest. It is designed to be computationally difficult to reverse and to find two inputs with the same digest. Hashing is not encryption: a digest is not intended to be decrypted.

Hash functions such as SHA-256 are appropriate for integrity checks, identifiers in suitable contexts, and signature constructions. They are not sufficient by themselves for storing passwords because attackers can compute fast hashes at very high speed.

3.1 Salting

A salt is a unique, random value stored with a password hash. It ensures that two users with the same password do not normally have the same stored result and prevents the efficient reuse of precomputed rainbow tables. A salt is not a secret.

Password storage should use a dedicated, adaptive password-hashing function such as Argon2id, scrypt, or bcrypt, configured with an appropriate cost for the organisation’s hardware and risk. The stored record normally contains the algorithm, parameters, salt, and derived value. Verification recomputes the function and compares results using a safe comparison operation.

A pepper is an additional secret value kept separately from the database, for example in a secret-management system. It can provide defence in depth, but it introduces recovery and rotation obligations. A pepper must not be stored beside the password hash.

3.2 Hash-based integrity and MACs

A plain hash of a downloaded file does not authenticate the source: an attacker who changes the file may also change the hash. A keyed-hash message authentication code (HMAC) uses a secret key and detects modification by parties that do not possess that key. Digital signatures provide a related function using private and public keys and can support public verification.

4. Digital Signatures and Certificates

A digital signature is created with a private key and verified with the corresponding public key. It binds a signer to a particular message and detects modification. In practice, a signature is normally computed over a hash of the message rather than over the entire message directly.

A signature does not automatically prove who the signer is. That association is supplied by a public-key infrastructure (PKI), trusted certificate authorities, secure key custody, and certificate validation.

A digital certificate is a signed data structure that binds an identity, such as a domain name or organisation, to a public key. A certificate typically includes the subject, issuer, validity period, public key, permitted uses, and a signature from the issuing authority.

A certificate chain may contain an end-entity certificate, one or more intermediate certificates, and a trusted root. A relying party validates the chain, signature algorithms, validity dates, subject names, key-usage constraints, and revocation status according to its policy. Trusting any certificate without validation defeats the purpose of PKI.

Certificate revocation may use certificate revocation lists (CRLs), the Online Certificate Status Protocol (OCSP), or short-lived certificates with automated renewal. Operationally, automation is valuable because expired certificates can interrupt services, while excessive certificate lifetime increases exposure after key compromise.

5. Encryption at Rest

Encryption at rest protects stored data when media, snapshots, backups, or storage volumes are accessed outside their intended environment. It is particularly valuable against lost devices, improperly disposed media, stolen backups, and some forms of infrastructure compromise.

At-rest encryption does not necessarily protect data from a process that already has authorised access to a running database. A compromised database administrator, application account, or host may be able to request plaintext. Consequently, encryption at rest must be combined with least privilege, strong authentication, auditing, segmentation, and endpoint protection.

Important at-rest assets include:

• production database files and transaction logs;
• replicas, exports, and temporary files;
• backup archives and snapshots;
• object-storage copies and disaster-recovery media; and
• encryption keys and configuration secrets.

Backups must be encrypted independently and tested for restoration. If production and backup keys are identical, one compromise may expose both environments.

6. Encryption in Transit and TLS

Encryption in transit protects data while it crosses networks or communication links. TLS is the dominant protocol for securing application, API, database-administration, and service-to-service connections.

A simplified TLS sequence is:

1. The client and server negotiate a supported protocol version and cipher suite.
2. The server presents a certificate and proves possession of its private key.
3. The parties perform an authenticated key exchange, commonly producing an ephemeral shared secret.
4. Session keys are derived from the exchange.
5. Application data is protected using authenticated encryption.

Modern deployments should prefer TLS 1.3 where supported, or carefully configured TLS 1.2 where necessary. SSL and obsolete TLS versions should be disabled. Certificate hostname validation must remain enabled; disabling it converts encryption into an unauthenticated tunnel.

Mutual TLS (mTLS) requires both client and server to present certificates. It is useful for service-to-service authentication, database connections, and high-assurance internal APIs. However, certificate issuance, renewal, revocation, and identity mapping must be managed carefully.

TLS protects a connection, not every endpoint. Plaintext may still appear in application memory, database logs, debugging traces, browser storage, or improperly configured proxies. Sensitive fields should not be logged merely because the transport is encrypted.

7. Database Encryption Patterns

7.1 Transparent database encryption

Transparent database encryption (TDE) encrypts database files, pages, tablespaces, and often logs at the storage layer. Applications generally continue to issue normal SQL queries, so migration can be comparatively straightforward.

TDE is effective for stolen disks, snapshots, and backup media. Its main limitation is that the database engine normally decrypts data for authorised queries. It does not prevent a privileged database account or compromised application from reading values. TDE also requires careful protection and backup of the database encryption key and its key hierarchy.

7.2 Field-level encryption

Field-level encryption encrypts selected columns or values, such as national identifiers, payment data, or medical information, before or during storage. It limits the amount of sensitive information exposed if unrelated fields are accessed.

Design questions include:

• Which component performs encryption and decryption?
• Does the database ever see plaintext?
• How will encrypted values be searched or sorted?
• How are keys associated with records and versions?
• How will existing data be migrated and re-encrypted?

Randomised encryption provides stronger confidentiality because equal plaintext values normally produce different ciphertext. Deterministic encryption produces repeatable ciphertext and can support equality searches, but it reveals equality patterns and may enable frequency analysis. Range queries usually require specialised schemes and should not be designed casually.

7.3 Tokenization

Tokenization replaces a sensitive value with a token that has no exploitable mathematical relationship to the original. The original value is stored in a protected token vault. Systems use the token for routine processing and call the vault only when the original value is genuinely required.

Tokenization can reduce the number of systems in scope for some compliance regimes, but it does not eliminate security obligations. The vault, token-management service, access policies, detokenization interfaces, logs, and operators remain high-value targets. Tokens must be generated so that they cannot be feasibly reversed or guessed.

8. Key Management Lifecycle

Key management is the controlled handling of cryptographic keys from creation to destruction. A practical lifecycle includes the following stages.

Generation

Generate keys using approved cryptographic libraries, secure random sources, and documented algorithms. Assign an owner, purpose, environment, algorithm, version, and expiry or review date. Never derive production keys from usernames, hostnames, source code, or predictable configuration.

Storage and use

Store keys in a dedicated key-management service (KMS), hardware security module (HSM), or another appropriately protected system. Do not place long-term secrets in source repositories, container images, spreadsheets, chat messages, or unencrypted configuration files.

Apply separation of duties. The person who deploys an application should not automatically be able to export its master keys. Use narrowly scoped identities, approval workflows, audit logs, and rate limits. Prefer non-exportable keys where feasible.

Distribution

Applications should retrieve keys through authenticated, authorised channels, often using short-lived credentials. Key material should not be copied widely. If a key must be transported, use a secure key-wrapping mechanism and verify the recipient and purpose.

Rotation

Rotation replaces a key according to time, usage, risk, personnel change, suspected exposure, or algorithm transition. Rotation policy should distinguish:

• routine rotation;
• emergency replacement after compromise;
• cryptographic migration to a new algorithm; and
• re-encryption or rewrapping of existing data.

A new key does not automatically protect old ciphertext. Systems need key-version metadata and a controlled process for reading old versions, writing new data with the current version, and gradually re-encrypting legacy data.

Backup and recovery

Keys must be recoverable enough to restore encrypted systems after disaster, but recovery material must not create an uncontrolled copy. Use encrypted, access-controlled backups, geographically separate storage, dual authorisation for sensitive recovery, and regular restoration exercises. A backup that restores data but not its keys is not a usable backup.

Revocation and destruction

Revoke keys when compromise is suspected, an owner leaves, a system is retired, or an algorithm is deprecated. Destruction should be deliberate and recorded. Key destruction can make data permanently inaccessible, so retention schedules, legal holds, and recovery requirements must be confirmed first.

A useful conceptual model is:

Figure: A controlled cryptographic key lifecycle. Rotation and recovery require documented versioning and authorisation.

9. Threats, Limitations, and Common Failures

Frequent failures include hard-coded keys, shared administrator keys, unencrypted backups, disabled certificate validation, weak random-number generation, nonce reuse, insecure key export, excessive key permissions, missing key-version metadata, and failure to test recovery.

Encryption can also create operational risks. Lost keys can cause irreversible data loss; poorly planned field encryption can break reporting; certificate expiry can cause outages; and centralised KMS failure can affect many services. High availability, monitored dependencies, emergency procedures, and tested break-glass access are therefore part of cryptographic engineering.

Cryptography does not protect data after authorised decryption. Screen capture, memory scraping, SQL injection through an authorised application, malicious insiders, and excessive exports remain relevant threats. Defence in depth is essential.

10. Governance, Ethics, and Compliance

Organisations should classify data and document why each cryptographic control is used. Policies should specify approved algorithms, minimum configurations, key owners, retention, access reviews, incident response, recovery, and exceptions.

Privacy principles support minimisation: do not collect or retain sensitive information merely because encryption is available. Access to plaintext should be limited, logged, and reviewed. Logs must avoid exposing keys, passwords, tokens, and sensitive fields.

Regulatory obligations vary by jurisdiction and sector. Payment, health, employment, and government data may have distinct requirements for encryption, key custody, breach reporting, retention, and audit evidence. Technical compliance does not excuse unethical collection, opaque processing, or unnecessary surveillance.

Cryptographic choices also have a technology lifecycle. Organisations should monitor algorithm deprecation, certificate standards, cloud-provider changes, and post-quantum migration guidance. Post-quantum cryptography is especially relevant to long-lived confidential data because an adversary may record encrypted traffic today and attempt decryption later. Migration should begin with an inventory of algorithms, protocols, certificates, and data lifetimes rather than an indiscriminate replacement of every component.

11. Applied Case: Illustrative Online Retail Database

Background

An online retailer stores customer profiles, order history, payment references, and employee access records. Its database uses disk encryption, but backups are copied to cloud storage without independent key separation. Internal services communicate over a mixture of TLS and unencrypted connections.

Problem

A stolen cloud credential exposes backup objects. Investigation shows that backups are encrypted with a key accessible to the same service identity that reads production data. The organisation also stores payment-card numbers, although most business processes require only a payment token.

Analysis

TDE protects the live database volume but does not correct the backup key-design weakness. A single identity has excessive privileges and violates separation of duties. Unencrypted internal links expose credentials and personal data to network interception. Storing unnecessary card numbers increases both breach impact and compliance scope.

Approach and solution

The retailer adopts envelope encryption. Separate DEKs protect production, test, and backup data; a KMS protects KEKs; and backup administrators cannot export production keys. Backups are encrypted before transfer and restoration is tested quarterly.

Payment-card numbers are replaced by tokens from a specialised vault. Only the payment service can detokenize values, while order systems store and process tokens. Highly sensitive employee identifiers receive field-level encryption with key-version metadata.

All service connections use TLS 1.3 where supported, with certificate validation and mTLS for high-value internal APIs. Passwords are migrated to Argon2id with unique salts. The organisation creates automated certificate renewal, key-rotation alerts, access reviews, and incident procedures for suspected key compromise.

Outcome

A stolen backup credential no longer provides direct access to production keys. The routine order database contains tokens rather than payment-card numbers, reducing exposure. Transport encryption prevents passive interception, while audit records show key use and detokenization events.

Learning points

The case demonstrates that encryption must be designed across data stores, networks, identities, and recovery processes. TDE alone is insufficient; tokenization can reduce unnecessary sensitive-data handling; and key separation is as important as cipher selection.

12. Professional Implementation Checklist

Before approving a design, verify that:

1. data is classified and protection requirements are documented;
2. TLS is enforced for all sensitive connections, including administrative links;
3. modern authenticated encryption is used with correct nonce handling;
4. passwords use an adaptive password-hashing function with unique salts;
5. backups, replicas, exports, logs, and temporary files are considered;
6. TDE, field-level encryption, or tokenization is selected for a stated threat model;
7. keys are generated by approved mechanisms and stored in a KMS or HSM where appropriate;
8. duties and permissions are separated and audited;
9. rotation, versioning, re-encryption, revocation, and destruction are documented;
10. recovery is tested without creating uncontrolled key copies; and
11. certificates, algorithms, dependencies, and post-quantum migration risks are inventoried.

Chapter Summary

Cryptography provides confidentiality, integrity, authentication, and—when supported by trustworthy identity and governance—non-repudiation. Symmetric encryption efficiently protects bulk data, while asymmetric cryptography supports key establishment and signatures. Hashes verify integrity but do not encrypt; passwords require adaptive hashing and unique salts.

TLS protects data in transit when protocol versions, certificates, and endpoint validation are correctly configured. At rest, TDE protects database storage but normally does not hide plaintext from authorised database processes. Field-level encryption provides more selective protection, while tokenization replaces sensitive values with references to a protected vault. These mechanisms address different threats and may be combined.

Key management is the central operational discipline. Secure generation, storage, distribution, use, rotation, recovery, revocation, and destruction must be planned together. KMSs and HSMs, separation of duties, key versioning, independent backup protection, auditing, and recovery exercises reduce the risk that encryption becomes either ineffective or operationally dangerous.

Key Terms

Cryptography: The science and practice of protecting information using mathematical techniques.

Plaintext: Readable or usable original data.

Ciphertext: Data transformed by encryption.

Symmetric encryption: Encryption using the same secret key for encryption and decryption.

Asymmetric cryptography: Cryptography using related public and private keys.

Authenticated encryption: Encryption that provides confidentiality and detects tampering.

Nonce: A value used once, subject to algorithm-specific uniqueness requirements.

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

Salt: A unique random value added to password processing before hashing.

Pepper: A separate secret used as additional password-protection material.

HMAC: A keyed hash used to authenticate a message and detect modification.

Digital signature: A private-key-generated value that supports integrity and signer authentication.

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

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

TLS: A protocol for authenticated and encrypted network communication.

TDE: Encryption of database storage structures, normally transparent to applications.

Field-level encryption: Encryption applied selectively to individual database fields or values.

Tokenization: Replacement of sensitive data with a token maintained through a protected vault.

DEK: Data-encryption key used to encrypt data.

KEK: Key-encryption key used to protect or wrap another key.

Review Questions

Short Answer Questions

1. Why is encryption at rest insufficient to protect data from a compromised application account?
2. What is the purpose of a salt in password storage?
3. Distinguish a digital signature from encryption.
4. What is the role of a certificate authority?
5. Why should backup keys be separated from production keys?

Long Answer Questions

1. Compare symmetric and asymmetric cryptography, including their performance, key-distribution, and practical uses.
2. Explain the TLS connection-establishment process and identify the responsibilities of certificate validation.
3. Compare TDE, field-level encryption, and tokenization for a regulated database.
4. Describe a complete cryptographic key lifecycle from generation through destruction.
5. Explain why password hashing requires an adaptive function, salts, and potentially a separately protected pepper.

Analytical / Application Questions

1. A company encrypts its database volume but sends administrative credentials over an unencrypted internal network. Identify the remaining risks and propose controls.
2. A reporting system must test whether two sensitive identifiers are equal, but it must not expose the identifiers to analysts. Evaluate deterministic field encryption and tokenization for this requirement.
3. During an incident, a service key may have been copied. Design an immediate response covering containment, revocation, rotation, data re-encryption or rewrapping, investigation, and recovery testing.

Multiple Choice Questions with Answers

Question 1

Which mechanism is primarily designed to provide confidentiality and integrity together?

A. Plain SHA-256 hashing

B. Authenticated encryption

C. A database index

D. A certificate subject name

Correct Answer: B. Authenticated encryption

Question 2

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

A. To make the password recoverable

B. To provide network encryption

C. To prevent identical passwords from producing identical stored results

D. To replace the need for an adaptive password-hashing function

Correct Answer: C. To prevent identical passwords from producing identical stored results

Question 3

Which statement best describes TDE?

A. It replaces every sensitive value with a vault token

B. It encrypts database storage while usually remaining transparent to applications

C. It guarantees that a compromised database administrator cannot read data

D. It authenticates remote clients through certificates

Correct Answer: B. It encrypts database storage while usually remaining transparent to applications

Question 4

What is the principal function of a digital certificate?

A. To bind an identity to a public key

B. To store a user’s password in plaintext

C. To compress a database backup

D. To generate a database index

Correct Answer: A. To bind an identity to a public key

Question 5

Why is nonce reuse dangerous in many authenticated-encryption schemes?

A. It can compromise confidentiality and integrity

B. It automatically rotates the encryption key

C. It makes certificates expire sooner

D. It prevents all plaintext from being stored

Correct Answer: A. It can compromise confidentiality and integrity

Question 6

In envelope encryption, what normally encrypts the application data?

A. The certificate authority

B. The data-encryption key

C. The root certificate

D. The password salt

Correct Answer: B. The data-encryption key

Question 7

Which control is most directly intended to protect data while it travels between a client and server?

A. TLS

B. TDE

C. Database indexing

D. Token-vault retention

Correct Answer: A. TLS

Question 8

What is a key-encryption key primarily used for?

A. Generating password salts

B. Wrapping or protecting a data-encryption key

C. Replacing a certificate hostname

D. Creating a plaintext database export

Correct Answer: B. Wrapping or protecting a data-encryption key

Question 9

Which statement about tokenization is correct?

A. The token must always be mathematically reversible without a vault

B. The original value is normally retained in a protected vault

C. Tokenization guarantees that access control is unnecessary

D. Tokens should be sequential so they are easy to predict

Correct Answer: B. The original value is normally retained in a protected vault

Question 10

What should an organisation do when rotating a key used for existing encrypted records?

A. Delete all records immediately

B. Ignore key versions because ciphertext identifies the key automatically

C. Define controlled versioning and a re-encryption or rewrapping process

D. Publish the new key so every service can update itself

Correct Answer: C. Define controlled versioning and a re-encryption or rewrapping process