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

From: Laurence Lundblade <[email-masked]>
Date: Wed, 23 Jun 2021 12:53:34 -0700

The definition of Attesting Environment seems more implied than explicit.
Does an Attesting Environment always have key material?
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.

If yes is the answer to the above, then the layered attestation diagram is not right because it has the output of one Attesting Environment going into another Attesting Environment.

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.

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 <https://mailarchive.ietf.org/arch/msg/rats/NsGYYPmqo4q8sT6mBWyTWdgwQvg/>, 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

---

From: Thomas Fossati <[email-masked]>
Date: Thu, 24 Jun 2021 13:40:46 +0100

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

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

> 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 i…

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!

> 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

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 25 Jun 2021 13:06:14 -0700

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 <[email-masked]> wrote:
> 
> <[email-masked] <mailto:[email-masked]>> wrote:
>> 
> [1] draft https://github.com/ietf-rats-wg/architecture/issues/344 <https://github.com/ietf-rats-wg/architecture/issues/344>
> 
> [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!
> 
> _______________________________________________
> RATS mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>

---

From: "Smith, Ned" <[email-masked]>
Date: Fri, 25 Jun 2021 22:03:38 +0000

See inline. NMS>

From: RATS <[email-masked]> on behalf of Laurence Lundblade <[email-masked]>
Date: Friday, June 25, 2021 at 1:06 PM
To: Thomas Fossati <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Rats] Definition of an Attesting Environment (and layered attestation)

NMS> I agree these statements reflect intended objectives of an attesting env. What wording leads the reader to believe otherwise?

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.

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

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.

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?

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

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.

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’?

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.

LL

On Jun 24, 2021, at 5:40 AM, Thomas Fossati <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, Jun 23, 2021 at 8:53 PM Laurence Lundblade
<[email-masked]<mailto:[email-masked]>> wrote:

cheers!

LL

--
Thomas

_______________________________________________
RATS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rats

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 28 Jun 2021 12:38:46 -0700

My main interest here it to get my head around the concepts and security of all this, so I took a few days and here’s a write up of what I think it going on. How does this align with what is intended?

LL

First Layer Execution Environment
This is the first execution environment to come into existence on the device.

An example of this is the BIOS ROM. It exists only for a short time at the beginning of system start up. It is very secure because it is small, well cared for and because no less-trusted code is running at this time.

It has two main duties:

1. Securely start up the second layer
There are several ways this can be accomplished:
Read the code for the second layer from some I/o or such into RAM and verify a signature on the code using a public key signing scheme.
Read the code for the second layer from some I/o or such, hash/measure it and compare it to reference values it knows.
Simply jump to a location in some ROM that it known to contain trusted code for the second layer.
Other schemes, some of which are combinations of the above, are also possible.
This set up of the next execution environment is technically not a remote attestation function. There is no remote Verifier. This staged boot design is in common use in the industry even when the device is not doing remote attestation.

(Personally, I’m not sure if this is considered a local attestation in the TCG world. Maybe it is? Also, maybe some of the measurements used in this first part are used in the second part?)

2. Produce Attestation Evidence about the second layer

This first layer has an Attestation Environment whose Attestation Target is the second layer execution environment. After the second-layer code is loaded, the first-layer Attestation Environment measures it and makes the measurement into Attestation Evidence, most likely by signing it.

This Attestation Evidence is stored some place that the second execution environment can read it after the first layer execution environment ceases to exist.

Second Layer Execution Environment
For simplicity of example, this second environment is assumed to be able to receive a nonce and send Attestation Evidence to the Verifier. In practice there may be one or more simple layer like the first layer between the first and the layer that has network capability.

This has 4 duties:

1. Securely start up the third layer.
 It can use any of the same methods that were listed for the first, but doesn’t have to use the same one that the first used.

2. Receive the nonce
Nonce’s are necessary to avoid a replay

3. Produce Attestation Evidence about the third layer
This second layer has an Attestation Environment whose Attestation Target is the third layer. It measures the third layer and puts the measurements into Attestation Evidence.

This second Attestation Environment can include the Attestation Evidence produced by the first layer as nested Attestation Evidence, cryptographically binding it to the nonce. This is generally a good idea to avoid replay of the first Attestation Evidence. (The first Attestation Environment can’t bind to a nonce because it doesn’t have network connectivity to be able to receive a nonce).

4. Convey Attestation Evidence to the Verifier
The second-layer Attestation Evidence is sent to the Verifier via the network.

If the first layer Attestation Evidence was not nested and cryptographically bound, then it is sent separately to the Verifier.

Verifier
The Verifier receives either one or two Attestation Evidences depending on whether the first was nested in the second or not.

The Verifier trusts the first one based on an Endorsement it received from the manufacturer or such. The trust of the first has to be this way — based on some out-of-band information received by the Verifier.

The Verifier has also received Reference Values which it compares with the measurements about the second layer that were in the first layer’s Attestation Evidence. If successfully compared, the Verifier knows that the second layer is configured correctly.

There are several options for the Verifier to come to trust the second Attestation Environment:

1) In addition to the Endorsement for the first, it also receives an Endorsement for the second. 

2) It bases its trust on the comparison of the measurements that are in the first-layer Attestation Evidence. (Note that it also is likely to need to receive a verification key from somewhere to be able to verify the signature on the second-layer Attestation Evidence). 

3) The Endorsement of the first also gives implicit trust to the second. This is possible and acceptable because the first layer does securely start up the second layer. The Endorser that produces the Endorsement would have to indicate somehow that it vouches for both.

