Data Protection, Privacy and Cryptography

Introduction

Modern web applications process identity data, payment information, health records, location data, business secrets and behavioural profiles. A security failure can expose this information, enable fraud, violate legal obligations and destroy user trust. Data protection therefore cannot be reduced to adding encryption to a database. It requires a coordinated approach involving classification, minimisation, secure processing, cryptographic controls, access governance, retention decisions and demonstrable compliance.

Cryptography provides technical mechanisms for confidentiality, integrity, authentication and non-repudiation. Privacy engineering determines whether data should be collected, how it may be used, how long it should be retained and how individuals can exercise their rights. A secure full-stack developer must understand both dimensions: encryption may protect a dataset from unauthorised reading, but it does not justify collecting unnecessary data or retaining it indefinitely.

Learning Objectives

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

• distinguish confidentiality, integrity, authentication and non-repudiation;
• select suitable controls for data in transit, at rest and in use;
• explain hashing, password hashing, digital signatures, certificates and PKI;
• manage cryptographic keys through their lifecycle;
• classify, minimise, retain and delete data responsibly;
• apply privacy by design to a full-stack application;
• relate technical controls to regulatory and governance obligations; and
• analyse the trade-offs and limitations of cryptographic protection.

1. Security Properties and Data States

The principal security objectives are often represented by the CIA triad:

• Confidentiality: only authorised parties can access information.
• Integrity: information is not altered without authorisation or detection.
• Availability: authorised users can access systems and data when needed.

Cryptographic systems also support authentication, which establishes the identity or origin of a communicating party, and non-repudiation, which makes it difficult for a signer to credibly deny a valid signature. Non-repudiation is not purely a technical property: legal rules, control of private keys and evidence about the signing process also matter.

Data should be considered in three states:

1. In transit—moving between a browser, API, service, queue or external provider.
2. At rest—stored in databases, object storage, backups, logs, caches or devices.
3. In use—present in application memory or being processed by software.

TLS primarily protects data in transit. Disk, database or field-level encryption protects selected forms of data at rest. Data in use is more difficult to protect because legitimate computation normally requires plaintext or a usable representation. Access control, isolation, secure memory practices, confidential-computing techniques and carefully designed tokenisation can reduce exposure, but no single control solves the problem.

2. Data Classification, Minimisation and Retention

A data-classification scheme gives information an appropriate level of protection. A practical scheme might contain four categories:

Classification should be attached to data assets and not merely to documents. A database column, API response, log event and backup may all inherit the sensitivity of the underlying information. Metadata can itself be sensitive; a log showing a person’s repeated visits to a clinic may reveal health information even if it contains no diagnosis.

Data minimisation

Data minimisation means collecting and processing only what is adequate, relevant and necessary for a defined purpose. Developers should ask:

• What business or legal purpose requires this field?
• Can the purpose be achieved with a less precise value?
• Can a derived attribute replace the original value?
• Does the application need to retain the value after the transaction?
• Is the field copied into logs, analytics systems, test databases or backups?

Examples include storing an age range instead of a date of birth, retaining a payment token instead of a card number, and recording that a user passed an identity check rather than retaining a complete identity document.

Retention and deletion

Retention must be based on purpose, contractual requirements, legal duties and operational necessity. A retention schedule should specify the owner, data category, storage locations, retention period, deletion method and exceptions such as litigation holds. “Delete” must include replicas, search indexes, caches, exported reports and development copies where feasible. Cryptographic erasure—securely destroying an encryption key—can render encrypted data inaccessible, but it is not automatically equivalent to physical deletion if plaintext copies or recoverable keys remain elsewhere.

3. Cryptographic Foundations

Symmetric encryption

Symmetric encryption uses the same secret key for encryption and decryption. It is efficient for large volumes of data. Modern authenticated encryption modes, such as AES-GCM and ChaCha20-Poly1305, provide confidentiality and integrity together.

A conceptual authenticated-encryption operation can be represented as:

Here, K is the secret key, N is a unique nonce, P is plaintext, A is authenticated but unencrypted associated data, C is ciphertext and T is an authentication tag. The recipient verifies T before releasing plaintext. The notation describes the interface rather than a particular implementation.

A nonce need not always be secret, but it must satisfy the algorithm’s uniqueness requirements. Reusing a nonce with the same key in AES-GCM is a serious failure that can reveal relationships between plaintexts and may compromise authentication. Libraries should generate and manage nonces rather than relying on ad hoc application code.

