Cryptography and Key Management

Introduction

Databases contain credentials, financial records, health information, intellectual property, and operational data. A database security programme must therefore protect information in three states: at rest, when stored on disks, backups, snapshots, or removable media; in transit, when transmitted between clients, application servers, database servers, and replicas; and in use, when data is being queried, processed, displayed, or exported.

Cryptography provides important controls for these states, but encryption alone is not a complete security strategy. A system may use strong encryption and still be vulnerable if keys are exposed, passwords are hashed incorrectly, database administrators have excessive access, or decrypted data is copied into logs. Effective protection combines cryptographic algorithms, sound key management, access control, secure configuration, monitoring, and governance.

This chapter explains encryption, hashing, salting, masking, tokenisation, TLS, and the lifecycle management of cryptographic keys. It also introduces key-management systems (KMS), hardware security modules (HSMs), implementation decisions, limitations, and professional responsibilities.

Learning Objectives

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

1. Distinguish encryption, hashing, salting, masking, and tokenisation.
2. Explain how symmetric and asymmetric cryptography support database security.
3. Select suitable controls for data at rest, in transit, and in use.
4. Describe TLS protection for database connections.
5. Design a basic cryptographic key lifecycle using a KMS or HSM.
6. Evaluate practical, operational, ethical, and regulatory issues in cryptographic deployments.

1. Cryptographic Foundations

Cryptography transforms information so that only authorised parties, or parties with the correct verification capability, can use or validate it. The original information is called plaintext. The transformed information is ciphertext when encryption is used. A cryptographic key controls the transformation.

A secure cryptographic design normally seeks several properties:

• Confidentiality: unauthorised parties cannot understand the data.
• Integrity: unauthorised modification can be detected.
• Authentication: the identity of a communicating party or message source can be verified.
• Non-repudiation: in suitable digital-signature contexts, a signer cannot reasonably deny having signed a message.

These properties are related but not identical. Encryption primarily provides confidentiality. A message authentication code (MAC) provides integrity and authentication when the communicating parties share a secret. A digital signature provides integrity, origin authentication, and evidence associated with a private key. A database encryption feature that does not authenticate ciphertext may still be vulnerable to undetected tampering.

1.1 Symmetric cryptography

Symmetric encryption uses the same secret key, or mathematically related secret material, to encrypt and decrypt data. Modern systems commonly use AES, especially AES-128 or AES-256, with an authenticated-encryption mode such as AES-GCM. ChaCha20-Poly1305 is another modern authenticated-encryption construction used in many protocols.

Symmetric encryption is efficient and is therefore suitable for database files, tablespaces, backups, large objects, and bulk application data. Its principal management challenge is protecting and distributing the secret key. If the key is disclosed, confidentiality is lost; if it is destroyed without a recovery plan, authorised decryption may become impossible.

Authenticated encryption produces ciphertext together with an authentication tag. The tag allows the recipient to detect alteration. Additional unencrypted information, such as a record identifier or protocol version, may be supplied as associated authenticated data (AAD) so that it is authenticated without being encrypted.

A nonce or initialization vector (IV) is also used by many modes. For AES-GCM, nonce reuse with the same key is dangerous and can compromise confidentiality and authentication. Nonces must therefore be generated and managed according to the algorithm’s requirements. A nonce does not normally need to be secret, but it must not be reused in circumstances where reuse is prohibited.

1.2 Asymmetric cryptography

Asymmetric cryptography uses a public key and a private key. The public key may be distributed widely, whereas the private key must remain secret. Public-key algorithms support key establishment, digital signatures, and certificate-based authentication. Examples include elliptic-curve cryptography and RSA, although algorithms and key sizes must be selected according to current standards and organisational policy.

Asymmetric operations are slower than symmetric operations and are not normally used to encrypt an entire database. A common design is envelope encryption: a randomly generated data-encryption key (DEK) encrypts the data, while a key-encryption key (KEK), held by a KMS or HSM, encrypts or wraps the DEK. The application stores the encrypted DEK with the ciphertext, but the KEK remains under central control.

