Re: [Rats] -12 text on layered attestation (was Re: EAT claims for composite and layered attestation)

[Laurence Lundblade <[e-mail]>]

A little more…

Say a device has two attesting environments. Are they layered or composite?

By my theory of layered attestation, they are composite only if there are endorsements for both. It is layered when one attesting supplies claims that is the basis of trust in the other.

In this theory, it doesn’t matter how the two attesting environments are implemented. The subsystem that one runs in could be involved with secured/trusted boot/start of the other (staged boot and such), but that is not what determines if it is layered or not. What matters is what manifest in RATS protocols.

Perhaps in another theory the implementation does matter. It does matter that one attesting environment is involved with the other. I don’t like this theory so much because:
1) There are many different secured / trusted boot/start architectures and it is better that RATS not try to characterize them or set criteria for them.
2) The implementation details don’t really manifest unless they manifest in a RATS protocol. 

LL


> On Apr 26, 2021, at 12:07 PM, Laurence Lundblade <[e-mail]> wrote:
> 
> Here’s another attempt at describing my view of layered attestation. Hopefully this is better than the last. :-)
> 
> To make this description simpler I assume simple public key crypto where an Attesting Environment has a secret signing key and the Verifier has the corresponding public verification key.
> 
> A RATS Attesting Environment: 
> - It generates claims that are sent to a RATS Verifier. 
> - It has a key for signing the RATS claims it sends.
> - The RATS Verifier has a public key to verify the signature.
> - The RATS Verifier trusts the public key because… …discussion below
> 
> (If all the above aren’t true, then it isn’t a RATS Attesting Environment. Verification of layers in a staged boot are similar, but are not RATS!)
> 
> A Layer-0 Attesting Environment is where the Verifier trusts because it got the verification key from an Endorser, device manufacturer, CA or such.
> 
> Most of the time when we talk about an Attesting Environment, it is Layer-0.  When there is just one Attesting Environment, it is Layer-0. In composite attestation, there are multiple Attesting Environments, but all are Layer-0.
> 
> A Layer-1 Attesting Environment is one that is trusted by the Verifier because of Evidence provided by a Layer-0 Attesting Environment. The Verifier does not get anything from an Endorser or manufacturer or CA for Layer-1 Attesting Environments. It is trusted based on the evidence from the Layer-0 Attesting Environment below it.
> 
> One can say that the Layer-1 Attesting Environment is the Target Environment of the Layer-0 below it.
> 
> The Evidence a Layer-0 Attesting Environment provides about a Layer-1 can be in one of two forms, Boolean or Detailed.
> 
> When the Layer-0 Attesting Environment makes the decision to trust Layer-1 entirely on it’s own, then it sends Boolean Evidence. This is just a simple “true” telling the Verifier that Layer-1 can be trusted. Layer-0 can decide on this trust in many ways, simple or complex. It may make and evaluate complex measurements (all done locally), or it may just be because they are in the same HW. There are many architectures for this and their descriptions are all beyond the scope of RATS. Note that the local evaluation of measurements of Layer-1 here is not RATS Attestation because it isn’t remote and there is no RATS Verifier.
> 
> When the Layer-0 Attesting environment leaves the trust decision to the Verifier, then it sends Detailed Evidence. These claims about the Layer-1 Attesting Environment can be large and complex. For example it may take a bunch of measurements and send them to the Verifier. Note that these measurements are RATS Attestation because they are remote and there is a RATS Verifier.
> 
> This, of course extends to a Layer-1 Attesting Environment providing Evidence about a Layer-2 Attesting Environment and so on.
> 
> Here’s a diagram:
> 
> 
> <PastedGraphic-2.png>
> 
> 
> I think maybe the text in -12 architecture covers this, but also maybe disallows the Verifier from making the decision about Level-1 because it says "the BIOS conducts the most important and defining feature of layered attestation, which is that the successfully measured bootloader now becomes…”. This seems to say that Level-0 MUST always evaluate Level-1 locally.  
> 
> I don’t think that Layer-0 has to measure Layer-1. There are other ways Level-0 can trust completely Level-1 and the descriptions of how it can do so are out of scope for RATS.
> 
> I think the defining  characteristic of layered attestation is that the Verifier relies on Layer-0 to come to trust Layer-1 rather than on an endorsement.
> 
> I think that the Verifier can be the one making the decision about trust in Layer-1 based on Detailed Evidence. It isn’t solely up to Layer-0 as the -12 draft seems to say.
> 
> My PR <https://github.com/ietf-rats-wg/architecture/pull/294/files> was just for Detailed Evidence about Layer-1 from Layer-0. The -12 text seems to be more about the local evaluation of Layer-1 by Layer-0 and Boolean Evidence. So I can understand why it was rejected. I wasn’t sure what was desired and wasn’t clear about Detailed vs Boolean at the time I wrote it. 
> 
> I really can’t find a way to modify the -12 architecture text on layered attestation to line up with my view here. It would be a rewrite for me.  This is not important enough to me to personally relative to other stuff, so I’m not going try to contribute text. Perhaps I’m being lame and lazy.
> 
> LL
> 
> 
> 
>> On Apr 10, 2021, at 12:50 PM, Laurence Lundblade <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> I’ve made a PR for EAT claims for layered attestation. https://github.com/ietf-rats-wg/eat/pull/105 <https://github.com/ietf-rats-wg/eat/pull/105>
>> 
>> LL
>> 
>> 
>>> On Apr 5, 2021, at 1:29 PM, Smith, Ned <[e-mail] <mailto:[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
>>>  
>>>  
>>>  
>>>  
>>>  
>> 
>> _______________________________________________
>> RATS mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/rats
> 
> _______________________________________________
> RATS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats