14.2 Key Handling and Safe Cryptographic Operations

The Key Is the Real Secret

Encryption is only as strong as the way its keys are handled. A public, peer-reviewed algorithm like AES with a well-protected key gives strong confidentiality; the same algorithm with a key pasted into a chat message, committed to a public repository, or saved next to the encrypted backups gives almost none. The exam tests this judgment constantly. When a scenario says "the data is encrypted," do not stop — ask who can reach the key, how the key is protected, and what happens when something goes wrong.

The Key Lifecycle

Keys move through a predictable lifecycle, and a weakness at any stage defeats the control.

A small-business example: the finance team encrypts tax records before uploading them to cloud storage, but saves the key in the same cloud folder. An attacker who reaches the folder now has both the ciphertext and the means to decrypt it. The fix is a managed secret store or key management service (KMS) that restricts access to approved identities, logs every key use, and separates who can read backups from who can administer keys.

Never Hardcode Secrets

Hardcoded keys are one of the most common operational failures on the exam and in real life. A developer drops an API token or encryption key directly into source code to speed up testing. The repository is later cloned, shared with a contractor, or leaked through a continuous-integration (CI) log — and the key is no longer trustworthy. The safe pattern loads secrets at runtime from an approved secret manager, an environment-specific configuration store, or a hardware-backed service. Tickets, spreadsheets, screenshots, and shared folders are equally dangerous because they linger for years where many people can read them.

Least Privilege and Separation of Duties

Key access must match job duties. A storage administrator may run backup jobs without ever reading the encryption key. A security administrator may set key policy without viewing every protected record. An application identity may decrypt one database field, not the entire secret vault. Separation of duties splits sensitive tasks so no single account controls the whole chain, and least privilege grants only the minimum needed. Together they limit blast radius and make misuse easier to spot.

Logging is part of key handling: capture key creation, deletion, policy changes, failed access, and unusual decrypt volume. A sudden spike of decrypt requests from one service account is an early data-theft signal.

Rotation, Revocation, and Recovery

Rotation replaces a key on a planned schedule or after an incident. It is not automatic safety — systems must track which key protected which data, keep old data readable during transition, and avoid outages. Revocation withdraws trust from a key or certificate that is no longer valid; if a private key leaks, the organization revokes the certificate, issues a replacement, and investigates what could have been exposed.

Recovery is a balancing act between availability and confidentiality.

• Lose the only copy of a key and the encrypted data becomes permanently unreadable.
• Spread recovery copies too widely and confidentiality erodes.
• A sound program documents recovery roles, protects escrowed backup keys, tests restoration, and records who touched recovery material.

Mapping Scenarios to Answers

• "The backups are encrypted but cannot be restored" points to recovery / key escrow failures — the key was lost or untested.
• "A developer accidentally committed a key" points to remove it from the repo, rotate, revoke where applicable, and monitor for misuse — the key is now public knowledge.
• "One administrator can both run backups and read all keys" points to separation of duties and least privilege.

The wrong answers on these items usually say "do nothing, the data is still encrypted" — which ignores that an exposed key is no longer a secret.

Hardware Protection and Crypto-Shredding

Two concepts round out CC key handling. A hardware security module (HSM) is a tamper-resistant device that generates, stores, and uses keys so the private key never leaves the hardware in plaintext; cloud providers expose the same idea through a managed KMS. Prefer hardware-backed storage when a scenario stresses that keys must never be exported. The second concept is cryptographic erasure, sometimes called crypto-shredding: instead of overwriting terabytes of encrypted data, you securely destroy the key, rendering the ciphertext permanently unreadable.

This is fast, works well in the cloud, and links key handling directly to the destruction topic in the next section — but it only works if the key was the single gate to the data and no copies survive.

A Worked Example

A SaaS company stores customer files encrypted with per-tenant symmetric keys, and those keys are wrapped (encrypted) by a master key held in an HSM. When a customer cancels, the company crypto-shreds that tenant's key, so the data is unrecoverable even though the bytes remain in backups until they age out. When an engineer leaves, her access to the KMS is revoked the same day, and key-use logs are reviewed for any unusual decrypt activity in her final weeks.

This single design demonstrates generation, protected storage, least-privilege use, revocation, monitoring, and destruction — the full lifecycle the exam expects you to reason about rather than memorize as isolated terms.