1.3 Cryptographic randomness

Keys, salts, nonces, and tokens require unpredictable values. They must be generated using an approved cryptographically secure random-number generator (CSPRNG), not a timestamp, sequential counter, spreadsheet function, or ordinary pseudo-random generator. Weak randomness can defeat otherwise strong algorithms.

2. Hashing, Salting, and Password Protection

A cryptographic hash function maps input data to a fixed-length digest. A secure hash is designed so that it is computationally difficult to reverse the digest, find a second input with the same digest, or deliberately construct collisions. SHA-256 and SHA-3 are examples of general-purpose hash functions.

Hashing is not encryption. A hash normally cannot be decrypted because no decryption key exists. Hashes are useful for integrity checks, indexing certain non-secret values, and supporting password-verification schemes.

2.1 Password hashing

Passwords should not be stored as plaintext or as ordinary fast hashes such as a simple SHA-256 digest. Attackers can test huge numbers of guesses against fast hashes, particularly when passwords are weak or reused.

Password storage should use a password-derived key function designed to be expensive and configurable. Suitable contemporary choices include Argon2id, scrypt, or bcrypt, subject to current guidance and implementation support. The function should use a unique random salt for every password and parameters that impose an appropriate computational and memory cost.

A salt is not a password and does not need to be secret. Its purpose is to ensure that identical passwords produce different stored results and to prevent the efficient reuse of precomputed rainbow tables. A stored password record commonly contains the algorithm identifier, cost parameters, salt, and derived value. During authentication, the supplied password is processed using the stored parameters and compared using a suitable constant-time comparison method.

A pepper is an additional secret value applied to password processing. Unlike a salt, it is not stored with the password record; it may be held in a secrets manager or HSM. A pepper can add protection if the database is stolen, but it introduces availability and rotation challenges. It must not become a single unmanaged secret shared across all systems.

2.2 Integrity hashes and MACs

A plain hash of a database export does not prove who generated it because anyone can calculate a new hash after changing the file. A keyed-hash message authentication code, such as HMAC, addresses this issue when the verifier and generator share a secret key. Digital signatures are appropriate where public verification, independent validation, or formal signing evidence is required.

3. Protecting Data in Three States

3.1 Data at rest

Data-at-rest protection may include:

• Full-disk or volume encryption.
• Database transparent data encryption (TDE) for data files and often transaction logs.
• Column or field encryption for especially sensitive attributes.
• Encrypted backups, snapshots, replicas, and export files.
• Application-level encryption before data reaches the database.
• Encryption of temporary files and removable media.

TDE is comparatively transparent to applications and protects stolen disks or backup media. It does not, however, protect data from an authorised database process, a compromised application account, or an administrator who can query the database while it is running. Field-level or application-level encryption offers more selective protection but creates challenges for indexing, searching, sorting, reporting, key rotation, and data recovery.

A layered design may use TDE for broad storage protection and application-level encryption for highly sensitive fields. The organisation must document which threats each layer addresses. Encryption of production files does not automatically encrypt database logs, replicas, caches, backup catalogs, or analyst extracts.

3.2 Data in transit

Data should be protected whenever it crosses a trust boundary or travels over a network that may be observed or altered. This includes client-to-database connections, application-to-database connections, replication channels, backup transfers, administrative sessions, and connections to cloud services.

TLS provides confidentiality, integrity, and endpoint authentication when correctly configured. A database connection should validate the server certificate and its certification path, use approved protocol versions and cipher suites, and reject expired, revoked, mismatched, or untrusted certificates. Disabling certificate validation merely to resolve a connection problem defeats a central purpose of TLS.

Mutual TLS (mTLS) adds client-certificate authentication. It is useful for service-to-service connections, although certificate issuance, renewal, revocation, and identity mapping must be managed carefully.