Asymmetric cryptography

Asymmetric cryptography uses a mathematically related public key and private key. The public key may be distributed; the private key must remain controlled by its owner. Asymmetric operations are generally slower than symmetric encryption, so web systems commonly use a hybrid design: asymmetric cryptography authenticates parties and establishes a shared secret, while symmetric encryption protects the application data.

A key pair may support encryption, signatures or both, but usage should follow the algorithm and protocol’s intended purpose. Private signing keys should not be reused casually as encryption keys.

Hash functions

A cryptographic hash maps an input of arbitrary length to a fixed-length digest. Desired properties include preimage resistance, second-preimage resistance and collision resistance. A hash is not encryption: it is not designed to be reversed with a secret key.

Hashes are useful for file integrity, content addressing, signature schemes and constructing password verifiers. However, ordinary fast hashes such as SHA-256 are unsuitable by themselves for password storage because attackers can test enormous numbers of guesses quickly. Passwords should be processed with a dedicated, salted, adaptive password-hashing function such as Argon2id, scrypt or bcrypt, using parameters appropriate to the deployment.

A password verifier is generally stored as a function of the password, a random salt and cost parameters. The salt need not be secret; its purpose is to prevent identical passwords from producing identical stored values and to defeat precomputed tables. A server should rate-limit authentication attempts and support secure password reset procedures. Encryption of a password database is helpful but does not replace password hashing: anyone who obtains the decryption key could recover all passwords if they were stored reversibly.

Message authentication codes

A MAC uses a shared secret to provide integrity and authentication between parties that possess that secret. HMAC is a widely used construction. A MAC does not provide public verifiability because both parties know the same key. This distinguishes it from a digital signature.

Digital signatures

A digital signature is generated with a private signing key and verified with the corresponding public key. It provides evidence that the holder of the private key authorised the signed message and that the message has not changed since signing. In practice, the signer signs a carefully defined representation, often a digest of canonicalised data, rather than an ambiguous human-readable string.

Signatures do not automatically encrypt content. A signed message may remain publicly readable. They also do not prove that a person is trustworthy; they connect a message to a key whose ownership and identity must be established through other controls.

4. TLS, Certificates and PKI

HTTPS uses TLS to protect browser-to-server communication. A simplified TLS connection involves:

1. negotiation of protocol versions and cryptographic parameters;
2. authentication of the server using a certificate and public key;
3. establishment of shared session keys, normally using an ephemeral key exchange; and
4. authenticated encryption of application records.

A certificate binds an identity, such as a domain name, to a public key. A certificate authority (CA) signs the certificate, and the client validates a chain leading to a trusted root. Validation includes the domain identity, validity period, signature chain, key usage and, where applicable, revocation information.

Public key infrastructure (PKI) includes certificates, CAs, registration processes, trust stores, policies, revocation mechanisms and operational procedures. A certificate is not proof that an application is secure. It does not prevent SQL injection, authorisation errors, malware or a compromised server. It primarily helps a client authenticate the endpoint and negotiate protected communication.

Developers should use current, well-maintained TLS libraries and secure platform defaults. They should avoid disabling certificate verification, accepting arbitrary hostnames, or implementing cryptographic handshakes themselves. Internal services require the same discipline: service-to-service TLS and, where justified, mutual TLS can authenticate both endpoints.

5. Encryption at Rest and in Application Design

Encryption at rest may be implemented at several layers:

Envelope encryption uses a data-encryption key (DEK) to encrypt data and a key-encryption key (KEK), usually held by a key-management service or hardware security module, to encrypt the DEK. The application stores ciphertext and the wrapped DEK. During decryption, an authorised service unwraps the DEK under policy controls.

Encryption does not replace access control. If an application automatically decrypts every restricted field for every authenticated employee, encryption may provide little protection from misuse within that application. Least privilege, purpose-based access, separation of duties, audit logs and anomaly detection remain essential.

6. Key Lifecycle Management

The security of an encryption system is often limited by key management rather than by the cipher. A complete lifecycle includes:

