Introduction

Concise Attribute-Bound Encapsulation (CABE) defines an envelope format and key management architecture for managing object-level encryption of information using Attribute-Based Access Control (ABAC) principles. CABE works by assigning a set of key-value metadata items known as attributes to messages, and automatically manages the generation of keys for each unique attribute set used within a CABE domain. Access to keys is gated according to their associated attribute sets and in relation to an ABAC policy. CABE therefore allows for highly flexible access control policy to be expressed and enforced using data encryption, facilitating multi-level data transfer, storage, and interchange in otherwise untrusted operating environments.

CABE is defined as a set of core specifications, namely:

An overall architecture specification (this document);
The CABE Baseline Envelope Structure (CBES) defining how messages are encapsulated securely into opaque envelopes and subsequently decapsulated back into intelligible messages.
The CABE Key Access Protocol (CKAP) defining communications between a CABE client and key server, and how keys are retrieved from key servers for use with the Baseline Envelope Structure.

CABE is further extended by additional specifications providing augmented functionality building on these core specifications.

Definitions

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY” and “OPTIONAL” in this document are to be interpreted as specified in BCP 14 when, and only when, they appear in all capitals, as shown here.

The following terms are defined:

Payload: The sequence of zero or more bytes constituting the plain-text body of a Message, which has application-specific meaning opaque to CABE.
Metadata: Information characterising the Payload of a Message other than the Payload itself, to include at least an Attribute Set and, potentially, other application-specific data items opaque to CABE.
Message: Refers to a Payload, associated Attribute Set and any other associated Metadata which may be used to construct an Envelope via Encapsulation, or which may be obtained from an Envelope via Decapsulation.
Envelope: The result of Encapsulating a Message using CABE, rendering it cryptographically secure and opaque to examination or modification.
Attribute: A key-value pair constituting an item of Metadata relating to some given Message, which may be used to qualify the circumstances in which access to a Message may be made.
Attribute Key: The key of a key-value pair in an Attribute, which is a textual, human-readable string of non-zero length and which matches the grammar given in the section “Attribute Sets”.
Attribute Value: A CBOR data item within the CBOR Basic Data Model as defined in RFC 8949.
Attribute Set: A unique set of Attributes in relation to a Message, Envelope, Key or Lease.
Message Set: The set of Messages with a given Attribute Set.
Envelope Set: The set of Envelopes with a given Attribute Set. (These last two definitions are largely conceptual, as the set of Messages or Envelopes with a given Attribute Set is infinite and not countable.)
Encapsulation: The process of producing an Envelope from a Message.
Decapsulation: The process of producing a Message from an Envelope.
Principal: A logical identity characterising an Agent, and which possesses a set of Claims for the purposes of determining what Messages/Envelopes it is permitted to Encapsulate/Decapsulate, as determined by a Key Server’s Policy.
Claims: A set of known facts about a Principal.
CKAP: The CABE Key Access Protocol (CKAP).
Agent: A piece of software which implements CABE, which Encapsulates Messages and/or Decapsulates Envelopes, and incorporates a Client which authenticates to and communicates with a Key Server as a Principal.
Client: The component of an Agent which implements CKAP, and which communicates with a Key Server.
CABE Domain: A CABE deployment comprising a single logical Key Service and one or more Clients.
Key Service: The logical service which handles requests by Clients for a CABE Domain to facilitate Encapsulation and Decapsulation. A Key Service is provided by one or more Key Servers which collectively provide the logical Key Service. The use of multiple Key Servers is intended to facilitate high availability.
Key Server: A server which is capable of handling requests by Clients made to a given Key Service to facilitate Encapsulation/Decapsulation, primarily by performing Key Resolution and tracking Leases, and which manages an arbitrarily large set of keys to facilitate this.
Key: A secret value used, directly or indirectly, to encapsulate/decapsulate Messages/Envelopes. Note that:
- A Key is either Derived or Non-Derived;
- A Key is either an Internal Key or an Access Key; and
  - Access Keys are further divided into
    - Captive (Access) Keys; and
    - Non-Captive (Access) Keys.