3.3 Data in use

Data in use is exposed to the database engine, application processes, administrators, memory, query results, and user interfaces. Conventional encryption must generally be reversed before computation, which creates a plaintext exposure window.

Controls for data in use include least-privilege database roles, views, row-level security, dynamic data masking, secure application interfaces, restricted exports, audit logging, and minimisation of sensitive values in memory and logs. Trusted execution environments and homomorphic encryption can reduce some exposure in specialised cases, but they introduce complexity, performance costs, and operational limitations. They are not general replacements for access control.

4. Masking and Tokenisation

4.1 Data masking

Masking changes the presentation or content of data so that users receive only what they need. Static masking creates a sanitised copy for development, testing, or training. Dynamic masking changes returned values according to the requester’s privileges while leaving the underlying value unchanged.

Examples include displaying only the last four digits of an account number, replacing a national identifier with a format-preserving substitute, or showing a date at month rather than day precision. Masking must be assessed against inference risks. A small dataset, a predictable replacement pattern, or unrestricted access to related tables may allow re-identification.

Masking is not encryption. A privileged database administrator or application process may still access the original value, and a masked value may not protect data in backups unless the copies are also controlled.

4.2 Tokenisation

Tokenisation replaces a sensitive value with a token that has no exploitable mathematical relationship to the original. A token vault or controlled cryptographic service stores the mapping. Systems use the token for routine processing and request detokenisation only when justified.

Tokenisation can reduce the number of systems handling payment-card or identity data. However, the token vault becomes highly sensitive and must be strongly protected, monitored, backed up, and available when legitimate detokenisation is required. If tokens are predictable, reversible without authorisation, or reused across unrelated contexts, their security and privacy benefits are reduced.

5. Key Management and Lifecycle Design

Cryptographic strength is limited by the protection of keys. Key management covers creation, activation, distribution, storage, use, backup, rotation, revocation, archival, recovery, and destruction.

A practical lifecycle is:

1. Plan: classify data, identify threats, define ownership, retention, recovery, and compliance requirements.
2. Generate: create keys using an approved CSPRNG, preferably inside a KMS or HSM.
3. Register: assign a unique identifier, algorithm, purpose, owner, creation date, status, and permitted applications.
4. Distribute or wrap: deliver keys through authenticated, authorised channels; avoid embedding them in source code or configuration files.
5. Activate and use: enforce separation of duties, least privilege, usage restrictions, and audit logging.
6. Rotate: replace keys according to exposure risk, cryptoperiod, policy, or suspected compromise. Rotation must include a plan for decrypting historical data or rewrapping old DEKs.
7. Revoke or suspend: prevent further use when a key is compromised, misused, or no longer authorised.
8. Archive: retain keys only when necessary to decrypt legally or operationally retained data, with restricted access.
9. Destroy: securely eliminate keys when retention obligations expire and verify that no required recovery process depends on them.

A key identifier is not the key itself. Systems should distinguish key versions and status values such as pending, enabled, disabled, compromised, and destroyed. Rotation without version tracking can make old data inaccessible or cause applications to encrypt new records with an unintended key.

5.1 KMS and HSM

A key management system automates key generation, storage, policy enforcement, access control, rotation, auditing, and often envelope-encryption operations. It may be cloud-based, on premises, or hybrid.

A hardware security module is a specialised tamper-resistant device that generates and performs cryptographic operations with keys protected inside the device. HSMs are useful where assurance requirements, regulatory obligations, high-value signing keys, or strict separation of duties justify their cost. They do not eliminate the need for sound identity management, backup, availability planning, and operational controls.

The root or master key should have stronger protection than ordinary data keys. A common hierarchy is:

• Root or key-encryption key protected by an HSM or KMS.
• Key-wrapping keys used to protect DEKs.
• DEKs used for database objects, files, or records.
• Short-lived session keys used for individual communications.

