CCSP Data Security Technologies: Encryption, Key Management, Hashing, Masking, Tokenization and DLP

Each encryption control protects data in exactly one state, so the right control is the one that covers the state where the exposure is. Data at rest sits on disks, volumes, object stores and backups; data in transit moves between a client and a service or between tiers; data in use is in memory while it is being processed. A system that already encrypts disks gains nothing against a network finding by adding more disk encryption, and the reverse is equally true.

Confidential computing versus homomorphic encryption

Confidential computing and homomorphic encryption are the two in-use controls the exam usually sets side by side (secure multi-party computation, where parties jointly compute a result without revealing their inputs, is a third, more specialised one). Both protect data in use, and the constraints decide between them. Confidential computing runs workloads inside a hardware trusted execution environment (TEE) such as a confidential virtual machine or an enclave: memory is encrypted and isolated from the hypervisor, the host operating system and the provider's operators. Existing code generally runs unchanged. Its trust anchor is the processor vendor and the remote attestation process, which proves to the data owner what code is running in a genuine TEE before keys or data are released to it.

Homomorphic encryption lets a party compute directly on ciphertext; the result decrypts to the same answer as the computation on plaintext, and the processing party never sees any value. It does not depend on trusting anyone's hardware, but it is far slower than ordinary computation and supports a limited set of operations, so computations must be redesigned for it. It suits simple aggregates (sums, counts, some statistics and model inference) where timing is relaxed, and it is the option left when the data owner refuses to trust the processor's hardware or attestation service.

Encryption is only as strong as control over its keys, and in the cloud the question that matters is who can use, disable and destroy the key. The four common models trade that control against compatibility with the provider's own services and against the customer's operational burden.

Two properties are worth separating. Reach: wherever key material sits inside the provider's key service, whoever generated it, it is within the provider's operational reach; only a key manager outside the provider removes it. Revocability: generating and importing key material gives the customer a unilateral off-switch while leaving the key in a service the provider's other services already integrate with. Higher control usually costs either compatibility or availability, so the right model is the lowest rung that meets the stated threat.

Client-side (application-level) encryption is a separate choice: data is encrypted before it reaches the provider and the keys never go there. It gives strong confidentiality against the provider, but the provider's native services (search indexing, analytics, server-side processing) see only ciphertext and stop working on that data.

Envelope encryption is a two-level key hierarchy in which data encryption keys (DEKs) encrypt the data and a key-encryption key (KEK), also called a master or root key, encrypts (wraps) the DEKs. The KEK stays inside the key management service or HSM; the wrapped DEK is stored next to the ciphertext it protects. This is the layered key hierarchy that NIST SP 800-57 describes, and it is how cloud key services handle bulk data.

1. The application asks the key service for a data key under a named KEK.
2. The service returns the DEK twice: in plaintext, and wrapped under the KEK.
3. The application encrypts the data locally with the plaintext DEK, discards the plaintext DEK from memory and stores the wrapped DEK with the ciphertext.
4. To decrypt, the application sends only the small wrapped DEK to the key service, which unwraps it if policy allows.

Three consequences follow, and each is a reason the design is used:

• Throughput. Only small key-wrapping calls reach the key service, so terabytes of data never pass through a service built for small payloads with request quotas.
• The master key never leaves the service. Applications only ever hold short-lived plaintext DEKs, so compromising an application server does not expose the key that protects every other DEK.
• Cheap rotation. Rotating the KEK does not re-encrypt the bulk data. The service keeps earlier KEK versions so it can still unwrap old DEKs, or the small wrapped DEKs are rewrapped under the new version; the object ciphertext is untouched and stays readable.

The key lifecycle

Every key passes through generation (from a strong random source, ideally inside an HSM), distribution, storage, use, rotation, revocation or suspension, and destruction. Good practice separates duties (those who administer keys do not also administer the data), restricts key use by policy, logs every key operation and keeps keys away from the data they protect. Destroying keys to make data unrecoverable, crypto-shredding, is a deletion technique covered with retention and deletion in sub-domain 2.7.

A hardware security module (HSM) is a tamper-resistant device that generates, stores and uses cryptographic keys so that key material never leaves it in plaintext. HSMs are how a requirement for hardware-based key protection is met: encrypting a key in software, wherever that software runs, protects it only as well as the system around it.

What "validated" means