Key Mapping: The scheme by which a Key Service selects a Set Key in the context of a given Prograde Resolution request and associated Attribute Set.
Key Resolution: The operation of resolving an Attribute Set to a Set Key as requested by a Client. Key Resolution refers either in the form of Prograde Resolution or Retrograde Resolution.
Prograde Resolution: Key Resolution wherein a Client requests key information for a given Attribute Set, for the purposes of performing Encapsulation of a new Message, and receives key information in the form of a Lease.
Retrograde Resolution: Key Resolution wherein a Client quotes a Lease Reference for the purposes of obtaining a previously used Lease Key’s LKAI, for the purposes of performing Decapsulation of an existing Envelope.
Lease: A temporary object with a specific expiration time managed and tracked by a Key Service in response to a Prograde Resolution request.
Internal Key: A Key which is used internally by the Key Service to derive one or more Derived Keys but which is never disclosed to any Client.
Access Key: A Key which is not an Internal Key and which is available for Clients to use, either by being provided by the Key’s bit pattern (as in the case of a Non-Captive Key), or via Assisted Encapsulation/Decapsulation performed by the Key Service on behalf of a Client. In this version of the specification, the only defined kind of Access Key is a Lease Key.
Set Key: An Internal Key assigned to a given Envelope Set at a given point in time, which is used to derive Lease Keys.
Non-Derived Key: A Key which is directly derived from an entropy source and therefore must be stored by a Key Service if it is to be subsequently recalled.
Derived Key: A Key which is derived from another Key (which in turn may be a Non-Derived Key or a Derived Key), and which therefore does not need to be stored by a Key Service in order to be subsequently re-derived.
Non-Captive Key: An Access Key which a Key Service is willing to provide a copy of to a suitably authorized Client, so that it can encapsulate/decapsulate corresponding Messages/Envelopes without further interaction with the Key Service.
Captive Key: An Access Key which a Key Service does not disclose to any Client, but is willing to perform operations using on behalf of a Client to allow it to accomplish encapsulation/decapsulation of corresponding Messages/Envelopes.
Key Series: A chronological series of Keys all possessing the same associated Attribute Set. The Keys in a Key Series are totally ordered and each Key in a Key Series corresponds exactly to a single Key Epoch.
Key Epoch: A contiguous period of time used to manage the rollover of Keys for an arbitrarily large number of Key Series managed by a Key Service. Key Epochs succeed one another consecutively and no time passes between a Key Epoch and its successor.
Current Key: A key for a given Key Series which is non-retired and may be used by a Key Service to derive Lease Keys in response to a Prograde request.
Retired Key: A Key within a given Key Series which is not the Current Key.
Lease Key: A Derived Key generated from the Current Key for a Key Series and which is associated with, and unique to, a Lease.
Lease Key Access Information (LKAI): Information needed to make use of a Lease Key, whether it is a Captive Key (in which case it comprises the Lease Key Access Token (LKAT)) or Non-Captive Key (in which case it comprises the bit pattern of the Lease Key).
Lease Key Access Token (LKAT): An opaque byte string quoted to the Key Server to perform Assisted Encapsulation or Decapsulation using a Lease Key which is a Captive Key.
Key Access: The process in which a Client obtains (for a Non-Captive Key), or indirectly makes use of (for a Captive Key) a Lease Key, for the purposes of facilitating access to some contiguous temporal subset of an Envelope Set. Key Access is distinct from, and occurs subsequently to, Key Resolution.
Lease Reference: An opaque byte string produced by a Key Service which it can use to subsequently recover a given Lease Key and corresponding LKAI. Lease References MUST be globally and permanently unique.
Policy: An arbitrary rule or logic used by a Key Service to determine which Principals may access which Envelope Sets, and which Key Epochs within a given Envelope Set, based on its Claims. The nature of a Policy is not defined in this specification, and is left as an implementation detail. A Policy is a deterministic, pure function over a Principal’s Claims, an Attribute Set, and a requested operation, returning either ALLOW or DENY.
Access: Generically, Access to an Envelope Set or Key refers to the authorization to perform Key Resolution for a given Envelope Set, and thereby perform encapsulation and decapsulation for it.
Rollover: The process by which a new Key Epoch is created for a Key Series, with a new assigned Set Key, which then becomes the Current Key for that Key Series.
Rollover Period: The (approximate) period for which Clients are liable to encapsulate Messages using Lease Keys derived from non-Current Set Keys for a given Key Series.
Synchronous Rollover: Rollover which occurs predictably and on a chronological schedule.
Asynchronous Rollover: Rollover which can occur unpredictably at any time in response to arbitrary system events, such as the addition of newly authorized Principals, the revocation of existing Principals, or at operator request.
CSPRNG: A cryptographically secure pseudo-random number generator.

