Hierarchical Key Model

Every protected object in Lattix is encrypted under its own unique key. That key is itself wrapped — key-encrypted — by a tenant-scoped key that remains inside a trusted key service boundary. Whether that wrap can ever be undone for a given requester is governed by a separate control plane that evaluates policy for every request. This 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 unwrap.

The model is easier to reason about as four layers than as a flat list of keys. The first two layers are the cryptographic artifacts that touch data; the second two are the protection and control around them. Conflating them is a common source of threat-modeling errors.

The four layers

Data (Layer 1). The plaintext object to be protected — a file, record, stream, or segment. Once protected it exists only as ciphertext, alongside a wrapped DEK and the policy binding in the envelope manifest.

Data Encryption Key (DEK — Layer 2). A unique symmetric key generated per data object. The DEK is the content key: the only key that ever touches the payload. Encryption uses authenticated encryption (AEAD), so any tampering with the ciphertext is detectable on unwrap. The DEK is written into the envelope's manifest only in wrapped form — it is never stored at rest in plaintext and is never persisted on the consumer.

Key Encryption Key (KEK — Layer 3). A tenant-scoped key that wraps the DEK. The KEK does not encrypt the payload directly; it encrypts the DEK. A single KEK can wrap many DEKs, but the mapping is an architectural choice rather than a universal hierarchy — a tenant may configure one KEK per tenant, per dataset, per policy domain, per rotation epoch, per object class, or even per object. Whichever scope is chosen, the KEK remains inside the trusted key service boundary; only the unwrap operation is exposed across that boundary.

Control plane (Layer 4). The authorization and key-use tier, with three cooperating roles:

• The Policy Decision Point (PDP) evaluates policy for a specific request and emits a signed decision.
• The Key Access Service (KAS) is the policy enforcement point for key release. It verifies the signed decision, binds it to the specific object, and — if authorized — invokes the unwrap operation inside the trusted boundary. Every KAS operation produces a ledger record.
• The KMS or HSM is the trusted key service that actually executes the key use. Depending on the deployment, the KAS may broker operations into a separate KMS or HSM, or it may itself be the boundary that holds and uses KEKs directly. In either case the raw KEK is not exported; only the result of the authorized operation crosses the boundary.

The KAS is not cryptographically above the KEK. The KEK is a protection key; the KAS is a control-plane authority that mediates the KEK's use. Keeping that distinction clean is what lets a threat model reason about each layer independently.

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, acting as the policy enforcement point for key release, invokes the unwrap operation inside the trusted key service boundary — either against an embedded KMS/HSM or by brokering to the tenant's configured backend. The KEK itself is not exported across the boundary.
4. The result of the authorized operation — the unwrapped DEK, or (in deployments that prefer it) a short-lived derived key or decryption capability — is returned to the consumer. The operation is recorded on the ledger.
5. The consumer uses the DEK (or derived capability) to decrypt the object locally. Whatever is returned 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 that refuses the unwrap — no key or capability is released and a denied-access record is written.

Whether the KAS returns a raw DEK or a transformed short-lived key is a deployment-level trust-model choice. Returning the raw DEK keeps the decrypt cheap and local but makes the consumer part of the trusted decrypt path, so endpoint hardening matters. Returning a derived capability keeps more of the key material inside the trusted boundary at the cost of extra round-trips.

Why KEK scoping matters

KEK scoping is an architectural choice, not a universal hierarchy. A single tenant-wide KEK means every revocation requires rewrapping every object beneath it. A KEK per object gives maximum isolation but makes large-scale rotation expensive. Intermediate scopes — per dataset, per policy domain, per rotation epoch, per object class — are what most deployments actually use, because they let a single rotation precisely target the objects that need to be affected:

• 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 blast radius of any theoretical KEK compromise.

Because every DEK is wrapped under a specific KEK at a specific epoch, retiring that KEK cleanly scopes the revocation to objects wrapped under it — no rewrapping is required for objects outside the scope. The tenant chooses where in this spectrum to sit; Lattix does not impose a fixed hierarchy.

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 host 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 remains inside each tenant's chosen boundary (only the unwrap operation crosses it), and cross-tenant flows rely on decisions and wrapped DEKs rather than shared key material.

Why the KEK stays inside the trusted boundary

The KEK is the thing that makes the envelope openable at all. Keeping it inside the trusted key service boundary — whether that boundary is a KMS, an HSM, or a KAS that embeds one — means that:

• A compromised consumer exposes at most the DEKs (or short-lived derived capabilities) of objects it has recently unwrapped, not the ability to unwrap more objects.
• A compromised storage layer exposes ciphertext, not cleartext — the KEK is never in storage alongside the data.
• An exfiltrated envelope, on its own, reveals nothing — the adversary needs a positive policy decision and a KAS-authorized unwrap before the KEK will be used against it.

Relationship to other concepts

• Use of the KEK is gated by Policies and ABAC: the PDP decides, and the KAS enforces by authorizing the unwrap only on a signed, valid decision.
• Every release event is logged to the Immutable Ledger.
• KEK algorithms and rotation schedules interact with Cryptographic Agility — the choice of wrapping algorithm is policy-configurable per tenant.