Several teams can keep encrypted reports in a shared object store. Within an established CABE Domain that retains the required key material, a later policy decision can admit another team to an existing report without creating another archive copy or re-encrypting it.
Concise Attribute-Bound Encapsulation
Attribute-based access control
for encrypted data
CABE defines a compact encrypted Envelope format and a protocol for obtaining keys under an attribute based access policy. Applications can exchange protected data through brokers, relays and storage services without giving those services the keys to read it.
Why CABE?
Keeping information separate does not need to mean operating a separate network, message broker or archive for every audience. Where each sharing arrangement needs its own infrastructure, organisations pay to provision and operate duplicate services. Bringing another participant into an exchange can become another integration project.
CABE is intended to make more of that infrastructure reusable. Producers encrypt information before handing it to shared services. Message Attributes and access Policy determine who may obtain the keys needed to read it. The aim is to carry protected information over shared or unclassified transport, and retain it in common storage, without giving every participant or infrastructure operator access to its contents.
The information does not need to be a document. A position report, chat message, command update or sensor reading can be protected as an individual object. CABE’s concise Envelope and reusable Leases support these small, frequent exchanges. With a valid cached Lease and a Non-Captive Key, a producer can encrypt further Messages with the same Attribute Set locally, without a new Key Service request for every Message.
Sharing can also change after information is stored. Within an established CABE Domain which retains the required key material, a later Policy decision can admit a new reader to an existing report without copying it into another archive or re-encrypting it for that reader.
A common Envelope and key access protocol give independently developed applications a common way to exchange protected information. In a coalition, that can support contributions to a common operating picture while preserving different permissions for the applications using those contributions. Those applications still need compatible Payload formats and agreed Attribute meanings.
A shared broker
with two consumers
Suppose a sensor publishes an encrypted observation through a broker used by an analysis application and a maintenance application. Both receive the same Envelope. The Key Service applies its Policy to their requests for the decryption key.
CABE Domain
Key Service (khaled)Authentication and claims mapping → Cedar policy evaluation → key access decision.
- Producer
Assigns Attributes, obtains a Lease and encrypts the observation.
- Shared broker
Delivers the same ciphertext to both consumers. It has no decryption key.
- Consumers request key access
Analysis application — key access permitted
Maintenance application — key access refused
The decision inside the Key Service
How access is decided
Message Attributes
{
"project": "survey",
"product": "observation",
"release-to": ["ExampleOrg"]
}The producer assigns this Attribute Set to the Message.
Established caller Claims
Analysis application
- Project
- survey
- Organisation
- ExampleOrg
- Function
- analysis
Maintenance application
- Project
- survey
- Organisation
- ExampleOrg
- Function
- maintenance
Authentication and claims mapping establish these facts about each Principal. The application’s name grants no permission by itself.
Configured access rule
For requests to obtain the decryption key, require the same project, a permitted organisation and an approved function for the product.
- analysis
- observation
- maintenance
- equipment-status
| Policy check | Analysis application | Maintenance application |
|---|---|---|
| Project matches | ✓ survey | ✓ survey |
| Organisation is permitted | ✓ ExampleOrg | ✓ ExampleOrg |
| Function permits this product | ✓ Observations permitted | × Equipment status only |
| Key request | ALLOW | DENY |
The broker delivers the same ciphertext to both consumers. The Key Service evaluates their requests separately.
Where Cedar fits
Policy integrationCABE does not prescribe a policy language. The reference key server khaled supports pluggable policy languages; the Cedar policy language is supported out of the box. The server uses the policy decision to control key access; authentication and claims mapping establish the facts on which it depends.
Payload encryption
Envelope operationsWith a Non-Captive Key, the Client encrypts and decrypts the Payload locally using the Lease Key. With a Captive Key, the Client asks the Key Service to wrap or unwrap a content encryption key (CEK), then handles the Payload locally using that CEK. The Key Service does not need the Payload for these operations, but remains trusted for the key material it controls.
The Payload format is the application’s choice.
CABE uses CBOR and COSE for its Envelope. The Payload is an opaque sequence of bytes: applications can protect their existing data formats, including encoded voice and video, without converting them to CBOR. An application may also choose CBOR for its own structured data when compact encoding is useful.
Try the policy simulator
Work through the full CABE example, change access rules and inspect the Envelope. The hosted simulator uses Cedar for policy evaluation.
Experiment with access policy
Leases, message size
and federation
Leases
A Client with a valid cached Lease and a Non-Captive Lease Key can encrypt further Messages with the same Attribute Set locally. It requests a new Lease when the cached one expires or is invalidated. Rollover and cache invalidation affect when the Client switches to new key material.
Key access and LeasesMessage size
CABE is a concise encapsulation scheme which can scale to arbitrarily large or arbitrarily small messages.
Envelope structureFederation
A Federated Lease Package lets a receiving CABE Domain’s Key Service recover key material for the shared Lease without a live request to the Origin Domain.
Federation and preparationApplications
A shared event service may carry equipment readings, observations and application results for several consumers. Access rules can distinguish these products without making the broker a trusted reader of their payloads.
An analysis application may need selected products from a satellite provider or coalition information service rather than access to its entire collection. The provider’s release rules determine which consumers may obtain which products. For a live feed, an application can protect finite video segments before they reach a shared relay or cache.
An air operations centre can distribute an Air Tasking Order and subsequent changes through shared messaging and storage services. Participating planning and unit applications obtain access to the tasking information they are authorised to receive, while relays and storage operators do not need its decryption keys. The same protection model can carry a complete order or separately prepared tasking messages and amendments.
Voice and video can be protected as they are produced. Applications encapsulate encoded audio blocks, video frames or segments in CABE Envelopes and send them through shared relays. Authorised receivers obtain the key material needed to recover the media; the relays do not need those keys. Reusable Leases allow successive chunks to be protected without a Key Service round trip for every chunk.
A partner’s publishing application can send an encrypted drone observation to an authorised SOF application for situational awareness. Relays carry the Envelope without needing the decryption key.
An ally’s mobile ad hoc network may provide an available path between applications. Protected application data can use that path without giving the radios and relays its decryption keys.
An Origin Domain can send protected reports through an intermittent link or store-and-forward path. A prepared Target Domain uses the accompanying Federated Lease Package and its local Key Service to provide authorised access. The recipient does not need a live connection to the Origin Domain when it reads the report.
An authorised processing application can read restricted observations and decide which result may be released. It protects that result as a new Message with its own Attributes and key arrangement, so another audience can read the result without being given access to the inputs.
A coordinator passes tasks and protected input references to separately authenticated processing services. Each worker requests access to the information it needs. Arranging the work does not require the coordinator to hold every worker’s input keys.
An analyst asks a planning application to examine imagery. The application passes part of the task to an image-processing service, which requests access to protected observations. An integration can supply verified requester and task information to the key access decision, allowing policy to consider whose request the service is carrying out as well as the service’s own identity.
An operator publishes fault records separately from operational observations through a shared collection service. A supplier’s diagnostic application can obtain keys for the fault records while access to operational information is refused. Selective sharing does not require duplicating the whole collection system.
Software
khaled
The reference key server, including Cedar policy evaluation and plugins for authentication, claims mapping and key storage.
Server configurationcabe-go
The Go client library. Its cabecap interface handles encapsulation, decapsulation and Lease caching.
cabetool
Command-line tooling for client identity, encryption and decryption, included with cabe-go.
Where CABE sits
Producers use a CABE client library to encrypt Messages before publishing them. Consumers use it to obtain the required key material and decrypt received Envelopes. The broker, relay or object store carries those Envelopes.
Operators configure how the Key Service authenticates applications, which facts it establishes about each caller, and the rules that grant access. Those facts might include the caller’s organisation, project and approved function. In khaled, authentication, claims mapping, policy evaluation and key storage are separate plugins.
CABE components
- Client library
- Serialises Attributes, constructs Envelopes and caches Leases.
- Key Service
- Maps Attribute Sets to key material and resolves Lease References.
- Envelope
- Carries protected Attributes and a Lease Reference alongside the encrypted Payload.
Application responsibilities
- Publishing application
- Chooses the information to publish and assigns its Attributes.
- Consuming application
- Interprets recovered data and controls its use and release.
- Transport
- Routes, stores and retries delivery according to the application’s needs.
Specifications
CABE-ARCHArchitectureAttributes, Key Series, Leases and access. CBESEnvelope structureMessage encoding and cryptographic operations. CKAPKey access protocolClient and Key Service interaction. CFARFederation and resilienceLease packages for prepared receiving Domains. ACP240Attribute mappingA defined subset of classification metadata. All specification drafts Security model
CABE lets brokers, relays and storage services carry encrypted Envelopes without entrusting them with plaintext. The Key Service, identity and claims authorities, and participants holding usable key material or plaintext remain trusted for the information and authority they control.
What if a broker, relay or storage service is compromised?
CBES uses authenticated encryption: an intermediary without the relevant key cannot read the Payload or make a changed ciphertext or protected header verify under the intended key. Protected headers, including the Attribute Set and Lease Reference, remain visible. Unprotected headers do not carry the same integrity guarantee; CFAR explicitly permits intermediaries to change the attached federation-package list. An intermediary can drop, delay, reorder or replay Envelopes and observe their size, timing and routing. CABE encryption alone does not guarantee delivery, freshness, replay prevention or resistance to traffic analysis. Envelope headers
Who is trusted to make the access decision?
The Key Service applies its configured Policy to the Principal’s Claims, the Message’s Attribute Set and the requested operation. The Key Server authenticates the Client; the deployment’s trusted identity and claims authorities establish the caller information. The producer assigns Message Attributes, so their authority depends on the producer and any validation the deployment requires. Key management, authentication and authorisation remain trusted components. Keeping the Payload out of the Key Service’s normal data path does not make it unable to decrypt. Compromise affects the keys and authority the compromised component can use. Key resolution
Where are keys held, and when is policy checked?
A Non-Captive Lease Key is disclosed to an authorised Client for local use. A valid cached Lease avoids repeated resolution for encryption; local use of retained key material does not trigger another policy check. A Captive Lease Key stays at the Key Service, which can enforce current Policy when wrapping or unwrapping a content encryption key (CEK). The Client handles the Payload using that CEK and may retain it or the plaintext. New Key Resolution requests are checked against Policy. Lease expiry and Rollover govern key selection for subsequent encryption; they do not erase retained keys or guarantee immediate revocation. Old ciphertext remains decryptable with its key, and Envelopes sharing usable key material can share an access boundary. Key access and rollover
What changes in the trust model when domains federate?
CFAR lets a receiving CABE Domain’s Key Service recover Non-Captive Lease Key material for shared Leases without contacting the Origin Domain. That service is therefore trusted with the means to decrypt the associated Envelopes and with access decisions for its Clients. This is a different role from merely transporting ciphertext. Once usable material is shared, the Origin Domain cannot be assumed to continuously control its use. Federation draft
Does successful verification identify the producer?
Successful verification under a symmetric key establishes integrity against an intermediary without that key. It does not distinguish participants able to use the same key. An Attribute naming a source, a protected Origin Domain header, or encryption to a recipient is not, by itself, authenticated evidence of a particular producer. Applications requiring producer-specific attribution need additional authenticated evidence binding that producer to the Message. Envelope protection