Attribute Sets

Definition

An Attribute Set is a unique unordered set of Attributes. Each Attribute is a key-value metadata item which characterises a Message, Envelope, Key or Lease.

The key of an Attribute is a textual string meeting the following requirements:

It comprises at least one character ("" is not a valid key);
The UTF-8 representation of the string does not exceed 255 bytes; and
It satisfies the ABNF (RFC 5234) grammar shown below.

ALNUM         = ALPHA / DIGIT
ATTRIBUTE_KEY = ALPHA *ALNUM *('-' 1*ALNUM)

The value of an Attribute is a data item within the CBOR Basic Data Model as defined in RFC 8949.

Duplicate keys MUST NOT be present in an Attribute Set. An implementation which encounters an Attribute Set with duplicate keys MUST refuse to process it.

Serialization

The serialization of an Attribute Set MUST be the serialization of a CBOR Map data item using Deterministically Encoded CBOR as defined in RFC 8949. The CBOR encoding MUST satisfy the core deterministic encoding requirements as defined in section 4.2.1 of RFC 8949.

Equality

Two Attribute Sets are the same if their serializations are the same byte string.

Architectural Overview

CABE defines a means of Encapsulating messages into envelopes, attaching attribute-based metadata and encrypting them in the process, and subsequently Decapsulating envelopes into messages, decrypting them, obtaining their contents and associated attribute-based metadata in the process. CABE Agents are responsible for Encapsulation and Decapsulation and perform these operations in coordination with a Key Service, which they communicate with using the CKAP protocol.

Overall Process

CABE is based around symmetric cryptography and avoids direct reliance on asymmetric primitives.

The key aspects of CABE are:

Characterisation. An Encapsulating Agent characterises the Message to be secured by assigning it a set of Attributes which characterise it for the purposes of access control policy. For example, a Message might be characterised by sensitivity level (confidential, secret, top secret, etc.), country, compartment or codename, or along any other axis. CABE is agnostic to the specific system of classification and metadata used.
Key mapping. The Attribute Set for a Message is mapped to a (symmetric) Key. This function is performed by the Key Service, which is responsible for maintaining a repository of Keys corresponding to each unique Attribute Set used within the CABE Domain.
Key resolution. The CABE Key Service automatically maintains the Key Mapping needed according to the Attribute Sets used within the scope of the CABE Domain. When a CABE Client needs to Encapsulate a Message to create an encrypted CABE Envelope, it asks the Key Service to perform Key Resolution, in which the Key Service examines the Attribute Set in use and determines the correct Key to use within its existing, automatically maintained Key Mapping. Having determined the correct Key, a CABE Agent proceeds to Key Access.
Key access. CABE Clients request access to the Keys managed by a Key Server so that they can encapsulate Messages into Envelopes and vice versa. Whereas key mapping is the process of choosing the correct Key for a Message, key access is the process of using the chosen Key to encapsulate a Message, or decapsulate an Envelope.

“Use of” a Key does not necessarily imply its bit pattern is provided to the CABE Client. Both “in-memory” (non-captive) and “out-of-memory” (captive, i.e., RPC-based) use of Keys “at a distance” is envisaged. The need to transmit large messages to a Key Service is avoided as only an ephemeral Content Encryption Key (CEK) is provided to the Key Service (in the out-of-memory case) for encapsulation/decapsulation.

Key Access represents the key policy enforcement point of CABE, as the Key Server can control access according to Attribute-Based Access Control (ABAC) principles based on the identity of the Client and the metadata of an Envelope to be decapsulated.

Key Mapping

