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

[Thomas Fossati <[e-mail]>]

Hi Laurence, just a couple of points (see below).

On Wed, Jun 23, 2021 at 8:53 PM Laurence Lundblade
<[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

> 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

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