• Generation: use a cryptographically secure random source and approved key sizes and algorithms.
• Registration and labelling: record owner, purpose, algorithm, environment, creation date and status.
• Distribution: deliver keys through authenticated, access-controlled channels; never place secrets in source code or public repositories.
• Storage: use a managed key vault, HSM or equivalent protected service where appropriate.
• Use: restrict operations by identity, purpose and environment; prefer non-exportable keys for high-value operations.
• Rotation: replace keys according to risk, exposure, algorithm policy and contractual requirements. Rotation must account for decrypting older data or rewrapping DEKs.
• Revocation and suspension: stop trust in compromised, misissued or retired keys.
• Backup and recovery: protect backups with independent controls and test restoration.
• Destruction: securely remove keys when retention ends, subject to legal holds and recovery requirements.

Key rotation alone does not repair a compromise. An incident response plan must identify affected ciphertext, revoke or replace keys, investigate access, notify relevant parties where required and prevent reuse of compromised credentials. Secrets-management systems should support access logs, short-lived credentials and automated renewal.

7. Privacy by Design and Regulatory Obligations

Privacy by design incorporates privacy into architecture rather than adding it after deployment. A useful engineering process is:

1. define the purpose and lawful basis for processing;
2. map data flows, recipients, storage locations and transfers;
3. classify data and assess risks to individuals;
4. minimise fields and use privacy-preserving defaults;
5. implement access, encryption, pseudonymisation and deletion controls;
6. provide transparency and mechanisms for individual rights; and
7. test, monitor and revise the design.

Pseudonymisation replaces direct identifiers with tokens or coded identifiers, while retaining a means of re-identification. It reduces exposure but remains personal data when re-identification is reasonably possible. Anonymisation aims to make identification no longer reasonably possible, but it is difficult to achieve when datasets can be linked with other information.

Regulatory obligations vary by jurisdiction and sector. Common themes include:

• a defined and lawful purpose for processing;
• transparency about collection and use;
• data minimisation and accuracy;
• appropriate security safeguards;
• limits on retention;
• individual rights such as access, correction, deletion or portability;
• controls for processors and third-party providers;
• records of processing and risk assessments; and
• breach detection, response and notification within applicable deadlines.

Examples include the European Union’s General Data Protection Regulation, state privacy laws in the United States, sectoral rules such as health or payment regulations, and national data-protection statutes elsewhere. A developer should not assume that encryption alone establishes compliance. Legal applicability depends on jurisdiction, role, data type, organisation and processing activity; legal counsel and the organisation’s privacy officer should resolve disputed interpretations.

8. A Full-Stack Implementation Pattern

Consider a customer portal. The browser connects using HTTPS. The API authenticates the user with a secure session cookie or carefully designed token. Authorisation is checked server-side for every protected operation. Passwords are stored using an adaptive password hash. Sensitive profile fields are encrypted using envelope encryption. Logs contain event identifiers and outcome codes rather than passwords, access tokens or unnecessary personal data. Backups are encrypted and governed by the same retention policy as production data.

The application should distinguish:

• authentication: who is the requester?
• authorisation: is this requester allowed to perform this action on this resource?
• purpose limitation: is the processing consistent with the declared purpose?
• accountability: can the organisation demonstrate what happened?

A secure API also validates input, prevents injection, applies output encoding where relevant, uses CSRF protections for cookie-authenticated state changes, limits sensitive responses, and avoids placing secrets in URLs. TLS protects a request during transport but cannot correct an insecure endpoint, a leaked browser token or excessive data returned by the API.

9. Illustrative Case: University Health Appointment Platform

Background

A university deploys a web platform for students to book health appointments. The initial design stores names, student numbers, appointment details, insurance information and free-text notes in one database. Developers copy production data into a testing environment, and application logs record complete request bodies.

Problem

A compromised developer account exposes the test database. Although the production database uses disk encryption, the copied records are readable. Logs also contain sensitive notes. The university cannot determine which records were accessed or which retention periods apply.

Analysis

The main failure is architectural and governance-related, not a failure of the AES algorithm. Data was not classified, minimised or separated by environment. Encryption at rest protected storage media but not authorised application queries, copied plaintext or logs. The absence of an inventory prevented a reliable breach assessment.

Approach and solution

The university classifies health notes and insurance information as restricted. It removes insurance details that are not necessary for appointment scheduling and replaces free-text notes with a controlled clinical workflow managed by the health service. Production data is never copied directly to testing; synthetic data or strongly de-identified datasets are used instead.