The Key Service maintains a Key Mapping for every needed Key Series. A Key Series corresponds exactly to a unique Attribute Set and represents a succession of Keys used to secure Envelopes which possess that Attribute Set. A Key Service maintains at least one Key Series for every Attribute Set in use, though a Key Service MAY choose to maintain multiple Key Series for a given Attribute Set.

A Key Series is essentially a temporal sequence of Keys which are used to encrypt Messages and decrypt Envelopes for a given Attribute Set. At any given point in time, a Key Series has a Current Key which is used to encapsulate any new Messages. Previous keys in a Key Series are retained indefinitely so that older Envelopes can be decapsulated. Periodically, the Current Key in a Key Series is replaced with a new Key, which thereby becomes the Current Key.

The Rollover of a Key Series serves several functions. A Key Series maps uniquely and exactly to a unique Attribute Set. The set of Principals permitted to Decapsulate Envelopes for a unique Attribute Set may expand and contract over time, as policy or the authorization granted to a specific Principal changes. Therefore, Rollover of a Key Series is frequently necessary to facilitate the following invariants:

No access after revocation. A revoked Principal cannot decapsulate Envelopes created after the time of revocation.
No access before authorization. A newly authorized Principal cannot decapsulate Envelopes created prior to the time of authorization (where such a restriction is desired).

For keys which are allowed to be exported from the Key Service for in-memory use (Non-Captive Keys), any contraction or expansion in the set of authorized Principals must cause the rollover of a Key Series to enforce the above invariants. For Captive Keys, which never leave the Key Service and are held captive by it, this is optional, as the Key Service can enforce the updated policy. Non-Captive Keys therefore avoid the need for a Client to continually query the Key Service and is therefore more performant, at the cost of being less secure.

A Key Service thus conceptually manages the set of all Key Series (essentially, the set of all possible Attribute Sets), each of which represents a temporal succession of actual Keys:

Each time period for a given Key in a Key Series is called a Key Epoch.

A Key may exist but this does not necessarily mean it needs to be stored persistently. Derived Keys are Keys which are derived deterministically from other Keys in a hierarchy. On the other hand, actual generation of new Keys based on new entropy, which are not derived from other Keys (Non-Derived Keys), is often desirable to facilitate recovery from any leakage of any key material. These considerations can be balanced to achieve a reasonable balance between key storage requirements and security. Further discussion of possible key derivation architectures can be found in the CKAP specification.

Both temporal and spatial partitioning of access are desirable properties. Temporal partitioning refers to enlargement or contraction of the authorized Principals over time for a given Attribute Set as shown above. Spatial partitioning is better achieved by simply using a suitably designed metadata scheme to construct suitable Attribute Sets.

An example of a circumstance in which an implementation might choose to maintain multiple Key Series for a given Attribute Set is to facilitate high availability.

A single Key Server within a CABE Domain is not required to select the same Key Series, Set Key or Key Epoch when processing a Prograde request at a given point in time for a given Attribute Set as another Key Server within the same CABE Domain.

However, once a Lease has been created and returned, all Key Servers within a Key Service MUST be able to fulfill any future Retrograde request for that Lease’s Lease Reference. Therefore, a Key Server MUST NOT return a Lease in response to a Prograde request unless and until it has guaranteed that all other Key Servers comprising part of the Key Service (if any) will be capable of handling a Retrograde request made immediately or at any future point in time which quotes the returned Lease Reference; as such, a Key Server unable to guarantee this in a particular circumstance MUST NOT return a Lease and MUST instead refuse to process the Prograde request.

Key Resolution

The Key Service automatically maintains the Key Mapping as needed. A Client then, as needed, requests a Key from the Key Service. This process is known as Key Resolution.

There are two circumstances in which Key Resolution occurs:

Prograde resolution. When a Client wants to Encapsulate a Message, and desires a Lease Key corresponding to the Message’s Attribute Set;
Retrograde resolution. When a Client wants to Decapsulate an Envelope, and desires the Key which was used to create the Envelope (which may not be a Current Key).

Prograde Resolution

In Prograde Resolution, the Client sends the relevant Attribute Set to the Key Server and requests a Lease Key to use for the purposes of constructing an encrypted Envelope. The Key Service determines whether the Principal should be allowed to access the given Key Series according to its configured Policy, and if allowed, creates a Lease and returns information about it.

