How TDF Enforces Access Policy at Decrypt Time

Trusted Data Format (TDF) enforces access policy at decrypt time by never giving the recipient the key. The data encryption key inside a TDF object is wrapped to the public key of a key access server, and the access policy is bound to that key by a keyed hash. To open the object, a client sends a rewrap request. The key access server authenticates the caller, unwraps the key, verifies the policy binding, and asks a policy decision point (PDP) whether the caller's attributes satisfy the policy. Only on allow does the server rewrap the key to the client and return it. Every open is a fresh decision.

The decrypt sequence, step by step

The sequence below follows the OpenTDF protocol. It runs in full every time a TDF object is opened.

1. Manifest read. The client opens the TDF container and parses manifest.json, extracting the key access object and the Base64-encoded policy from encryptionInformation.
2. Ephemeral key generation. The client generates an ephemeral key pair for this request. The public half receives the rewrapped key; the private half never leaves the client.
3. Rewrap request construction. The client builds a signed request, typically a signed JWT, carrying the key access object, the policy, the policy binding and its ephemeral public key.
4. Caller authentication. The key access server validates the request signature and authenticates the caller against the identity provider, rejecting an unauthenticated caller before any key material is touched.
5. Key unwrap. The key access server decrypts the wrappedKey from the key access object using its own private key, recovering the data encryption key in server memory.
6. Policy binding verification. The server recomputes the keyed hash over the supplied policy using the recovered data encryption key and compares it to the manifest policyBinding value. A mismatch means the policy was altered after creation, and the request is rejected.
7. Attribute evaluation. The server passes the verified policy and the caller's identity to the policy decision point, which evaluates attribute-based access control (ABAC) and returns allow or deny.
8. Rewrap and release, or denial. On allow, the server encrypts the data encryption key to the caller's ephemeral public key and returns it. On deny, no key material is returned in any form.
9. Client-side decryption. The client unwraps the key with its ephemeral private key, verifies the payload against the segment hashes and root signature, and decrypts.

Where the key is split across several key access servers, steps 3 through 8 run once per server, and every participating server must return allow before the client can reconstruct the data encryption key. That configuration puts independent organizations in the path of a single release.

What the policy decision contains

Most documentation of TDF stops at allow or deny. The content of the decision is what makes enforcement auditable, and it is the part worth specifying in a requirement. A decision produced by a policy decision point carries the following.

The attributes evaluated extend well past user identity. A production policy decision point evaluates subject attributes, device posture, environment and geography, purpose of use, network posture, risk signals, and the attributes carried by the data object itself. Purpose of use is the one most often omitted and most often required by regulation, because the same person may be entitled to a record for treatment and not for marketing.

What evidence a decrypt attempt leaves behind

Every decrypt attempt reaches the key access server, which makes access to a distributed object observable to its originator. Conventional file encryption cannot provide that, and it is only useful if the record is complete enough to answer questions later.

A usable record covers four things: which object was requested, identified by content identifier rather than filename, since filenames change and copies proliferate; who requested it, resolved to an authenticated identity; what the decision was, with the reasons and the policy version hash that produced it; and when, with enough precision to correlate against other telemetry.

Denials matter more than allows for detection. A pattern of denials against many objects from one identity, or against one object from many identities, is a signal that conventional access logs do not surface, because those logs record file opens rather than authorization outcomes.

Linking decisions into a verifiable chain turns a log into evidence. Merkle-tree lineage records make the decision history for an object tamper-evident and queryable, so an investigator can establish that a decision was recorded and that the record has not been edited since. The broader pattern is covered in data provenance, lineage and chain of custody.

How revocation takes effect

Revocation in TDF is a change to policy or to attributes, not an action on distributed copies. Nothing is recalled and no file is reached out to. Removing an attribute from a subject, adding a clause to the policy, or disabling the subject in the identity provider changes the input to the next evaluation, so the next rewrap request is denied and circulating copies stay ciphertext.