4) The Endorsement of the first includes a boolean value that indicates whether the second can be trusted. (This is not practical here because of the staged boot, but is possible in other architectures).

5) Possibly others, possibly a combination of the above.

Once trust in the second-layer Attestation Environment has been established, the Attestation Evidence for it can be verified and the Verifier can compare the measurements in it to the Reference Values it has for the third layer and come to know if the third layer is configured correctly or not.

> On Jun 25, 2021, at 3:03 PM, Smith, Ned <[email-masked]> wrote:
> 
> See inline. NMS>
>  
> From: RATS <[email-masked] <mailto:[email-masked]>> on behalf of Laurence Lundblade <[email-masked] <mailto:[email-masked]>>
> To: Thomas Fossati <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>> On Jun 24, 2021, at 5:40 AM, Thomas Fossati <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: "Panwei (William)" <[email-masked]>
Date: Tue, 29 Jun 2021 09:10:59 +0000

Hi Laurence,

I can share an understanding about the Attesting Environment and Layered Attestation, maybe it’s helpful.

I was also confused about how to identify the Attesting Environment in the Layered Attestation, i.e., is the ROM Attesting Environment? If it is, but it has no cryptographic capability of signing/encrypting the Claims, the Claims usually signed by the TPM.
After re-read the section of “Two Types of Environments of an Attester” in the architecture draft, I find out that the ROM itself isn’t the Attesting Environment, the combination of ROM and TPM is the Attesting Environment.

   Claims are collected from Target Environments. ...  Attesting Environments
   then format the Claims appropriately, and typically use key material
   and cryptographic functions, such as signing or cipher algorithms, to
   generate Evidence.

   An arbitrary execution environment may not, by default, be capable of
   Claims collection for a given Target Environment.  Execution
   environments that are designed specifically to be capable of Claims
   collection are referred to in this document as Attesting
   Environments.  For example, a TPM doesn't actively collect Claims
   itself, it instead requires another component to feed various values
   to the TPM.  Thus, an Attesting Environment in such a case would be
   the combination of the TPM together with whatever component is
   feeding it the measurements.

PS:
There is a minor error in the section split of “Two Types of Environments of an Attester”, the current draft is:
   See Section 8 for further discussion of the conceptual messages shown
   in Figure 1. ## Two Types of Environments of an Attester
I think there is a line break missing here in the markdown file to make it a split section.

Regards & Thanks!
Wei Pan

From: RATS [mailto:[email-masked]] On Behalf Of Laurence Lundblade
Sent: Tuesday, June 29, 2021 3:39 AM
To: Smith, Ned <[email-masked]>
Cc: [email-masked]; Thomas Fossati <[email-masked]>
Subject: Re: [Rats] Definition of an Attesting Environment (and layered attestation)

LL

It has two main duties:

  *   Read the code for the second layer from some I/o or such into RAM and verify a signature on the code using a public key signing scheme.
  *   Read the code for the second layer from some I/o or such, hash/measure it and compare it to reference values it knows.
  *   Simply jump to a location in some ROM that it known to contain trusted code for the second layer.
  *   Other schemes, some of which are combinations of the above, are also possible.
This set up of the next execution environment is technically not a remote attestation function. There is no remote Verifier. This staged boot design is in common use in the industry even when the device is not doing remote attestation.

This has 4 duties:

2. Receive the nonce

Verifier

On Jun 25, 2021, at 3:03 PM, Smith, Ned <[email-masked]<mailto:[email-masked]>> wrote:

See inline. NMS>

From: RATS <[email-masked]<mailto:[email-masked]>> on behalf of Laurence Lundblade <[email-masked]<mailto:[email-masked]>>
Date: Friday, June 25, 2021 at 1:06 PM
To: Thomas Fossati <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Rats] Definition of an Attesting Environment (and layered attestation)

Lead Attester

Root of Trust

LL

cheers!

LL

--
Thomas

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 29 Jun 2021 11:01:25 -0700

Ahhh, the TPM is where the measurements are stored by the first layer so that the second layer can pick them up as I describe in my previous message. The TPM is also doing the signing of the attestation evidence. So, when there’s a TPM in use like this the actual ROM isn’t doing that much, just taking the measurements and putting them in the TPM registers.

Thanks for that pointing that out.

That said, I don’t think layered attestation requires a TPM. It’s perfectly reasonable for there to be SW crypto and such in the ROM code, or what ever it is that implements the first layer. The concept of layered attestation should be general, more like what I described in my previous message.

So, obviously, the description-by-example of layered attestation doesn’t succeed in conveying what it is for me personally. I suspect others that don’t assume TCG/TPM architecture would have similar trouble.

I believe the TPM/TCG architecture came out of the PC/Windows world where end users get to install whatever OS they want. It has a lot of facilities to deal with that.

The mobile phone world was never like that. The OEM always controls the SW. Thus it never needed an architecture like that of the TPM/TCG world. Lots of IoT devices don’t need TPMs or TCG architecture. Often, it is simpler without TPMs and the TCG architecture.

I kind of worry that a lot of people think that Attestation == TPM, that you must have a TPM to do attestation. That is of course not true.

Some TEE-based attestation systems are more capable than TPM-based systems. TEE’s can measure the HLOS every hour if need be rather than just once at start up.

RATs of course has to work for both systems that use TPMs and those that don’t.

LL

> On Jun 29, 2021, at 2:10 AM, Panwei (William) <[email-masked]> wrote:
> 
> Hi Laurence,
>  
> On Jun 25, 2021, at 3:03 PM, Smith, Ned <[email-masked] <mailto:[email-masked]>> wrote:
>  
> See inline. NMS>
>