Composition musings

Composition Primitives Status Quo

A view of the basic relationships that the CoMID information model can currently express:

• A target environment has one or more reference or endorsed values;
• An attesting environment has one or more attestation verification keys (Henk: cryptographic attestation keys that evidence is signed with).

erDiagram
    TE ||--o{ RV : "reference values"
    TE ||--o{ EV : "endorsed values"
    AE ||--o{ VK : "attestation verification keys"

Loading

Gap 1: Attesting - Target Environments Linkage

At the moment, we don't seem to have a way to clearly describe the attester's scope in terms of the composing attesting and target environments, i.e., the fact that a given target environment is associated with one or more target environments:

erDiagram
    AE ||--|{ TE : "target environments"

Loading

Gap 2: Domains Don't Allow Recursive Composition

Another gap in the information model is that we can't express composition of attesters in a natural (recursive) way using the domain triple. (Henk: The reason why "bundling a collection of related environments and their measurements" is required is way too under-specified atm, imo. Is there another reason than the 'system boundaries' of components that are composed? Also, as always, examples.)

Proposals

Note The following assumes that there is only one attesting environment per attester.

Closing Gap 1

Providing a way to explicitly tell the verifier which attesting environment and target environments an attester is made of using a new "attester triple" that says: AE is an attesting environment for the following TEs target environments.

attester = {
    AE: environment-map
    TEs: [ + environment-map ]
}

Closing Gap 2

We want a domain to represent a logical subset of attesting environments that are part of a system or device.

For example, separate attesting environments can be grouped into a domain to model a server with multiple independent RTMs (e.g., CPU, GPU, NIC). (Henk: multiple RTMs, because each component - that is represented by a domain - potentially comes with its own rtm? this goes complex really fast, but maybe an appropriate example. Domain and Module have to disambiguated, I think)

We also want the domain composition primitive to be recursive in order to allow a hierarchy to be bottom-up assembled from smaller parts.

Given the stated assumption (i.e., 1:1 relationship between attesters and attesting environments), we can describe a domain as a collection of attesting environments.

erDiagram
    domain ||--|{ AE : "attesting environments"

Loading

In CDDL it'd look like this:

domain = [
    AEs: [ + environment-map ]
    ? name: environment-map
]

Two things worth noting:

1. The name is optional, in fact in the simplest case (where no further composition is expected) a domain can remain anonymous;
2. The name is given as an environment-map that represents the composite attester. A direct consequence is that the composite attester can be treated as a normal environment that can be used as the subject of new CoMID reference and endorsed values triples in multi-stage appraisals.

Full Picture

The composition primitive described above would allow us to model things like this:

flowchart TD
    Domain1["sub-Attesters Domain"]
    subgraph Attester1["NIC"]
        AE1["AE"]
        TEx["TE A"]
        TEy["TE B"]
        AE1 --> TEx
        AE1 --> TEy
    end
    subgraph Attester2["GPU"]
        AE2["AE"]
        TE2["TE"]
        AE2 --> TE2
    end
    Domain1 --> Attester1
    Domain1 --> Attester2

    Domain0["Lead Attester Domain"]
    subgraph Attester0["CPU"]
        AE0["AE"]
        TE0["TE"]
        AE0 --> TE0
    end
    Domain0 --> Attester0
    Domain0 --> Domain1

Loading

in a fairly natural way.