Sharing with partners when the label must travel with the data

Inside an organization, access to data is enforced by the systems that hold it. Once a report, a dataset or an image is sent to a partner, those controls stay behind. Data-centric protection tries to keep the rules with the data itself. It works, within limits that are worth understanding before an exchange is designed around it.

This article is for people who plan or run information exchange between organizations: coalition and allied partners, agencies sharing with each other, health systems working with researchers, and firms sharing with suppliers or regulators.

When the file leaves the perimeter

Traditional sharing relies on trust in the receiving system: the file is encrypted in transit, and from then on the partner’s own controls apply. That raises four recurring problems. The partner may use a different marking scheme, so the sender’s label means little to the receiver’s systems. Forwarding and copying are invisible to the sender. Access cannot be withdrawn once the file is decrypted at the destination. And there is no shared record of who actually opened the content.

Protecting the object, not the network

Data-centric protection encrypts each object and binds to it a policy and a label. The keys are not sent with the file. Instead, a key access service checks the policy each time someone tries to open the object and releases the key only if that person, at that moment, satisfies it. Because the decision happens at open time, access can be changed or withdrawn after the file has been shared, and each decision can be logged.

The Trusted Data Format, developed in the open as OpenTDF [3], is one such design: an encrypted payload, a manifest carrying the policy and the label, and key access servers that make the authorization decision before releasing a key [4]. The Zero Trust Data Format (ZTDF), introduced in the Combined Communications-Electronics Board’s ACP-240 standard for allied partners, builds on the same specification [1, 3]. Commercial sensitivity-label systems, such as those built into office suites, apply a similar idea within their own ecosystems.

Labels partners can read

Encryption without a shared understanding of labels only moves the problem. NATO’s standards specify how a confidentiality label is expressed so that systems from different nations can read it (STANAG 4774) and how a label is bound to the object it describes so that it cannot be swapped (STANAG 4778) [2]. Inside a single government, schemes such as US CUI, UK Government Security Classifications or the Traffic Light Protocol play the same role between organizations.

In practice, every exchange needs a mapping between the sender’s scheme and the receiver’s. The mapping should be agreed in writing, tested with real labels before data flows, and conservative where terms do not line up: a label that cannot be mapped should stop the exchange rather than be dropped.

Planning an exchange

• Who runs the key service? Each partner may operate its own, or one party may host it for the exchange. The answer decides who can withdraw access and who sees the access log.
• What does withdrawal mean? Revoking a key prevents future opens. It cannot recall content already decrypted, printed or copied. Agree what “withdrawn” requires of the partner, such as confirmed destruction of copies.
• Disconnected use. If recipients must open content without a connection, the policy has to allow cached keys for a period, which weakens withdrawal. Decide the period explicitly.
• Metadata exposure. Labels, policies and file names travel in the clear in some designs. A label can itself be sensitive; keep descriptive metadata to what the receiver needs.
• Large and streaming data. Imagery, video and big datasets need formats and key handling that work in segments.
• Access records. Decide whether the partner’s access logs come back to the sender, in what form and how quickly.

What object protection does not record

Object protection answers “who may open this?” It does not answer “who decided to send it, to whom, for what purpose, and under whose authority?”, which is what auditors, originators and courts usually ask. Nor does it stop someone with legitimate access from re-typing the content or photographing a screen.

A complete exchange process therefore pairs object protection with three things: a recorded release decision, naming the approver, the recipient, the purpose and, where required, the originator’s consent; a tamper-evident record of each hand-off, ideally signed and chained so that gaps are visible; and, for the most sensitive material, numbered copies per recipient with marks that allow a leaked copy to be traced to its source.

A practical checklist

1. Agree the label mapping between schemes, in writing, and test it with real labels.
2. Decide which content needs object protection, from which marking level upward.
3. Agree who operates the key service, who can withdraw access, and what withdrawal obliges the partner to do.
4. Set the policy for offline access and its maximum period.
5. Record every release decision with its approver, recipient and purpose, separately from the encryption.
6. Arrange for access records to come back, and check them.
7. Rehearse a withdrawal and a correction before you need one.

Sources

1. Combined Communications-Electronics Board. ACP-240 Edition A, which introduces the Zero Trust Data Format (ZTDF).
2. NATO. ADatP-4774, Confidentiality Metadata Label Syntax (STANAG 4774), and ADatP-4778, Metadata Binding Mechanism (STANAG 4778), as listed in the NATO Interoperability Standards and Profiles, Volume 3. nato.int
3. OpenTDF. OpenTDF specification, which describes ZTDF as building on it. github.com/opentdf/spec
4. OpenTDF. Access control concepts. github.com/opentdf/spec