A Lease provides the following information:

Lease Key Access Information (LKAI), which is information needed for Key Access to the Lease Key, namely:
- In the case of a Non-Captive Key, this is the memory image of the Lease Key itself;
- In the case of a Captive Key, this is an opaque reference token (the Lease Key Access Token (LKAT)) which can be used to make subsequent calls to the Key Service to perform assisted Encapsulation or Decapsulation using the Lease Key.
A Lease Reference, which is an opaque byte string which a Client can quote to a Key Service to facilitate subsequent Key Access to the same Lease Key, by performing Retrograde Key Resolution.
The point in time at which the Lease expires.

Caching. The purpose of this design is to facilitate caching. Once Prograde Resolution has been performed, a given Client does not need to perform it again for every single Message it wishes to Encapsulate for the same Attribute Set, up until the expiry time of the Lease.

Temporal imprecision of key selection. However, this mechanism is not exact, nor is it intended to be. The lease expiry time can only account for Synchronous Rollover of a Key Series. Factors such as clock skew, or events which cause Asynchronous Rollover, can cause the Current Key for a Key Series to change suddenly, in which case a Client might continue to encapsulate Messages with an out of date Lease Key (which is derived from the Current Key) for some period of time (the Rollover Period). Further discussion of the issues around this can be found in the CKAP specification.

Retrograde Resolution

Retrograde Resolution is performed when decapsulating Envelopes into Messages. Unlike Prograde Resolution, a Key was already chosen when the Envelope was created, which is specifically requested by the Client, as it is the only Key which can be used to decapsulate the Envelope.

Each Envelope’s header contains a Lease Reference which is an opaque byte string uniquely identifying a previously issued Lease Key to a Key Service. The Client quotes this Lease Reference to the Key Service, which verifies the Principal’s access according to its Policy before providing the result of the resolution process. The Client can then proceed to Key Access in the same way as for Prograde Resolution.

All Key Servers within a Key Service MUST be able to process Lease References issued by any Key Server within that Key Service. A logical consequence of this is that a Key Server MUST NOT issue a Lease unless and until it has ensured that the contained Lease Reference will be processable by any and all Key Servers within the CABE Domain as part of a Retrograde operation occurring at the point in time that the Lease is issued and at any subsequent point in time.

Due to the temporal imprecision noted in the previous section, the Key chosen to derive a Lease Key used to create a given Envelope may not have been the Current Key at the time the Envelope was created. Thus, Lease Keys are identified by a unique Lease Reference rather than being inferred from an Envelope timestamp.

Key Access

In the case of a Non-Captive Key, Key Access is straightforward as it is provided directly in the Key Service’s response. The means by which the Lease Key is used to create Envelopes is discussed in detail in the CBES specification.

In the case of a Captive Key, direct access to the Lease Key’s bit pattern is not available. Instead, a Client makes Assisted Encapsulation/Decapsulation calls to the Key Service.

Since these merely perform key wrap operations on Content Encryption Keys (CEKs) used to encrypt a specific Message, the bandwidth consumed by these calls is a function of the number of Messages encrypted, not the size of the Messages encrypted.

An advantage of the use of Captive Keys is that there is no Rollover Period in which an updated Policy is not yet fully effective, as a new Policy can begin being enforced immediately by the Key Service.

On the other hand, the need for interaction with the Key Service for each encapsulation or decapsulation operation means that performance is bounded by the round-trip time between the Client and the Key Service, though this can be ameliorated by pipelining.

Architectural Invariants

The following invariants are worth noting explicitly:

Every Key Series is associated with exactly one Attribute Set. One Attribute Set MAY be associated with more than one Key Series.
A Key Series is an ordered sequence of non-overlapping Key Epochs.
Each Key Epoch has exactly one Set Key.
A given Envelope is bound to exactly one Lease Key and Lease Reference.
A Lease Reference identifies exactly one Lease Key within a CABE Domain.
A Lease Key is derived from a specific Set Key in a specific Key Epoch.
Resolution of a Lease Reference via a Retrograde operation is independent of the Key Server through which the Lease Reference was obtained.

CABE Architecture Specification