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

From: Laurence Lundblade <[email-masked]>
Date: Sun, 11 Jul 2021 11:36:31 -0700

Catching up on this...

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

---

From: "Smith, Ned" <[email-masked]>
Date: Tue, 13 Jul 2021 23:14:10 +0000

NMS> Arch doesn’t assert there are multiple “Attesters” but multiple “Attesting Environments”.  I don’t know which text you’re referring to. Can you provide a quote?

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.
NMS>  There are lots of possible ways to integrate nonces with layering. I don’t think it was the intent to bias a particular approach. It is important that ‘measureing the next environment before the next environment is started’ (last paragraph section 3.1) is done securely (i.e., cryptographically bound to the environment). I think the other sections make this expectation clear.  See pg 11  “Attesting Environments then format the Claims appropriately, and typically use key material and cryptographic functions, such as signing or cipher algorithms, to generate Evidence.”

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.
NMS> I agree ROM alone doesn’t adequately describe all the properties of a RoT environment. However, there isn’t a commonly accepted term that isn’t incumbered with vendor specific or implementation specific context. This isn’t a “TCG-ism” TCG has other terminology. The best I can suggest is “Root of Trust”, which is already used by the architecture draft.

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.
NMS>  I think the text “the read-only BIOS in this example,  has to ensure the integrity of the bootloader” is wrong since the example no longer has a “read-only BIOS” component. It should say “ROM” to be consistent. If ROM is changed to RoT then it would be changed along with all other occurances.

Root of Trust

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.
NMS> The arch draft defines root of trust in [1] and describes basic properties of a RoT in [2]. I couldn’t find any reference to a pinned certificate as being a root of trust. That usage might exist outside of this ID, but it seems to be using it consistently within the ID.
[1]“Typically, solutions start with a specific component (called a root of trust) that is intended to provide trustworthy device identity and protected storage for measurements.”
[2]“ To assess the security provided by a particular appraisal policy, it is important to understand the strength of the root of trust, e.g., whether it is mutable software, or firmware that is read-only after boot, or immutable hardware/ROM.”

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.
NMS> The text I’m referring to is in the section for “Two Types of Environments” which isn’t a concept that is specific to layered device, composite device or other more complex configuration. The language is correct in inferring there can be more than one target or attesting environments. It would be impossible to describe these more complex configurations if there could only be one of each type of environment.

Based on this exchange, I think your understanding of the layered device example is correct. There isn’t a formal ‘definition’ of ‘layered attestation’ IMO. But the example and words describing the example seem adequate to me. Nevertheless, the paragraph in [3] does a pretty good job as a formal definition as it doesn’t use any terms that are specific to the provided example.
[3] “In layered attestation, a root of trust is the initial Attesting Environment.  Claims can be collected from or about each layer.  The corresponding Claims can be structured in a nested fashion that reflects the nesting of the Attester's layers.  Normally, Claims are not self-asserted, rather a previous layer acts as the Attesting Environment for the next layer.  Claims about a root of trust typically are asserted by an Endorser.”

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 13 Jul 2021 21:56:02 -0700

Thanks for the comments, Ned. Helps close the loop.

> On Jul 13, 2021, at 4:14 PM, Smith, Ned <[email-masked]> wrote:
> 

The thing that resolves this sentence "The first Attesting Environment… has to ensure integrity of the boot loader” is making explicit that the first execution environment (the ROM/BIOS/…) has two jobs:
   - Securely start up the following environment, the boot loader (which it can do in many different ways)
   - Host the Attesting Environment that measures the following environment, the boot loader

It would help me (and maybe others) understand layered attestation if the text made this clear.

With the sentence as is, I wondered if there was a RATS Verifier on the device or not. The definition of Attesting Environment is something that produces Evidence and Evidence has to be checked by a Verifier… so maybe the intention is that there is a Verifier and that is the means by which the integrity is ensured. It is through this email thread that I am clear that is not the intent.

LL

---

From: "Smith, Ned" <[email-masked]>
Date: Thu, 15 Jul 2021 17:55:43 +0000

The Arch draft captures two duties of an Attesting Env fairly clearly (1- collect Claims, 2- create Evidence). In a layering context the Attesting Env has another duty (3- pass execution thread to the Target Env).

#3 is probably also true for composite device as well, though in composite device the Attesting Env retains a thread of control.

Does the list believe these points should be in the arch draft or are they reasonably inferred?

Thx,
Ned

From: Laurence Lundblade <[email-masked]>
Date: Tuesday, July 13, 2021 at 9:56 PM
To: "Smith, Ned" <[email-masked]>
Cc: Thomas Fossati <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Rats] Definition of an Attesting Environment (and layered attestation)

On Jul 13, 2021, at 4:14 PM, Smith, Ned <[email-masked]<mailto:[email-masked]>> wrote:

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 16 Jul 2021 11:24:33 -0700

> On Jul 15, 2021, at 10:55 AM, Smith, Ned <[email-masked]> wrote:
> 

