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

[Laurence Lundblade <[e-mail]>]

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 <[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?
>  
> 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.
>  
>  
> “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.
>  
>  
> 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?
>  
>  
> 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.
>  
>  
> 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] <mailto:[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>
> 
> 
> _______________________________________________
> RATS mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>