The platform adopts HTTPS with certificate validation, adaptive password hashing, role-based and attribute-based authorisation, field-level envelope encryption for necessary restricted fields, and a managed key service. Logs record the user, operation, resource category and outcome, but not clinical content or credentials. Retention schedules distinguish appointment administration, clinical records and security logs. A documented deletion and legal-hold process is introduced, and access reviews are performed periodically.

Outcome

The redesigned system reduces the quantity of sensitive data, limits who can access it, improves incident investigation and makes regulatory reporting more reliable. Encryption remains important, but risk is reduced primarily through minimisation, separation, access governance and controlled operational processes.

Learning points

• Encryption cannot compensate for unnecessary collection.
• Test, logging and backup systems are part of the data environment.
• Classification must guide architecture and retention.
• Privacy and security controls should be designed together.
• A breach-response plan needs data inventories and access evidence.

10. Limitations, Ethics and Contemporary Developments

Cryptography protects information only while algorithms, implementations, keys and endpoints remain trustworthy. Weak random-number generation, incorrect certificate validation, nonce reuse, side-channel leakage, exposed secrets and vulnerable dependencies can defeat strong algorithms. Encryption can also complicate lawful data recovery, accessibility, debugging and secure search.

Ethically, organisations should avoid collecting data merely because storage is cheap or future analytics might be useful. Predictive systems and AI tools increase the risk of secondary use, inference and re-identification. Training or prompting an external AI service with personal or confidential data may disclose it to another processor and create retention or transfer problems. Data-protection impact assessments should consider inferred information, not only fields explicitly supplied by users.

Modern systems increasingly use hardware-backed keys, passkeys, confidential-computing environments, tokenisation, privacy-enhancing computation and automated secrets management. Post-quantum cryptography is being standardised because sufficiently capable quantum computers could threaten some widely used public-key algorithms. Migration requires inventorying cryptographic dependencies, avoiding hard-coded algorithm assumptions and choosing systems that can support algorithm replacement. Symmetric cryptography is generally less affected, although key-size and protocol decisions still require expert review.

Best-Practice Checklist

• Maintain a current inventory and classification of personal and confidential data.
• Minimise collection, copies, precision and retention.
• Use HTTPS with modern, maintained libraries and strict certificate validation.
• Use authenticated encryption rather than unauthenticated encryption alone.
• Hash passwords with Argon2id, scrypt or bcrypt and unique salts.
• Keep secrets and keys out of source code, images, logs and client-side bundles.
• Use a managed key service for important keys and document the full lifecycle.
• Separate production, testing, analytics, logging and backup environments.
• Apply least privilege and check authorisation on the server for every request.
• Test restoration, rotation, revocation, deletion and incident-response procedures.
• Review third-party processors, cross-border transfers and contractual safeguards.
• Treat privacy, security, accessibility and fairness as continuing design responsibilities.

Chapter Summary

Data protection combines technical security with responsible information governance. Data should be classified, minimised and retained only for justified purposes. Cryptography supplies complementary tools: symmetric authenticated encryption protects bulk data, asymmetric cryptography supports key exchange and signatures, hashes provide integrity and password-hashing functions protect password verifiers. TLS and PKI authenticate endpoints and protect data in transit, while encryption at rest and envelope encryption protect stored information when keys are properly managed.

A complete key lifecycle covers generation, storage, use, rotation, revocation, recovery and destruction. Privacy by design integrates purpose limitation, transparency, individual rights and secure defaults into architecture. Regulatory compliance is broader than encryption and requires accountability, appropriate safeguards, retention control and breach readiness. The university health-platform case demonstrates that minimisation, separation and governance often reduce risk more effectively than adding a single cryptographic feature.

Key Terms

Authenticated encryption: Encryption that provides confidentiality and detects unauthorised modification.

Certificate: A signed statement binding an identity to a public key.

Cryptographic hash: A fixed-length digest designed to resist specified forms of reversal and collision.

Data classification: Assigning data a sensitivity category that guides protection.

Data minimisation: Collecting and processing only information necessary for a defined purpose.

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

Encryption at rest: Protection of stored data using cryptographic transformation.

Encryption in transit: Protection of data while moving between systems.

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

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

Message authentication code: A shared-secret integrity and authentication mechanism.

Nonce: A value used once or according to strict uniqueness requirements in a cryptographic operation.

Password hashing: Adaptive, salted processing of passwords for secure verification.

PKI: The policies, authorities, certificates and processes supporting public-key trust.

