Key Management in Data-Centric Security: Who Holds the Keys

Data-centric zero trust wraps every data object with its own encryption and its own access policy. That architectural promise is elegant. Its operational reality is not. Somewhere, someone holds the keys that unwrap those objects. Someone decides whether to release them. The quality of a data-centric deployment is ultimately the quality of its key management infrastructure.

This post walks through the cast of characters in key management systems: data encryption keys, key encryption keys, key access servers, and policy authorities. It explains envelope encryption in practice, the topology trade-offs between centralized and federated key servers, and the critical decision path when a user requests access. It covers rotation, revocation, and post-quantum key encapsulation. And it shows how Lattix Technologies implements key management as the foundation of its cryptographic enforcement model.

The Cast of Characters in Key Management

Data encryption keys (DEKs) protect individual data objects. Each object gets its own DEK, generating a unique ciphertext. Key encryption keys (KEKs) protect DEKs. A single KEK can protect many DEKs, creating hierarchy. Key access servers (KASes) hold KEKs and release them only under policy. Policy authorities (PAs) define who can access what, evaluated at key release time. Requesters consume the decryption material and unwrap objects.

The separation of roles is not accidental. A data object encrypted under a DEK is useless without the DEK. A DEK wrapped under a KEK is useless without the KEK. And the KEK is useless without the policy authority's permission. Chain the authorities correctly, and a single policy change revokes access to thousands of objects without re-encrypting any of them.

Envelope Encryption in Practice

Two-layer envelope encryption is the structural foundation of data-centric security. Here is the concrete flow:

During enrollment, Lattix generates a unique DEK for each data object and encrypts the object's plaintext under that DEK. The DEK itself is then wrapped under a KEK held by the policy authority. The wrapped object and the wrapped DEK travel together. Neither is useful alone. The DEK never appears in plaintext except inside the HSM or at the policy authority's KAS.

When a requester asks to decrypt, the KAS performs attribute collection (who is asking, from where, with what credentials). The policy authority evaluates those attributes against its policy rules. If the attributes satisfy the policy, the KEK releases the DEK. If they do not, the request fails and the key release is denied. The key release decision is logged immutably and, in Lattix deployments, anchored to a Merkle-tree lineage stored in the Cryptographic Authority Service (CAS-X).

This structure means that changing access policy does not require re-encrypting data. Policy changes apply only to future key release decisions. Objects already unwrapped are already decrypted. Objects not yet accessed remain protected by the old KEK until the next rotation event.

Topology Trade-Offs: Centralized Versus Federated KAS

A centralized KAS is a single point of decision and a single point of failure. One KAS, one policy authority, one HSM. Fast decision path. Simple audit trail. One compromise breaks everything. For organizations protecting data within a single jurisdiction or with unified policy authority, centralized KAS is the right choice.

Federated KAS topologies distribute key access servers across organizational boundaries. Different organizations can host their own KAS, each protecting KEKs it manages. A requester's attribute collection query can traverse multiple KASes in sequence, with each contributing attributes and policy evaluation. This enables true classified data sharing across coalition partners without centralizing trust in a single authority.

The cost is operational complexity. Cross-domain audit becomes intricate. Revocation at one KAS must propagate to others. Key rotation requires coordination. Organizations choosing federation must invest in interoperability standards like the TDF KAS protocol or OpenTDF KAS specification. The Lattix KAS implementation supports both topologies, allowing hybrid deployments where some domains are federated and others remain centralized.

Policy Evaluation at Key Release Time

The critical path begins when a requester presents a wrapped object to the KAS. The KAS immediately collects attributes: the requester's identity, their source IP, their clearance level, the data's classification level, the current time, and any other attributes the policy authority has defined. The policy authority, typically colocated with the PA PDP (policy decision point), evaluates those attributes against a policy expression. Lattix supports policy evaluation via OPA Rego and custom attribute-based access control (ABAC) expressions.

The policy decision is either PERMIT or DENY. If PERMIT, the KAS unwraps the KEK (stored in an HSM and never exposed in plaintext), uses the KEK to unwrap the DEK, and returns the DEK to the requester or a secure proxy. If DENY, the request is logged, the KAS returns nothing, and the requester cannot decrypt. Decision logging includes the request timestamp, requester identity, attributes collected, policy rules evaluated, and the final decision. This log becomes the audit surface for compliance and incident response.