Validation is a property of a cryptographic module, not of an algorithm. FIPS 140-3 is the US and Canadian standard for cryptographic modules, and the Cryptographic Module Validation Program (CMVP), run by NIST and the Canadian Centre for Cyber Security, tests modules through accredited laboratories and publishes a certificate for each one. An algorithm can be approved while the module implementing it has never been tested, so a module requirement is evidenced by a current CMVP certificate for the specific module in use, at the required security level, with the module configured in its approved mode of operation (a validated module run outside that mode is not operating as validated). General assurance about a provider's controls or management system is a different kind of evidence and does not substitute for module validation. FIPS 140-2 validations moved to the CMVP historical list on 21 September 2026, so a current certificate is now a FIPS 140-3 one. The four security levels themselves are covered in the lesson on evaluating cloud service providers (sub-domain 1.5).

Multi-tenant key service versus single-tenant cloud HSM

Validation level and administrative control are separate questions: a module's level describes how it resists attack, not who holds its administrator credentials.

A cryptographic hash function turns any input into a fixed-length digest; changing even one bit of the input changes the digest unpredictably, and the function cannot be reversed. Hashing therefore gives integrity (detecting change), not confidentiality, and the digest is useful only if the person checking it obtains it from a source the attacker cannot alter.

Verifying integrity

When files travel through parties you do not trust, such as third-party download mirrors, the publisher publishes each file's digest through a channel it controls (its own website, a signed release note) and recipients compare it with the digest of what they received. The digest has to travel by a different path from the file: if both come from the same untrusted party, a substituted file arrives with a matching substituted digest.

The same logic applies inside an organisation. Integrity checking defends only against people who cannot also forge the reference value. Against privileged insiders, the reference must be something they cannot recreate, typically a digital signature over the digest made with a key under separate control, outside their administrative reach.

Storing passwords

Passwords are stored as hashes so the system can check a login without keeping the password, but a plain fast hash such as unsalted SHA-256 fails in two ways: identical passwords produce identical digests, so precomputed (rainbow) tables apply; and the function is fast, so GPUs can try billions of guesses a second. The fix addresses both causes:

• a unique random salt per user, stored with the hash, so precomputed tables and cross-account cracking stop working;
• a deliberately slow, tunable password-hashing function (Argon2id, scrypt, bcrypt, or PBKDF2 with a high iteration count), memory-hard where possible, so each guess is expensive.

Both measures are needed because they defeat different attacks: the salt defeats precomputation and cross-account reuse, and the work factor makes each individual guess expensive. Password storage should also be one-way; a reversible scheme turns a key compromise into the disclosure of every password.

Non-repudiation is assurance that the originator of a message or action cannot credibly deny it, and it requires a digital signature made with a private key under one party's sole control. A plain hash proves only that data has not changed. An HMAC (a hash keyed with a secret) proves integrity and that the message came from someone holding the shared key, but both parties hold that key, so an HMAC cannot show a third party which of them created a message.

Two design points follow. First, non-repudiation attaches to whoever controls the signing key, so the key must belong to the party whose action is to be proved; a key shared by a team or held by a service proves only that the team or service acted. Second, signing and encryption use the key pair in opposite directions: a signature is made with the signer's private key and checked with the public key, while encryption for confidentiality uses the recipient's public key. Trusted timestamps can add proof of when something was signed. Chain of custody and non-repudiation of logged data events are covered in sub-domain 2.8.

Data obfuscation replaces or hides sensitive values so that data can be used without exposing them. The main techniques differ on two questions: is the change applied to a stored copy or at the moment of viewing, and can anyone reverse it?

Static versus dynamic masking

Masking techniques include substitution with realistic values, shuffling within a column, truncation or partial redaction, nulling and character scrambling. Two properties of a masking scheme are worth checking. Consistency: deterministic masking maps the same input to the same output every time it is applied, which preserves joins and referential integrity; random substitution does not. Irreversibility: masked data is irreversible only when nothing that could map values back, whether a key, a lookup table or a log, survives the process.

Anonymization versus pseudonymization

Anonymization irreversibly removes the ability to identify a person, by anyone, using means reasonably likely to be used; truly anonymous data is no longer personal data and falls outside the GDPR (Recital 26). Pseudonymization replaces identifiers with codes or tokens so that data can be attributed to a person only with additional information kept separately (GDPR Article 4(5)). Pseudonymized data is still personal data: as long as the additional information that re-links it exists within the organisation's reach, the data is pseudonymized. Pseudonymization remains a valuable safeguard that the GDPR encourages; it simply does not take data out of scope.

