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

[Laurence Lundblade <[e-mail]>]

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

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.


“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.

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.


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.


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. 


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?


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.

It’s not clear whether the user in layered attestation refers to a root certificate, or the primordially trusted device hardware/software. 

It also says there might be more than one root of trust, which is confusing.


Different than my proposals
Both what’s in the layered attestation section now and what I’ve proposed as layered attestation seem useful and valid things to do, but they’re really different. Part of the reason I wrote up what I did was to try to get my head around what layered attestation is. That’s what came into my head. We should probably use different terms for the two different things.

LL



> On Jun 24, 2021, at 5:40 AM, Thomas Fossati <[e-mail]> wrote:
> 
> Hi Laurence, just a couple of points (see below).
> 
> On Wed, Jun 23, 2021 at 8:53 PM Laurence Lundblade
> <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> The definition of Attesting Environment seems more implied than explicit.
>> 
>> Does an Attesting Environment always have key material?
> 
> I don't think so.  An Attesting Environment (AE) could create unsigned
> evidence and rely on a "trusted communication path" with some other AE
> (e.g., one at a lower layer in the boot chain) that has the signing
> capability.  (I don't know if this changes the picture you are trying
> to make though.)
> 
>> Does an Attesting Environment always create Attestation Evidence (or vice versa, does Attestation Evidence always come from an Attesting Environment)?
>> Does the output of an Attesting Environment always go to a Verifier?
>> 
>> I think the answer to all of the above is yes. I think it is yes because this is *remote* attestation. The Verifier is always remote in relation to the Attester.
>> 
>> the layered attestation diagram is not right because it has the output of one Attesting Environment going into another Attesting Environment.
> 
> I agree with you that the figures in the architecture document might
> become slightly surprising when you try to combine them together.  See
> [1].
> 
> [1] draft https://github.com/ietf-rats-wg/architecture/issues/344 <https://github.com/ietf-rats-wg/architecture/issues/344>
> 
>> My thought is that the ROM is a Target Environment from which some claims originate, not an Attesting Environment in the RATS sense. I think it is fine that it works as described, but I don’t see it as an Attesting Environment. I don’t think the ROM has key material it uses to sign Attestation Evidence.
> 
> In some cases it doesn't, in others (notably DICE [2]) it does.
> 
> [2] https://trustedcomputinggroup.org/wp-content/uploads/Hardware-Requirements-for-Device-Identifier-Composition-Engine-r78_For-Publication.pdf <https://trustedcomputinggroup.org/wp-content/uploads/Hardware-Requirements-for-Device-Identifier-Composition-Engine-r78_For-Publication.pdf>
> 
> cheers!
> 
>> To go further here, how do subsystems in a device boot up and trust each other? I think there’s number of ways this can happen. One of them is what is described in the layered attestation section, but this is particularly complex and interesting SoC / device that has tens of very different subsystems of very different natures with different CPUs and CPU types. For example a mobile phone has a GPU, a modem, a security processor / TEE, a main CPU, a Secure Element, an audio DSP and… It’s far more complex than what is described in the layered attestation section.
>> 
>> Sometimes two subsystems trust each other just because they are on the same silicon die or because they are soldered on to the same PCB. Or, they can trust each other because they were booted out of the same ROM. It can also be because of staged boot as described in layered attestation. They can trust each other because some main system like the TEE booted each of them.
>> 
>> In a mobile phone, there’s only one RAM part that is used by all the subsystems. For each subsystem to have integrity the MMU’s and SMMU’s have to be set up correctly and play a part in how subsystems trust each other.
>> 
>> So I kind of don’t see the point of the current section of layered attestation in the RATS architecture draft. It is too simplistic to cover complex devices.
>> 
>> It also seems a bit of an overreach to try to detail how al the different subsystems on a device can or should trust each other. It would be complex, hard and take a year or two to do.
>> 
>> Also, in previous emails, I have suggested that layered attestation might be something quite different. It is more of an alternative to endorsements for establishing trust in an attesters.
>> 
>> LL
> 
> -- 
> Thomas
> 
> _______________________________________________
> RATS mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>