Hierarchical Key Model

Every protected object in Lattix is encrypted under its own unique key. That key is itself encrypted under a tenant-held key. The outer key never leaves the tenant's chosen key management backend. This two-layer pattern is called envelope encryption, and it is what makes Lattix's access control actually effective: the envelope cannot be opened without a fresh, policy-authorized key release.

The three roles

• Data Encryption Key (DEK). A unique symmetric key generated per data object. The object's payload is encrypted under this key using authenticated encryption (AEAD), so any tampering with the ciphertext is detectable on unwrap. The DEK is written into the envelope's manifest, but only in a wrapped (re-encrypted) form.

• Key Encryption Key (KEK). A tenant-held key that wraps DEKs. KEKs are organized hierarchically — there can be separate KEKs per tenant, per policy scope, and per rotation epoch — so that revoking access at any of those levels is a matter of rotating or retiring a single KEK rather than re-wrapping every individual object.

• Key Access Service (KAS). The service that holds the KEKs (or holds references to them in an HSM or KMS), evaluates whether a given request is authorized to unwrap a given DEK, and releases the unwrapped DEK if policy allows. Every KAS operation produces a ledger record.

How unwrapping actually works

1. A consumer presents a wrapped object and a signed policy decision to the KAS.
2. The KAS verifies the decision signature and its binding to the specific object identity.
3. The KAS retrieves the appropriate KEK (from the tenant's configured backend — KMS, HSM, or cloud-managed service).
4. The KAS unwraps the DEK, returns it to the consumer, and records the operation on the ledger.
5. The consumer uses the DEK to decrypt the object locally. The DEK is ephemeral — it is not persisted by the consumer.

If step 2 or 3 fails — invalid decision, expired decision, revoked KEK, or an access rule on the KEK itself rejects the request — the DEK is never released and a denied-access record is written.

Why the hierarchy matters

The hierarchical structure is deliberate. A flat model where every object is encrypted under a single tenant-wide key means that revocation requires rewrapping every object. A fully-per-object model gives maximum isolation but makes large-scale key rotation expensive.

The hierarchy gives you intermediate granularity:

• Rotate the tenant-level KEK to force a full re-authorization pass.
• Rotate a policy-scope KEK when the policy itself changes materially.
• Rotate the epoch-level KEK on a regular schedule to bound the impact of any theoretical KEK compromise.

Because every DEK is wrapped under a specific KEK at a specific epoch, retiring a KEK precisely scopes the revocation to objects wrapped under it.

Supported key management backends

Lattix does not manufacture key storage — it integrates with the services your organization already trusts. At tenancy creation time, an administrator chooses the backend that will hold the tenant's KEKs:

• AWS KMS
• Google Cloud KMS
• Azure Key Vault
• HashiCorp Vault Transit engine

Customer-managed hardware security modules (HSMs) are supported through the same integration layer. For coalition or multi-organization scenarios, different tenants in the same deployment can use different backends without coordination — the KEK never leaves the tenant's chosen backend, and cross-tenant operations rely on decisions and wrapped DEKs rather than shared key material.

Why the consumer never sees the KEK

The KEK is the thing that makes the envelope openable at all. Restricting it to the KAS, backed by a KMS or HSM, means that:

• A compromised consumer exposes at most the DEKs of objects they've recently unwrapped, not the ability to unwrap more objects.
• A compromised storage layer exposes ciphertext, not cleartext — the KEK is not in storage.
• An exfiltrated envelope, on its own, reveals nothing — the adversary needs a positive policy decision to unwrap it.

Relationship to other concepts

• KEKs are gated by the Policies and ABAC layer: only a signed, valid decision causes a DEK release.
• Every release event is logged to the Immutable Ledger.
• KEK algorithms and rotation schedules interact with Post-Quantum Encryption — the choice of wrapping algorithm is policy-configurable per tenant.