Pseudonymisation: Replacing identifiers while retaining a controlled possibility of re-identification.

Retention schedule: A documented rule specifying how long data is kept and how it is disposed of.

Symmetric encryption: Encryption using a shared secret key.

TLS: A protocol suite that protects network communication and authenticates endpoints.

Trusted certificate authority: An authority whose root is accepted by a client to validate certificate chains.

Review Questions

Short Answer Questions

1. What are the three principal states of data?
2. Why is a cryptographic hash not the same as encryption?
3. What purpose does a salt serve in password hashing?
4. What does a certificate bind together?
5. Name two activities in a cryptographic key lifecycle.

Long Answer Questions

1. Explain how TLS uses certificates, key exchange and authenticated encryption to protect an HTTPS connection.
2. Compare full-disk, database, field-level and envelope encryption, including a limitation of each.
3. Explain privacy by design and show how it changes the development lifecycle.
4. Distinguish a MAC from a digital signature and identify a suitable use for each.
5. Discuss why encryption alone cannot establish regulatory compliance.

Analytical / Application Questions

1. A company encrypts its database but stores unredacted customer data in application logs and test exports. Analyse the risks and propose a revised data-protection architecture.
2. Design a key lifecycle for an online payment service that uses envelope encryption and must support rotation without losing access to legitimately retained records.
3. A mobile application requests a precise location continuously although it only needs a city for service availability. Apply minimisation, purpose limitation, retention and privacy-by-design principles to redesign the feature.

Multiple Choice Questions with Answers

Question 1

Which control is primarily designed to protect data while it travels between a browser and a web server?

A. TLS

B. Full-disk encryption

C. Password hashing

D. Database indexing

Correct Answer: A. TLS

Question 2

Why should ordinary SHA-256 not be used alone to store passwords?

A. It cannot produce a fixed-length output

B. It is designed to be fast, making guessing attacks efficient

C. It always encrypts passwords reversibly

D. It requires a certificate authority

Correct Answer: B. It is designed to be fast, making guessing attacks efficient

Question 3

What is the main purpose of a nonce in authenticated encryption?

A. To identify the database owner

B. To replace the encryption key permanently

C. To satisfy the algorithm’s uniqueness requirement for an operation

D. To make plaintext publicly readable

Correct Answer: C. To satisfy the algorithm’s uniqueness requirement for an operation

Question 4

Which statement best describes a digital signature?

A. It provides confidentiality without authentication

B. It is generated with a private key and verified with a public key

C. It is a reversible password hash

D. It removes the need for access control

Correct Answer: B. It is generated with a private key and verified with a public key

Question 5

What does a certificate primarily establish in PKI?

A. That an application contains no vulnerabilities

B. That a public key is bound to an identity under a trust system

C. That all stored data is anonymous

D. That a password is strong

Correct Answer: B. That a public key is bound to an identity under a trust system

Question 6

In envelope encryption, what normally protects the data-encryption key?

A. A key-encryption key

B. A database index

C. A salt only

D. A log timestamp

Correct Answer: A. A key-encryption key

Question 7

Which practice best demonstrates data minimisation?

A. Collecting every field in case it becomes useful later

B. Keeping production records in all testing environments

C. Storing an age range when an exact birth date is unnecessary

D. Copying full request bodies into logs

Correct Answer: C. Storing an age range when an exact birth date is unnecessary

Question 8

What is a principal limitation of full-disk encryption?

A. It cannot protect a lost storage device

B. It generally does little against a compromised running application that can read mounted data

C. It provides no protection for boot media

D. It prevents all authorised access

Correct Answer: B. It generally does little against a compromised running application that can read mounted data

Question 9

Which property distinguishes a MAC from a digital signature?

A. A MAC uses a shared secret and is not publicly verifiable

B. A MAC always encrypts the message contents

C. A digital signature cannot detect modification

D. A digital signature requires both parties to share one secret

Correct Answer: A. A MAC uses a shared secret and is not publicly verifiable

Question 10

Which action is most consistent with privacy by design?

A. Adding a privacy notice after deployment without changing data flows

B. Defining purpose, minimising fields and designing deletion controls before implementation

C. Retaining all data indefinitely in encrypted backups

D. Allowing clients to make all authorisation decisions

Correct Answer: B. Defining purpose, minimising fields and designing deletion controls before implementation