Hi Ned,

I don’t think #3 should be part of RATS.

- It is not necessary in composite devices
- Many devices using composite attestation will not do it

Here’s an example of a mobile phone. It has three Attesting Environments:
- A TrustZone-based TEE that is the lead Attester
- The HLOS, say Android
- A Secure Element soldered to the PCB

The Secure Element boots fully on its own using SW from the Secure Element vendor. The HW and SW on the Secure Element is certified to EAL 5 or such. The TEE and HLOS have no role in its security or its startup.

The Secure Element is connected to the TEE by HW that can’t be manipulated by the HLOS.

The Secure Element produces full, proper signed Attestation Evidence. That goes to the Attester on the TEE and gets cryptographically bound into the Attestation Evidence produced by the TEE as a nested token.

The Endorser for the Secure Element is one that just handles Secure Elements, knows about their certification levels and such. It is separate from the Endorser for the TEE.

That is the main point about #3. To go a little further…

The HLOS also has an attester that collects evidence about itself and about apps.

It feeds its Attestation Evidence to the TEE, but this is probably not signed and secured as a nested token. It’s just a common submodule as per EAT.

Perhaps the TEE was involved in the start up and validation of the HLOS. Perhaps it wasn’t. It can work either way if the Endorsements are done right.

Note also that all three of the Attestation Environments are up and running all the time. None are short-lived running only during the boot cycle.

A good use of this architecture is to produce fully live Attestation Evidence each time a payment is made by the user of the mobile phone. This is a useful thing to do because payment app, the HLOS, the TEE, the fingerprint authentication in the TEE and the Secure Element all are used to make the payment.

So new fresh attestations of large parts of the system are produced day in and day out. It’s not just re sending the measurements that were taken and stored when the device booted.

(Any interest in this as an example as an addition to section 3 next to the layered attestation example?)

LL

---

From: "Smith, Ned" <[email-masked]>
Date: Fri, 16 Jul 2021 23:30:12 +0000

It is good to cite counter examples. There are cases where a composite device will have a target environment that is measured so it isn’t an incorrect statement. The RATS architecture isn’t trying to be normative or exclusionary. So any cases to the contrary are also reasonable.

Date: Friday, July 16, 2021 at 11:24 AM

On Jul 15, 2021, at 10:55 AM, Smith, Ned <[email-masked]<mailto:[email-masked]>> wrote:

Hi Ned,

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Sat, 17 Jul 2021 11:15:57 -0700

> Does the list believe these points should be in the arch draft or are they reasonably inferred?

Here’s a few more reasons I don’t think #3, the secure start up of the following layer, should be part of the duties of an Attesting Environment even for layered attestation.

— There are several architectures which one layer can use to secure the start up of the following layer. It can use a code signing scheme based on public key crypto to verify the code for the next layer. This scheme can be very simple or very complex. There could be SW version roll-back protection. It could also be done just with hashes, though this is less flexible. It could be super simple and just know which location in ROM to jump to. It can be a combination of any of the above. 

— It is a local device implementation characteristic; one among many RATS may rely on. While, the endorser needs to know some high-level characteristics of the architecture, it also needs to know lots of other stuff that is not mentioned in the architecture draft.

— As written, the layered attestation text implies to some of us that there is a Verifier on the device.

LL

---

From: Jeremy O'Donoghue <[email-masked]>
Date: Mon, 19 Jul 2021 10:00:23 +0000

I agree strongly with Laurence on this point - #3 is not necessarily a duty of the Attesting Environment. It is also  necessarily true that an attesting environment retains a thread of control in a composite device – I can think of cases where this is not so.

Best regards
Jeremy

On 17/07/2021, 19:19, "RATS" <[email-masked]> wrote:

CAUTION: This email originated from outside of the organization.

LL

---

From: "Smith, Ned" <[email-masked]>
Date: Mon, 19 Jul 2021 17:06:40 +0000

The diagram for layered device implies (IMO) that the target env containing the attesting env is a superset functionality of the attesting env. For the use cases where there is #3 functionality, this clearly exists in the target env. The discussion is questioning whether it belongs in the attesting env. From a least privilege point of view it makes sense to take a minimalist approach when considering what functionality belongs in the attesting env.

I don’t think the current ATWG tries to sort out which functionality belongs or doesn’t belong except to say that at least claims collection and evidence creation are in the attesting env.

Is it inferred that the #3 duty (though not in the attesting env but is in the target env) exists or should the arch ID include words to that effect?

-Ned

From: RATS <[email-masked]> on behalf of Jeremy O'Donoghue <[email-masked]>
Date: Monday, July 19, 2021 at 3:00 AM
To: Laurence Lundblade <[email-masked]>, "Smith, Ned" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Thomas Fossati <[email-masked]>
Subject: Re: [Rats] Definition of an Attesting Environment (and layered attestation)

Best regards
Jeremy

LL