[Rats] EAT claims for composite and layered attestation

[Laurence Lundblade <[e-mail]>]

To try to get clarity on architecture for devices with multiple attesting environments, I’ve started thinking about what an EAT would look like for such.


I think composite attestation is straight forward.

In composite attestation, the attesting environments are trusted independently. The verifier will get a separate endorsement for each attesting environment. There’s no claim in one set of attestation evidence that is involved in establishing another, so no special claims are needed.

What is needed is the ability to embed the attestation evidence from one attesting environment in attestation evidence from another. We have that now in EAT with nested tokens in the submodule section.


The distinguishing characteristic of layered attestation is that the trust in attesting environments is NOT independent. One attesting environment plays a role in the verifier coming to trust another.

There is clearly has to be root attesting environment, trust in which is established by the usual way, most likely by an endorsement from the manufacturer.

From there, it seems there are two paths.

In the first one, the root attesting environment can collect evidence about a layered attesting environment, put it in an EAT and send it to the verifier. It is the *verifier* that evaluates and decides on the trust in the layered attesting environment. Probably the evidence about the layered attesting environment appears in EAT as a submodule. The verifier will look at the evidence and decide if the layered attesting environment is trustworthy. It may look at measurements, debug state for the attesting environment. 

To complete, that submodule probably needs to contain the public key of the layered attesting environment. It probably needs to be clearly labeled as the verification key for attestations from that layered attesting environment, so we need to define a new claim for this.


In the second one, the *root attesting environment* is the one that decides whether the layered environment is trustworthy. It can do this however it sees fit. It might just trust it because they are in the same HW running from the same ROM. It might do some staged secure boot. It might do run time integrity checks. 

It then tells the verifier that the layered attesting environment is trustworthy. This basically amounts to the root attesting environment sending an endorsement or the equivalent of an endorsement to the verifier. The root attesting environment might construct the endorsement on the fly or it might have been programmed in a the factory.

Probably this endorsement should be in attestation evidence from the root attesting environment so that the verifier knows that the root attesting environment did the checks it needed to do. That means we need a claim that holds an endorsement like those based on X.509 or to consider some set of attestation evidence that includes a public key to be considered and endorsement.

(I’ve worded this in terms of two layers, the root and a layered attesting environment. I don’t mean to exclude multiple layers, though there’s just one root).


I don’t really know what was intended by layered attestation in the architecture draft. It seems halfway the first path and halfway the second path. Seems just fine to have both paths, but they need to be described distinctly.  I filed an issue <https://github.com/ietf-rats-wg/architecture/issues/293> and a PR <https://github.com/ietf-rats-wg/architecture/pull/294> to try to sort this out in the architecture document. Hopefully, this email helps clarify those.

I’m interested in what the consensus is here before I go off and try to define the EAT claims I’ve mentioned above.

LL