Two boundaries apply. Plaintext already decrypted by a previously authorized user is outside the reach of revocation, because it is no longer a TDF object. And propagation is only as fast as attribute changes reach the policy decision point, so identity provider synchronization intervals are the real revocation latency.

What happens when the key service is unreachable

A client that cannot reach the key access server named in the manifest cannot obtain the key, and the payload stays ciphertext. Fail-closed is the correct default and an availability dependency that has to be engineered for.

Deployments handle this in three ways. A key service can run inside the disconnected enclave, so requests never cross the boundary. Keys can be provisioned in advance for a bounded scope and period, accepting that pre-provisioned material cannot be revoked within its window. Or the workload can be excluded from TDF where availability outranks access governance, which is a legitimate architectural decision rather than a failure.

Tactical and air-gapped deployments make the first option the norm. Enforcement posture should not change across cloud, regional hub, tactical edge and air-gapped environments, because a posture that differs by environment is not actually enforced.

Where enforcement can still be bypassed

Naming the limits of decrypt-time enforcement makes the rest of the description usable.

After release, the plaintext is the endpoint's. TDF governs the object. Once a decision allows and the client decrypts, screenshots, retyping, photography and copying into an unprotected file fall outside the format's scope.

A compromised endpoint sees what its user sees. Malware operating with an authorized user's session obtains the same allow that user obtains. Decrypt-time enforcement narrows what an attacker reaches without valid attributes; it does not defend a session already under attacker control.

A compromised key access server is a trust anchor failure. A server that can unwrap keys can release them. Splitting keys across independent servers means a single compromise is insufficient, and does not remove the need to protect the servers.

Wrong attributes produce confidently wrong decisions. The decision point evaluates what it is told, so stale entitlements and mislabelled objects produce correct evaluations of incorrect inputs. TDF vs traditional file encryption sets out which failure modes each approach carries.

How Lattix implements decrypt-time enforcement

Lattix operates the policy decision point and policy enforcement point (PEP) described on this page. The PDP evaluates ABAC across subject, device, environment and geography, purpose of use, network posture, risk, and data-object attributes, and returns a signed, short-lived decision carrying allow or deny, the reasons, the policy version hash, and the object identifier. The PEP enforces at decrypt time, defaults are fail-closed, and revocation propagates to deny. Content identifiers and Merkle-tree lineage records make decision history queryable, and the deployment posture is identical across cloud, regional hub, tactical edge and air-gapped environments. The object format itself is described in What Is Trusted Data Format: A Technical Reference.

Frequently asked questions

How does TDF enforce policy when data is decrypted?

TDF wraps the data encryption key to a key access server rather than distributing it. Opening the object requires a rewrap request. The server authenticates the caller, unwraps the key, verifies that the policy carried in the manifest still matches its cryptographic binding, and asks a policy decision point whether the caller's attributes satisfy that policy. Key material is released only on allow.

How does TDF enable persistent access control?

Persistent access control follows from binding the policy to the object and withholding the key. A copy of the object carries its policy wherever it goes, and opening it requires a fresh authorization decision, so the originating organization keeps a decision point over data it no longer possesses. Control persists over ciphertext, not over plaintext an authorized user has already decrypted.

What is a rewrap request?

A rewrap request is the message a client sends to a key access server to open a TDF object. It carries the key access object from the manifest, the policy, the policy binding, and an ephemeral public key generated for that request. The server, if it authorizes the request, re-encrypts the data encryption key to that ephemeral public key so only the requesting client can use it.

What does a TDF access decision record?

A well-formed decision records the verdict, the reasons behind it, the hash of the policy version evaluated, and the identifier of the object concerned, signed by the issuing decision point and given a short lifetime. That combination allows a decision to be re-derived and defended later, which a bare allow or deny cannot support during an audit or an incident review.

Can access to a TDF file be revoked after it has been shared?

Revocation is performed by changing policy or attributes, not by reaching distributed copies. The next decrypt request is evaluated against the new state and denied, so circulating copies stay ciphertext. Plaintext that a previously authorized user already decrypted is outside the format's reach. Real revocation latency equals the time for attribute changes to reach the policy decision point.