This hierarchy limits exposure and supports efficient rotation. Rewrapping a DEK under a new KEK can often be performed without decrypting and re-encrypting the entire dataset, provided the design and service support this operation.

5.2 Separation of duties and recovery

No single individual should ordinarily be able to create, approve, use, export, and destroy a high-value key without oversight. Roles may include key custodian, security administrator, database administrator, application owner, auditor, and recovery officer.

Recovery procedures must be tested. Encrypted backups are useless if the organisation cannot recover the required keys, credentials, configuration, and dependencies. Conversely, recovery copies of keys must be protected as carefully as production keys. Key escrow should be authorised, documented, access-controlled, and subject to dual approval where appropriate.

6. Implementation Pattern: Encrypted Customer Records

Consider an application storing customer identity and payment information. A suitable design could operate as follows:

1. The client connects to the application using TLS.
2. The application authenticates to the database using a short-lived identity or managed credential.
3. The application generates or obtains a DEK for a protected data domain.
4. Sensitive fields are encrypted using authenticated encryption, with a unique nonce for each encryption operation.
5. The KMS wraps the DEK under a KEK; only the wrapped DEK and ciphertext are stored in the database.
6. The database uses TDE to protect files, logs, and backups.
7. Analysts receive masked or tokenised values rather than plaintext.
8. Every decrypt operation is authorised, logged, monitored, and associated with a service identity.
9. Key versions support rotation and historical decryption.

Search requirements must be considered. Randomised encryption provides strong confidentiality but does not support ordinary equality searches without additional design. A keyed blind index or carefully controlled deterministic construction may support equality lookup, but it can reveal whether values are equal and may be vulnerable to frequency analysis. Security and functionality must therefore be balanced explicitly.

7. Illustrative Case: Regional Health-Service Database

Background

A regional health service operates a database containing patient identifiers, appointment records, diagnoses, and billing information. Its existing system uses database passwords, unencrypted backup files, and a shared administrator account. A contractor’s laptop is lost, and an unencrypted backup on that laptop is discovered.

Problem

The organisation must reduce the likelihood and impact of unauthorised disclosure while maintaining clinical availability. It must also support testing, reporting, auditing, and lawful retention.

Analysis

The lost laptop demonstrates that perimeter security and database access controls do not protect portable copies. The shared administrator account prevents reliable attribution. The absence of TLS exposes internal traffic to interception, while plaintext exports create uncontrolled secondary copies. Encrypting only the main data file would not address these risks.

Approach and solution

The organisation classifies patient identifiers and diagnoses as highly sensitive. It deploys TDE for database files, logs, replicas, and backups, with keys controlled by a KMS backed by an HSM. The application uses field-level authenticated encryption for selected identity attributes. A separate tokenisation service supplies tokens for reporting, while authorised clinical workflows can request detokenisation.

All client, application, replication, and backup-transfer connections require TLS with certificate validation. The shared administrator account is removed and replaced by named identities, role-based access, privileged access management, and audited emergency access. Development databases are created from statically masked data. KMS policies restrict decrypt operations to approved service identities, and alerts are generated for unusual volumes of decryption.

A documented rotation and recovery procedure is tested quarterly. Backup recovery is tested in an isolated environment, and key destruction is linked to approved retention schedules rather than informal administrator action.

Outcome

The lost-device scenario no longer exposes readable patient data because the backup is encrypted and the decryption key is not stored on the device. Analysts can perform most work with tokenised or masked information. Audit records identify privileged activity, and TLS reduces interception risk. Residual risks remain: a compromised application with legitimate decrypt authority could still expose data, and availability depends on the KMS and recovery process.

Learning points

The case illustrates that encryption must be layered, keys must be separated from protected data, and data minimisation reduces the number of systems requiring decryption authority. It also shows that technical controls must be supported by identity governance, monitoring, testing, and retention policy.

8. Limitations, Governance, and Professional Practice

