Encryption at Rest and Key Boundaries

This lesson is not about checking a box labeled “encryption enabled.” It is about making the trust boundary inspectable: what stored data is protected, where key authority lives, which workload may decrypt, which compromise collapses the benefit of encryption, and how rotation and recovery remain accountable. The final learner artifact is At-Rest Encryption & Key Boundary Record v1. The executable lab is SEC012-LAB1, and it uses only fake ciphertext identifiers and mock key handles. No real key material, production account, external target, or external key-management service is required.

1. Define the at-rest protection boundary

At-rest encryption protects stored data only within a declared threat model. A database snapshot, filesystem copy, backup object, or stolen storage device can be a meaningful at-rest threat when the attacker does not also obtain the authority needed to decrypt. The existence of ciphertext is therefore not enough. The evidence record must state which compromise path is being reduced and which compromise path remains outside the lesson.

Encryption at rest does not protect plaintext after an authorized application legitimately decrypts it. If a fully compromised workload already has decrypt authority, the security question moves into application compromise, authorization, isolation, runtime trust, or adjacent identity controls. SEC-012 does not absorb those lessons. It records that residual boundary explicitly so that a successful decrypt test is not overstated as universal confidentiality proof.

2. Separate data, DEK, KEK, and decrypt authority

The key reasoning move is to model four different things: the data or ciphertext, the Data Encryption Key (DEK), the Key Encryption Key (KEK) authority, and the workload allowed to request decryption. An encrypted DEK may be stored with ciphertext, while the KEK authority remains in a different trust boundary. The design becomes weaker when the same compromise path exposes both the stored data and the key authority that makes the encrypted key usable.

OWASP-CRYPTO-STORAGE is used only inside this claim boundary: threat-model-driven at-rest architecture, separation of keys and data, and the DEK/KEK relationship. In the lab, identifiers such as dek-primary-v1 and kek-authority-primary are labels, not cryptographic keys. The lab does not implement custom cryptography. Its purpose is to make boundary decisions deterministic and observable.

3. Key storage is a trust boundary, not a filename

A string placed in source code, a repository, or ordinary configuration is not automatically a durable key vault. If compromise of the application source or configuration also exposes the material needed to decrypt the database, the supposed separation may be mostly cosmetic. The evidence record therefore records the storage model and the compromise relationship, not merely a path name.

This lesson does not select a cloud KMS vendor, HSM product, or secret-manager brand. It uses OWASP-KEY-MGMT within the frozen source boundary for lifecycle, storage, compromise, backup/recovery, and related key-management reasoning. The lesson-specific record is a MAKNOW instructional artifact, not an OWASP-defined standard record format.

4. Rotation means accounting for old and new paths

Key rotation is not complete merely because a new identifier exists. A defensible rotation state explains which key reference encrypts new data, how historical objects remain decryptable when that is required, when the old reference is retired or revoked, and which recovery metadata is needed before an incident occurs. If the new key is active but historical objects silently lose their path, the design has created an availability and recovery failure rather than a successful rotation.

SEC-012 does not prescribe one universal cryptoperiod. Rotation timing depends on the threat model, sensitivity, compromise indicators, algorithm or implementation changes, operational constraints, and organizational policy. The local lab checks narrower invariants: a current key identifier exists, historical references are accounted for, old/new references are not ambiguous, and recovery requirements are not invented after the failure.

5. Recovery is part of the security boundary

Encrypted data may become permanently unavailable when key material is lost. Recovery must therefore be designed before a key loss or compromise event. However, a recovery path is itself a powerful authority. If recovery authority is colocated with the data store or granted too broadly, it can erase the separation the architecture intended to create.

The evidence record captures recovery ownership and recovery metadata without storing any real key material. One deliberate negative probe removes recovery metadata from a context that requires recovery. The expected result is denial of a recoverability claim. This Negative Evidence matters because the lesson must prove that missing recovery information changes the decision rather than simply documenting a happy path.

6. Distinguish ciphertext access from decrypt authority

Possession of ciphertext is not equivalent to permission to decrypt. A storage reader may be able to see fake ciphertext identifiers and a key handle while still lacking authority to invoke the key boundary. In the synthetic fixture, service:primary-api and service:backup-recovery are distinct authorized workloads for different contexts. A workload outside the declared set must be denied even if it can name the key handle.

This is not production IAM. It is a local oracle that forces the learner to preserve the difference between stored-data access, key references, and decrypt authority. The record must not convert “can read encrypted data” into “may decrypt data.”

7. Evidence schema

Each row in At-Rest Encryption & Key Boundary Record v1 contains: data_class, storage_boundary, ciphertext_location, key_handle, kek_authority, decrypting_workload, rotation_state, recovery_evidence, observed_evidence, and residual_risk. Values must come from the synthetic fixture and observed lab results rather than invented security claims.

Positive Evidence demonstrates a declared healthy path: a storage boundary contains ciphertext and a key reference, key authority remains separate, an authorized workload follows the decrypt path, and the current key reference is explicit.

Negative Evidence preserves at least one meaningful failure: collapsed key authority, unauthorized decrypt workload, missing recovery metadata, a hard-coded key location, or an incomplete evidence row. Failure output is evidence and must not be erased merely to make the final report look cleaner.

The starter intentionally leaves rows, positive_evidence, negative_evidence, owner_acceptance, and the final changed-context decision blank. Production proof is always false.

8. SEC012-LAB1

The lab runs with the Python standard library only. It does not perform real encryption. golden-policy.json defines two independent contexts: primary_database and backup_archive. Each context has a storage boundary, key handle, KEK authority, authorized decrypt workload, current key identifier, historical key references, and recovery requirement. baseline-data.json contains fake ciphertext object identifiers.

Run static_preflight.py first to verify local-only restrictions and the prohibition on network calls, real key material, custom crypto, external targets, or production proof. Run public-contract.test.py next. Finally, run_local_lab.py prints a bounded example record. The purpose is not to claim “encryption works”; the purpose is to show that the decision rule is deterministic and reviewable.

9. Failure probes

Probe A — collapsed key authority

If kek_authority collapses into the same boundary as the ciphertext store, the expected result is BOUNDARY_WEAKENED_KEY_AUTHORITY_COLLAPSED. A label saying “KMS” does not create isolation by itself.

Probe B — unauthorized decrypt workload

If an undeclared workload attempts the decrypt operation, the expected result is DENY_DECRYPT_AUTHORITY. Naming a key handle or reading ciphertext is not decrypt authorization.

Probe C — missing recovery metadata

If recovery is required but the recovery metadata is empty, the expected result is DENY_RECOVERY_METADATA_MISSING.

Probe D — rotation accounting

If the current key changes but historical objects still reference an old key and the old/new mapping is not explicitly accounted for, the expected result is DENY_ROTATION_HISTORICAL_PATH_UNACCOUNTED. A repair must preserve the declared historical path while directing new data to the new key identifier.

Probe E — key stored in source/configuration

If the model places key material in application_source or ordinary_config, the expected result is DENY_KEY_STORAGE_BOUNDARY. The probe uses labels only and exposes no secret.

10. Residual risk

A valid boundary does not eliminate every compromise. A fully compromised authorized decrypting workload may abuse its existing authority. A compromised recovery authority may become a bypass path. Removing historical keys too early can make required data unrecoverable; retaining them indefinitely may extend exposure. The learner must state which path was tested and which path remains outside the evidence.

The lesson does not claim that encryption solves authorization, that one cryptoperiod fits every system, that custom cryptography is preferred, or that a successful decrypt test certifies production security.

11. Rotation and historical data

The local model distinguishes the current key identifier from historical key references. A valid rotation event names the previous key, the new current key, the set of historical objects that still require the old path, and the recovery metadata that covers that state. If historical object references are present but no old-key accounting exists, the rotation result is denied.

This models an operational truth without implementing encryption: lifecycle has to be prepared before the compromise or retirement event. The important evidence is the explicit mapping and the observed decision, not a screenshot of a “rotate” button.

12. Changed-context transfer

The independent transfer compares a synthetic primary_database and backup_archive. Their recovery needs differ, so the learner must redesign their boundaries independently rather than copying the baseline. Storage location, key authority, decrypting workload, rotation state, and recovery evidence must each be reconsidered.

The transfer template intentionally leaves the final decision blank. AI may help organize observed output after the learner states the bounded objective, but it may not supply the decisive security conclusion, invent recovery evidence, or fill owner acceptance.

13. Assessment

The retrieval item states the bounded rule and one non-goal. The application item produces evidence from the local fixture. The diagnosis item explains one failed boundary. The decision item rejects a shortcut such as “store the key next to the database because the database is encrypted.” The transfer item redesigns the second context without copying the first context’s decision.

Blocking conditions include unsupported security claims, happy-path-only proof, and missing negative or transfer evidence. The record must separate observation from inference and keep residual risk explicit.

14. Sources and freshness

OWASP-CRYPTO-STORAGE is used only for the at-rest architecture boundary, threat-model reasoning, separation of keys and data, and DEK/KEK separation. OWASP-KEY-MGMT is used only for key lifecycle, storage, compromise, recovery, and related management boundaries. No new source is added during authoring. A current-primary-source check was performed on 2026-09-16 within this frozen two-source boundary, with the next review due on 2026-10-02.

15. Completion standard

The learner completes At-Rest Encryption & Key Boundary Record v1 with traceable rows, Positive Evidence, Negative Evidence, an independent changed-context transfer, and a clear Residual Risk statement. owner_acceptance remains blank in the starter. No real keys or production systems are used, and the lab never claims production proof.