Re: [Rats] EAT claims for composite and layered attestation

[Laurence Lundblade <[e-mail]>]

I’ve made a PR for EAT claims for layered attestation. https://github.com/ietf-rats-wg/eat/pull/105

LL


> On Apr 5, 2021, at 1:29 PM, Smith, Ned <[e-mail]> wrote:
> 
> See inline (NMS>)
>  
> From: RATS <[e-mail] <mailto:[e-mail]>> on behalf of Laurence Lundblade <[e-mail] <mailto:[e-mail]>>
> Date: Friday, April 2, 2021 at 11:51 AM
> To: "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
> Subject: [Rats] EAT claims for composite and layered attestation
>  
> 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 
>                                                                                                                                                                                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> NMS> It would likely not be viewed by Verifier as an Endorsement unless it was signed by a trusted Endorser (aka mfg). Since, the root attesting env isn’t a traditional CA (that can be physically audited), the Verifier isn’t likely to have TA policy for it. It would likely still be considered a ‘device’. The TCG DICE Layering Architecture specificationhttps://trustedcomputinggroup.org/wp-content/uploads/DICE-Layering-Architecture-r19_pub.pdf <https://trustedcomputinggroup.org/wp-content/uploads/DICE-Layering-Architecture-r19_pub.pdf> describes this sort of thing as an ‘embedded CA’ because it issues the certificate for the next layer environment. It is also an Attesting Environment because it might also include Evidence in the certificate.
>  
> This sort of root attesting environment wouldn’t be called an Endorser since it is also being called an Attesting Environment. The mfg CA that signs the root attesting env key is the likely line of demarcation; i.e., the mfg CA (and the cert chain to the root CA) is the Endorser, while the root attesting environment cert + any additional embedded CA issued certs + the ‘target environment’ claims would be the “Attester” Evidence.  (Assuming Certs contain evidence extensions).
>  
> Note:  The https://trustedcomputinggroup.org/wp-content/uploads/TCG_DICE_Attestation_Architecture_r22_02dec2020.pdf <https://trustedcomputinggroup.org/wp-content/uploads/TCG_DICE_Attestation_Architecture_r22_02dec2020.pdf> defines an OID for UCCS evidence as a certificate extension. This might be used to include EAT claims as evidence in an X.509 certificate that is issued by an attesting environment in a layering pattern.
> <SMN
>  
> 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
>  
>  
>  
>  
>