Encryption does not prevent authorised misuse, insecure user interfaces, SQL injection, malware operating inside an application, or disclosure through screenshots and reports. It may also create operational problems: CPU and storage overhead, increased latency, complicated indexing, key-recovery dependencies, and loss of access after configuration errors.

Organisations should maintain an inventory of sensitive data, keys, certificates, algorithms, owners, dependencies, and copies. They should define cryptoperiods based on sensitivity, threat exposure, algorithm guidance, transaction volume, and recovery requirements rather than rotating keys arbitrarily. Deprecated algorithms and protocols should be removed through a controlled migration plan.

Privacy and regulatory obligations may require confidentiality, breach notification, retention controls, auditability, data minimisation, and restrictions on cross-border processing. Encryption may reduce breach impact but does not automatically satisfy every legal requirement. Organisations must also consider lawful access, judicial orders, insider risk, and the danger of creating universal decryption mechanisms. Deliberate backdoors and shared master keys create concentrated failure points and should be evaluated through formal risk governance.

Artificial intelligence systems introduce additional concerns. Training datasets, embeddings, prompts, logs, and model outputs may contain sensitive database-derived information. Encryption and tokenisation should be applied before data is supplied to an AI service where feasible, and access policies should prevent models or operators from receiving more data than necessary. AI does not replace key custody, human accountability, or audit controls.

9. Best-Practice Checklist

• Classify data and identify its state: at rest, in transit, or in use.
• Use approved, modern algorithms and authenticated encryption where appropriate.
• Use unique, unpredictable nonces and salts according to algorithm requirements.
• Store passwords with Argon2id, scrypt, or bcrypt rather than plaintext or fast hashes.
• Protect keys separately from the data they encrypt.
• Use KMS or HSM services for high-value key generation and operations.
• Enforce least privilege, separation of duties, and named administrative identities.
• Require certificate validation for TLS connections.
• Encrypt backups, replicas, exports, temporary files, and portable media.
• Use masking or tokenisation to reduce routine exposure.
• Record key versions, owners, purposes, and lifecycle status.
• Test rotation, revocation, backup recovery, and disaster recovery.
• Monitor decrypt operations and investigate anomalous activity.
• Document residual risks, legal requirements, and exceptions.

Chapter Summary

Cryptography protects confidentiality, integrity, and authentication, but each property requires appropriate mechanisms. Symmetric encryption efficiently protects bulk data, while asymmetric cryptography supports key establishment and digital signatures. Authenticated encryption should be preferred where both confidentiality and tamper detection are required.

Hashing is one-way and is not a substitute for encryption. Passwords require slow, memory- or CPU-intensive password-hashing functions with unique salts. Masking changes what users see, while tokenisation replaces sensitive data with controlled substitutes. TLS protects database traffic only when certificates and protocol settings are correctly validated.

Data-at-rest controls must include databases, logs, replicas, backups, and exports. Data-in-use protection depends heavily on least privilege, masking, secure applications, and controlled decryption. KMS and HSM technologies provide centralised key protection, but effective security also requires lifecycle governance, separation of duties, recovery planning, monitoring, and tested procedures. Encryption reduces risk; it does not eliminate the need for access control, secure software, privacy governance, and professional judgement.

Key Terms

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

Plaintext: Information in its original readable form.

Ciphertext: Information transformed by an encryption process.

Symmetric encryption: Encryption using a shared secret key.

Asymmetric cryptography: Cryptography using related public and private keys.

Authenticated encryption: Encryption that also detects unauthorised alteration.

Nonce: A value intended for one-time use in a cryptographic operation.

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

Salt: A unique random value added to password processing.

Pepper: An additional secret used in password protection and stored separately.

Password-hashing function: A deliberately costly function designed for password verification.

TLS: Transport Layer Security, a protocol for protected network communication.

Data masking: Restricting the data representation shown to a user or system.

