Representing multiple attesters, of the same or different types

[andrew-draper]

CoRIM needs a way to represent an expected state which includes results from different attesters.

This in turn means that the Accepted Claims Set abstraction needs a way to model evidence and endorsements relating to different target environments.

As an example, please consider this example system, which contains two identical sub-components, each of which contains two Target Environments.

graph TD
    Verifier["Verifier"]

    subgraph Compound["Compound system"]

    subgraph DICE1["DICE Component #1"]
        TE1z["SPDM TEs"]
        TE1y["DICE L1 TE (SPDM AE)"]
        TE1x["DICE L0 TE (L1 AE)"]
    end
    TE1z ==> TE1y
    TE1y ==> TE1x

    subgraph DICE2["DICE Component #2"]
        TE2x["DICE L0 TE (L1 AE)"]
        TE2y["DICE L1 TE (SPDM AE)"]
        TE2z["SPDM TEs"]
    end
    TE2z ==> TE2y
    TE2y ==> TE2x

    end

    style Compound fill:#CCC,stroke:#CCC

    Verifier -...-> TE1y
    Verifier -...-> TE2y

Loading

Though components #1 and #2 are the same, they may be running different firmware. For example, component #1 might be running the 1.0 firmware, while component #2 has been updated to run the 2.0 firmware. If both firmware versions are acceptable to the verifier owner and relying party then the attestation result should be positive.

To provide hierarchy, I expect that the expected state for this system will be described by multiple CoRIM files. One CoRIM file describes the expected state for component #1, another for component #2 and a third describes the state of the system containing both components.

What information is in these CoRIM files?

I expect that the component CoRIM files are class RIMs, issued by the firmware author and either trusted or re-issued by the verifier owner and/or relying party. These RIMs apply to any device of the appropriate type.

The system RIM may contain instance measurements, for example, in addition to specifying the type of component #1 it may specify which instance of that component (by including the serial number of the component, a cryptographic key or similar instance measurement). This RIM might have been generated by scanning the state of the system and converting that to CoRIM format.

What does the ACS which matches against these RIMs look like?

I think the system RIM adds a constraint to the ACS format: Measurements from all sub-components must be in the same ACS so they can match against a single RIM.

The existence of two components of the same type adds a second constraint: It must be possible to keep all evidence and endorsements relating to sub-component #1 separate from those relating to sub-component #2.

What is a possible way to implement this?

My thoughts on how this could be implemented start by solving the problem of keeping ACS entries separate from each other.

As currently specified in the draft, a DICE/SPDM verifier provides evidence whose environment-map only contains the class field. The protocol also provides a public key known as the hardware identity, whose value does not change during normal device state changes.

If we change the draft to say that for DICE/SPDM generated evidence, the environment-map/instance field SHOULD be set to the hardware identity for the SPDM AE, then evidence loaded into the ACS for component #1 and component #2 will be separate. This means that both can be stored into the ACS without conflict.

For the component RIMs to match an ACS which contains an instance field described like this, we would need to change the matching rules for conditional endorsements slightly. The change is that if none of the reference value environment-maps within a conditional endorsement include an instance field, then the first environment-map will match against an ACS entry with the same class field as the reference value and any (or no) instance field. The second environment-map will match against an ACS entry with the same class field and the same instance field as the first ACS entry.

For conditional-endorsement-triple and conditional-endorsement-series-triple there is only one environment-map, so this simplifies to "If the environment-map does not contain an instance field then it will match against any environment-map with the same class field". The endorsement is added to the same environment-map.

Issue #172 is asking whether there are any problems with this approach.

Of course, if there are multiple identical components, each configured in the same way, then the triple will match each of them and add an endorsement to each. This is what I would expect to happen.

For the conditional endorsement triple with multiple environment-maps, it is a bit more complex. In particular, if any of the endorsements is added to a different environment-map from the reference values then the CoRIM needs to describe whether or not to copy the instance value from the reference value or use a new one.

I think that problem can be easily solved as part of defining the new conditional endorsement triple.

Is there another way to solve the same problems?

[nedmsmith]

As currently specified in the draft, a DICE/SPDM verifier provides evidence whose environment-map only contains the class field.

Note: the current corim spec defines environment-map to mean: "An environment is named after a class, instance or group identifier (or a combination thereof)." The above text seems to be misaligned. The verifier should not assume the environment-map only contains the class field.

[nedmsmith]

I think the system RIM adds a constraint to the ACS format: Measurements from all sub-components must be in the same ACS so they can match against a single RIM.

My reading of section 2 (CoRIM) doesn't place constraints on the internal representation that a verifier might use. I don't think it should either. The RIM is simply a signed envelope. It can refer to other RIMs (i.e., corim-locator-map) but doesn't include rich semantics. Given multiple RIMs may be needed for a solution, there is no way to represent rich semantics involving multiple RIMs using the enveloping context. Rich semantics need to be represented deeper.

so they can match against a single RIM

Matching ACS statements against a "RIM" is ambiguous as the RIM contents determines whether matching is meaningful.

Measurements from all sub-components must be in the same ACS

Statements in the ACS rely on the Verifier-Attester connection context to determine what is in the ACS. A verifier could have multiple connections and therefore multiple ACSs. If a verifier has multiple connections to the same attester device, the verifier may not know it is the same device (and may not care). For example, VM-guests on the same device need not be combined into a common ACS. Tenant isolation requirements might forbid it as well.
That doesn't mean it is impossible for a verifier to learn about a larger device context through endorsements. But the overlap means the respective ACSs have common attributes (claims) but not that the ACSs are merged.
If a use case requires merging of multiple attesters, the right approach is to use a lead attester.

[nedmsmith]

The change is that if none of the reference value environment-maps within a conditional endorsement

The structure of a conditional endorsement is: a condition followed by an endorsed value claimset. If the condition describes a state that exists in the ACS, then add the claimset to the ACS.

The structure of a reference value is: a claimset that is asserted by a RVP iff the same claimset is also asserted by an Attester.

Possibly there are use cases for asserting a claimset by a supplier iff the same claimset is also asserted by another supplier. If that use case exists, it is different from the above two use cases even though it may reuse some of the same primitives.

[andrew-draper]

Closed by #193