Removing names, emails and phone numbers is not anonymization. Quasi-identifiers, fields that are not identifying alone but are in combination (postcode, birth date, exact timestamps, location traces), let attackers re-identify people by linking a data set with outside sources. The root-cause fix before a release is to generalise (coarser postcodes, time bands, age ranges) or suppress quasi-identifiers until no record can be singled out, measured with models such as k-anonymity. Differential privacy, which adds calibrated noise to results, is covered with AI and ML data protection in sub-domain 2.9.

Tokenization replaces a sensitive value, such as a primary account number (PAN), with a surrogate token that has no mathematical relationship to the original; the mapping back to the original is kept in a separately secured token vault. Systems that hold only tokens cannot reveal card numbers if breached, which is why tokenization is the standard way to reduce PCI DSS scope: systems that store, process or transmit only tokens, and cannot reach the vault or detokenize, can be taken out of the cardholder data environment.

Vault-based versus vaultless tokenization

A vault is a central lookup database: highly protected, but every detokenization must reach it, and every copy of it is another copy of the most sensitive store. Vaultless approaches derive the token cryptographically, most commonly with format-preserving encryption (FPE), standardised as the FF1 mode in NIST SP 800-38G, which turns a 16-digit number into another 16-digit number. FPE keeps the format and is reversible by authorised holders of the key without any lookup database; the key becomes the thing to protect. Its trade-off mirrors the vault's: no central database to reach or replicate, but anyone who obtains the key can reverse every value, so the key must be managed as strictly as a vault would be.

Data loss prevention (DLP) is a set of controls that find sensitive data, watch how it is used and moved, and enforce policy to stop it leaving authorised boundaries. It has three functional components, applied in order:

1. Discovery and classification: scanning storage (buckets, file shares, databases, SaaS tenants) to learn where sensitive data already sits. It comes first so that later rules target the right data.
2. Monitoring: watching data at rest, in motion (on the network) and in use (on endpoints) for policy matches.
3. Enforcement: acting on a match by blocking, quarantining, encrypting, alerting or requiring a justification.

New rules should run in monitor-only (audit) mode first: matches are logged without affecting anyone, so false positives can be measured and the rule tuned before blocking begins.

The encrypted-traffic blind spot

A network DLP gateway inspects content, so traffic it cannot read it cannot match. Most uploads use HTTPS; unless the gateway or proxy performs TLS inspection (decrypting and re-encrypting with a certificate the managed devices trust), it sees only ciphertext.

Choosing a deployment for cloud

Each deployment sees only the channels and devices it sits on, so mature programmes combine several and choose by where the data moves and which devices are in play.

Secrets (passwords, API keys, tokens, connection strings) and certificates are keys in everyday form, and they are managed with the same aims: keep them out of places attackers can read, limit how long and where each is useful, and automate their lifecycle.

Secrets

• No credentials in code or repositories. Committed secrets spread to every clone, build log and fork, and remain in the version history. Remove them, rotate them (they must be treated as exposed), and scan repositories so it does not recur.
• Retrieve at runtime from a managed secrets store, authenticated by the workload's own identity (a role or managed identity) rather than another stored secret. Because the value is fetched rather than packaged, it can change without a rebuild or redeployment.
• Handle rotation in the client. Rotation is only safe if every consumer picks up the new value without intervention; a client that reads a secret once and keeps it for its whole lifetime breaks at the next rotation. Clients should cache briefly and re-fetch periodically and on authentication failure.
• Prefer short-lived, per-workload (dynamic) credentials. A secrets store that issues each service its own credential on request, valid for minutes or hours, means a leaked credential works briefly and only for one service, with no manual rotation.

Certificates

The certificate lifecycle is request, issuance, deployment, monitoring, renewal and revocation, with the private key protected throughout (ideally generated and kept in an HSM or key service). The commonest certificate failure is an unnoticed expiry, and it grows with the number of issuers and owners; the control that addresses it is a central certificate inventory with expiry alerting and automated renewal (for example through the ACME protocol). CA/Browser Forum rules are shortening the maximum lifetime of public TLS certificates in stages, toward 47 days by 2029, so renewal is now frequent enough that only automation keeps up.

When a private key is compromised, two steps close the exposure: generate a new key pair and install a certificate for it, and have the CA revoke every certificate for the old key, published through certificate revocation lists (CRLs, required for public TLS certificates) and, at some CAs, OCSP. A certificate is only a binding to a public key, so every certificate for the compromised key, whatever its serial number, must go; until revoked they remain valid until expiry. Revocation checking by clients is uneven, which is one more reason short lifetimes help. Certificates used inside information rights management are covered in sub-domain 2.6.