Re: [Rats] Definition of an Attesting Environment (and layered attestation)

[Laurence Lundblade <[e-mail]>]

Catching up on this...

> On Jun 25, 2021, at 3:03 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, June 25, 2021 at 1:06 PM
> To: Thomas Fossati <[e-mail] <mailto:[e-mail]>>
> Cc: "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
> Subject: Re: [Rats] Definition of an Attesting Environment (and layered attestation)
>  
> Attesting Environment definition
> After some thought, I think this should be the definition of an Attesting Environment:
> - It collects the claims that make up Attestation Evidence
> - Its output is Attestation Evidence and Attestation Evidence always comes from an Attesting Environment
> - It is not responsible for transmission of Attestation Evidence
> - It is responsible for the authenticity and integrity of the claims all the way to the Verifier
> NMS> I agree these statements reflect intended objectives of an attesting env. What wording leads the reader to believe otherwise?

For me it was lack of a sharp written definition, the text that says attesters securely set up the next layer and comments from Thomas.

Glad there is general agreement.


> I think the last point is critical because we don’t have remote attestation without authenticity and integrity. It’s kind of the point of RATs. If the Attestation Environment doesn’t take responsibility for this, then we have to add a new block into the architecture that does. There is no set way for how it does this, so it can use signing, TLS, MAC and other. It just has to do it.
>  
> One way Attestation Evidence can be transmitted is via a second Attesting Environment that has connectivity to the Verifier. Usually the second Attesting Environment will bind the first Attestation Evidence in with claims it collects and secure the bound up claims and evidence to the Verifier. In EAT this is a nested token submodule.
> NMS> Do you mean cryptographic blinding? Architecture didn’t imply that IMO.

Yes, I mean cryptographic binding. I can see that it can be either way. However isn’t cryptographic binding to the nonce really important and the only way to get that is to  cryptographically bind the lower layers to upper layers until you get to the layer with the nonce.

It seems critical to point this out at least as a security consideration. Seems like a huge replay attack window without it.

 
> “ROM” in layered attestation
> Usually ROM is just some read-only memory, but in the definition of layered attestation I believe it refers to an execution environment that exits for a few milliseconds during startup. It has a CPU, some RAM and access to some key material (probably in fuses, not ROM). It hosts a short-lived Attestation Environment that takes some measurements and signs them to produce the “ROM’s Attestation Evidence” which is then saved in RAM or such to be picked up by a subsequence and distinct Attestation Environment that will transmit to the Verifier.
> NMS> The layering concept is being described (not defined?) in the context of an example. There was discussion about whether the architecture wanted to give a definitive definition followed by an example. Consensus was that this was unnecessary. Use of terms like ‘ROM’ and ‘boot loader’ are merely exemplary.
>  
> That is all fine from an architecture view, but it is pretty hard to understand that from the text unless you are a TCG/DICE person. I figured it out reading one of the DICE documents. It is far from the usual use of the word ROM. Lots of IoT devices that do attestation will have a ROM, but not this type of ROM. Seems like the layered attestation text needs expanding to avoid this confusion.
>  
> The terms, “ROM”, “read-only BIOS”, and “BIOS stored in read-only memory” should be unified so there is just one term for short-lived execution environment.
> NMS> I believe these terms are exemplary and apply in the context in which they’re used.

Example or not, may work for TCG people with a TCG understanding of ROM/BIOS, but it seems misleading for others and the Wikipedia definition of ROM. 


>  Attesting Environment don’t ensure integrity
> There is a sentence in layered attestation that goes “The first Attesting Environment… has to ensure integrity of the boot loader”.
>  
> Yes, the “ROM” does need to ensure integrity of the boot loader in this architecture, but I don’t think it's the Attestation Environment that is doing it. It’s another part of the  ROM that’s doing it. I would call that functionality staged boot and don’t think it has much to do with attestation.
> NMS> The term ‘attesting environment’ is normative while ‘ROM’ is exemplary. The statement above seems to blend terminology between something that might read like normative from exemplary text. E.g., ‘attesting environments’ seems more normative language while ‘the boot loader’ seems more exemplary. Given the goal wasn’t to write a normative definition of layered device it seems to live up to its expectation. Does the WG want to see normative definition of common device patterns like layered device and composite device?

The statement that the normatively defined “Attesting Environment” “has to ensure the integrity of the boot loader” is the biggest point of confusion in all this for me. Personally I don’t think it is correct.


> Layered Attestation is a fairly special case
> I’d like to suggest reversing section 3.1 and 3.2. The Composite Device section describes a much more general and more broadly applicable architecture. 
> NMS> This may depend on your definition of ‘special’.

While this style of booting and attesting may have more numerous implementations, there are more specific things about it.


>  Lead Attester
> The definition of lead attester for a composition device seems useful. I think it should be applied to layered attestation (and the order of composite and layered sections reversed). Is an initial Attesting Environment the same as a lead attester?
> NMS> I don’t think so. The ‘initial’ AE refers to the root of trust (that may not be sophisticated enough to connect to a remote entity). The ‘bootloader’ AE seems closer to a ‘lead’ attester IMHO.

Yes, makes sense.


> Root of Trust
> The layered attestation section uses the term “root of trust” a lot. The rest of the document doesn’t use it much anymore.
> NMS> All of the cases where “Attester” is used implies there is a root of trust underlying it. The layered device example is the most logical diagram to talk about it.
>  
> It’s not clear whether the user in layered attestation refers to a root certificate, or the primordially trusted device hardware/software. 
> NMS> What text refers to ‘the user’?

Sorry, my typo. I meant “uses”.

My understanding is that “root or trust” sometimes refers to a pinned root certificate in an X.509 certification chain, OR, to some primordially trusted device hardware/software. In some systems there may be both and even they relate to each other, but they are still not the same. I think the architecture document should be clear about which use is referred to.


>  It also says there might be more than one root of trust, which is confusing.
> NMS> It says the ‘Attester includes at least one root-of-trust’. In multi-CPU systems the TEE may execute on any CPU / core which makes each core a root-of-trust for the TEE. The TEE has multiple roots of trust unless it is pinned to a single CPU.

Right, but we’re talking about one instance of layered attestation here.


Also, would appreciate comments and/or confirmation on my previously long description of layered attestation. I’m hoping for common understanding here. I don’t know if we have it or not.

LL