The entire decision path must complete in under 100 milliseconds for interactive workflows. Lattix deployments achieve this through attribute caching (refreshed on user login), policy pre-compilation (Rego code compiled to bytecode), and HSM tuning. The result is a system where billions of key release decisions can flow safely through policy enforcement without grinding to a halt.

Rotation, Revocation, and Re-Wrapping

Keys must change. Policies must change. Lattix separates these two control surfaces. Key rotation changes the KEK while keeping access policy stable. A new KEK is generated, and outstanding wrapped DEKs are re-wrapped under the new KEK. This re-wrapping does not need to happen immediately. Lattix uses lazy migration: as data objects are accessed, their DEKs are re-wrapped under the new KEK. Objects that are never accessed again maintain their old wrapping until they are deleted.

Revocation is different. When access policy changes to deny a previously permitted user, the user cannot request key release going forward. But if they already unwrapped the DEK before revocation, they have it in their own memory. Revoking their access does not take back the key. This is a hard architectural truth: revocation of read access is trivial before unwrap, trivial after deletion, and hard in between. Lattix addresses this through Merkle-tree lineage anchoring in CAS-X, allowing detection of out-of-policy access retroactively.

The Post-Quantum Dimension

Wrapped data is intended to survive five, ten, or twenty years. The KEK algorithm chosen today must survive the arrival of cryptographically relevant quantum computers. Classical RSA-2048 and ECDH will not. NIST published the ML-KEM family (FIPS 203) in August 2024. NSA CNSA 2.0 directs national security systems to transition to ML-KEM-768 or ML-KEM-1024 by January 2027.

Lattix supports both classical and post-quantum key encapsulation. The KAS can generate and manage ML-KEM-768 and ML-KEM-1024 keys today. New data enrollments can be wrapped under post-quantum KEKs. Existing data wrapped under classical KEKs can be re-wrapped lazily during migration periods. For organizations protecting long-confidentiality classified data, the migration is already late. For commercial enterprises protecting trade secrets, the timeline is tighter than it appears.

Lattix: Data-Centric Key Management in Practice

Lattix Technologies implements key management as the architectural core of its data-centric zero trust framework (ZTDF). The Lattix PDP (policy decision point) is colocated with the policy authority. The Lattix KAS can be deployed centralized or federated. Key wrapping uses NIST-validated cryptographic modules (FIPS 140-3 Level 3). DEK generation uses NIST FIPS 203 post-quantum key encapsulation. HSM management follows NIST SP 800-57, NIST SP 800-130, and NIST SP 800-152.

Key rotation is automated on configurable schedules. Re-wrapping is lazy, with progress tracked through CAS-X Merkle-tree lineage. Policy changes propagate within 60 seconds across federated topologies. Audit logging is cryptographically anchored. Access is enforced fail-closed: if the policy authority becomes unreachable, the KAS denies all key release requests rather than defaulting to permit.

Organizations deploying data-centric zero trust with Lattix can bind access policy to key release at enrollment time and enforce it for the life of the data. That enforcement is only as strong as the key management system that backs it. This post has shown the architecture, the trade-offs, and the operational discipline required to make it work.

References

1. NIST SP 800-57, Part 1: Recommendation for Key Management. National Institute of Standards and Technology, May 2022.
2. NIST SP 800-130: A Framework for Designing Cryptographic Key Management Systems. National Institute of Standards and Technology, December 2013.
3. NIST SP 800-152: Guidelines for Identifying Appropriate Cryptographic Mechanisms for Federal Applications. National Institute of Standards and Technology, July 2014.
4. NIST FIPS 140-3: Security Requirements for Cryptographic Modules. National Institute of Standards and Technology, December 2019.
5. NIST FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard. National Institute of Standards and Technology, August 2024.
6. OASIS Key Management Interoperability Protocol (KMIP) 2.1. Organization for the Advancement of Structured Information Standards, January 2023.
7. NSA Commercial National Security Algorithm Suite 2.0 (CNSA 2.0). National Security Agency, December 2022.
8. OpenTDF KAS Specification. OpenTDF Community, 2024.
9. TDF Data Format and KAS Protocol. OpenTDF Community, 2024.