Tokenisation: Replacing a sensitive value with a controlled substitute token.

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

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

KMS: A key management system that controls cryptographic key lifecycle operations.

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

Envelope encryption: Encrypting data with a DEK and protecting that DEK with a KEK.

Cryptoperiod: The authorised period or usage scope for a cryptographic key.

Review Questions

5 Short Answer Questions

1. What is the difference between encryption and hashing?
2. Why should every stored password have a unique salt?
3. What security properties can TLS provide for a database connection?
4. Define envelope encryption and identify its two main key types.
5. Why is TDE insufficient as the only database security control?

5 Long Answer Questions

1. Explain how a database security architecture can protect data at rest, in transit, and in use.
2. Compare masking and tokenisation, including their appropriate applications and limitations.
3. Describe the complete lifecycle of a cryptographic key from generation to destruction.
4. Explain the roles of a KMS and an HSM and discuss when each may be appropriate.
5. Discuss the operational and governance challenges associated with database encryption.

3 Analytical / Application Questions

1. A company encrypts its production database but sends plaintext nightly exports to a contractor. Analyse the weaknesses and propose a layered solution.
2. A development team wants to use a single SHA-256 hash for all user passwords. Evaluate this design and recommend a safer implementation.
3. A reporting system needs equality searches over encrypted customer identifiers. Analyse the confidentiality and functionality trade-offs of deterministic encryption, blind indexes, and tokenisation.

Multiple Choice Questions with Answers

Question 1

Which mechanism is primarily intended for protecting passwords against offline guessing attacks?

A. AES-GCM

B. Argon2id with a unique salt

C. TLS certificate validation

D. Full-disk encryption

Correct Answer: B. Argon2id with a unique salt

Question 2

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

A. To make the password recoverable

B. To provide network encryption

C. To ensure identical passwords have different stored results

D. To replace the need for access control

Correct Answer: C. To ensure identical passwords have different stored results

Question 3

In envelope encryption, what normally encrypts the application data?

A. The data-encryption key

B. The certificate authority key

C. The database username

D. The password salt

Correct Answer: A. The data-encryption key

Question 4

Which statement about TDE is correct?

A. It prevents every authorised database query from revealing plaintext

B. It protects stored database files but does not by itself solve all access risks

C. It replaces TLS for network connections

D. It is a password-hashing function

Correct Answer: B. It protects stored database files but does not by itself solve all access risks

Question 5

What is a major requirement when using AES-GCM?

A. Reuse the same nonce for every record

B. Keep every nonce secret from the recipient

C. Avoid prohibited nonce reuse with the same key

D. Store the key in application source code

Correct Answer: C. Avoid prohibited nonce reuse with the same key

Question 6

Which technology is specifically designed to protect cryptographic keys inside tamper-resistant hardware?

A. HSM

B. CSV

C. DNS

D. FTP

Correct Answer: A. HSM

Question 7

What does TLS certificate validation help a database client verify?

A. That the server identity and trust chain are acceptable

B. That all database rows are encrypted at rest

C. That passwords have unique salts

D. That backups never require keys

Correct Answer: A. That the server identity and trust chain are acceptable

Question 8

Which control replaces a sensitive value with a controlled substitute and keeps a mapping in a protected service?

A. Tokenisation

B. Hash collision

C. Disk defragmentation

D. Plaintext logging

Correct Answer: A. Tokenisation

Question 9

Why should cryptographic keys be stored separately from encrypted database data?

A. To make queries slower

B. To ensure ciphertext is always publicly readable

C. To reduce the impact of theft of the data alone

D. To eliminate the need for backups

Correct Answer: C. To reduce the impact of theft of the data alone

Question 10

Which practice best supports accountability for privileged database activity?

A. A single shared administrator account

B. Named identities with least privilege and audit logging

C. Disabling all logs

D. Using the same key for every application

Correct Answer: B. Named identities with least privilege and audit logging