Subject: Re: [Rats] Two types of secure attestation

From: "Smith, Ned" <[email-masked]>
Date: Tue, 3 Dec 2019 02:00:32 +0000

In both Measured Boot and Verified Boot the Relying Party is applying the (boot) Policy.

Maybe an exercise to map the various RATS roles onto the two forms of boot (Measured/Verified) would be helpful?
Measured Boot:

  *   Attester performs: RTM --- Component --- Component --- Component --- End State
  *   Verifier: Receives Evidence about the End State from the Attester and produces an Attestation Result of the form (End State is/is-not acceptable or it could also simply assert “End State” to the Relying Party)
  *   Relying Party:  Boot Policy identifies Verifiers trusted to say end state is/is-not acceptable or lists acceptable/unacceptable end states that RP compares to Attestation Results asserted End State.

Verified Boot:

  *   Attesting Env (aka Root of Trust) is the RTV.
  *   Attested Env executes: --- Component(A) and becomes Attesting Env for --- Component(B) etc…
     *   For each stage of the boot process the Attesting Env Measures Attested Env; Attesting Env performs the Verifier Role and Relying Party Roles (as described above for Measured Boot). These are local Verfiers / Relying Parties.
     *   A boot policy is provisioned/available for Verifier and RP at each stage until End State is realized.

It is possible to create a hybrid of the two where Verified Boot is applied and then the End State environment becomes the Attester that asserts to a remote Verifier that it booted using a Verified Boot mechanism.

-Ned

From: RATS <[email-masked]> on behalf of Laurence Lundblade <[email-masked]>
Date: Friday, November 29, 2019 at 2:10 PM
To: Monty Wiseman <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Rats] Two types of secure attestation

That is really helpful, Monty. Thank you!

My understanding is that TPM-based remote attestation is all about sending the Measured Boot result to a server / service that is the verifier + relying party. That is what the Yang module draft, before EAT was added, is about, what Guy’s RIV drafts is about, and Franke pub-sub draft is about.

My understanding is that Verified Boot is not directly relevant to the these just-mentioned IETF drafts. Devices doing remote Measured Boot might have used Verified Boot or might not have. It doesn’t matter. The remote server / service doesn’t know. It is not reported to them in the remote attestation.

In this regard, EAT is in a way the opposite. For SW-based implementations of EAT, Verified Boot is critical. The EAT is of little value without it. The server / service trusts an EAT because the manufacturer committed to not putting EAT signing keys into devices that don’t implement Verified Boot.

Does this line up with how you understand it?

LL

On Nov 27, 2019, at 12:11 PM, Monty Wiseman <[email-masked]<mailto:[email-masked]>> wrote:

Let's not use confusing terms like TPM-style / TCG language. I propose
we start with lower-level fundamental definitions or even axioms for
boot types. Within those definitions, I recommend deprecating the term
"Secure Boot" as it's imprecise and even misleading. I expect there to
be variations on these creating derivative definitions but I postulate
these are fundamental as basic building blocks.

Root of Trust: Something that is assumed to always operate in the
expected manner. The implementation is assumed to be correct. How it is
implemented it outside the scope of its definition.

Verified Boot: Starts with a Root of Trust. For this type of boot the
Root of Trust is the Root of Trust for Verification (RTV). The RTV
includes a boot policy which is likely a verification key. The RTV
enforces the boot policy which continues through the boot process
assuming each component continues enforcing the boot policy or other
policies authorized by the RTV's boot policy. The trust in the device
depends on the RTV's boot policy and not on any external entity such as a
Verifier. The boot policy is locked by the RTV and cannot be further
evaluated beyond a binary "Trusted" or "Not Trusted" state. The evidence
of whether this device is trusted is, therefore, determined by whether
it boot to the correct state. (Some would say this is "existential boot.)

The TPM has no dependency on Verified Boot and Verified boot has no
architectural dependence on the TPM.

Measured Boot: Starts with the Root of Trust. For this type of boot it
is the Root of Trust for Measurement (RTM). The RTM contains no boot
policy. The device's components are recorded and stored through the boot
process as each component is assumed to continue measurement process. At
some time during the boot process these measurements are converted to
evidence and send to a Verifier. The trust in the device depends on a
Verifier's evaluation of this evidence. The Verifier has a rich set of
policy options available it beyond a binary "Trusted" or "Not Trusted"
state. The type of boot depends on a trusted component (such as a TPM)
record and converted the measurements into evidence.

Summary:
The difference between Verified Boot and Measured boot is where the
policy is enforced.

Verified Boot:
      1> Policy is hard coded at boot time, is immutable, and binary.
      (This form of boot is "existential" -- The device either boots to
      a valid state, or not)

      2> Is simpler to implement but less flexible

Measured Boot:
      1> The trust state is determined by a Verifier using evidence
      about the device and a flexible set of policies.

      2> Is more complex to implement but more flexible.

Diagram:

Verified Boot===>

    Policy

    |

    V

    RTV --- Component --- Component --- Component --- End State:

    A trusted device state is created only if all policies were met
    (i.e, the device booted). If any policy was not met, the device (as
    it is expected) doesn't really exist (it appears as a different
    device)

Measured Boot===>

                                                            Policy

                                                               |

                                                               V

    RTM --- Component --- Component --- Component --- End State:

   Trust State determined by a Verifier by appraising evidence collected
   using a set of policies.

Monty
Disclaimer: This is my personal opinion and not that of my employeer or
the Trusted Ccomputing Group. While I co-chair TCG's Trusted Network
Connect and Infrastructure Working Groups, the above defintions have
not been officially adopted by the TCG's Technical Committee or Board of
Directors.
On 11/24/19 3:01 PM, Laurence Lundblade wrote:

On Nov 24, 2019, at 7:31 AM, Henk Birkholz <[email-masked]<mailto:[email-masked]>> wrote:

Hi all,

in a nutshell, one of the things I tried to express is that the following quite is simply not correct wrt to what is called here the "TPM-style" (I would really like to not use the words "TPM-style" and not to mixing authenticated & secure boot. Authenticated Boot is fine):
> Primarily the difference between TPM-style that doesn’t rely on secure boot and non-TPM-style that does rely on secure boot.

It’s hard to know what to call things. I’m learning the “TCG language” slowly and we’re also evolving (in the architecture document) a common language. I keep trying terms and definitions to see what sticks and what doesn’t. Pretty sure we agree on “attestation evidence”, “verifier” and “attestation result”, but I don’t know what “secure boot”, “authenticated boot” and “trusted boot” mean to you so I don’t know which term to use.

It is never possible to create TPM structures that are signed Attestation Evidence, if a device that is explicitly intended to conduct "secure boot" did actually not do so successfully. That is one of the key-features of TPM/TSS remote attestation procedures.

It seems to me that TPM-style attestation where you measure each step in the boot sequence and report to a verifier was designed to work without secure boot. However I can see that it could also work with secure / trusted / authenticated boot.

On the other hand, what leaves me puzzled is the following. If these three quotes are all correct...

You cannot create an EAT unless the authenticated boot was successful. The key material with which to sign the EAT is inaccessible if authenticated boot fails (or else the device just won’t boot at all).

draft-ietf-rats-eat-01:

All claims are optional

and draft-ietf-rats-eat-01 again:

3.7.  Secure Boot and Debug Enable State Claims (boot_state)
  This claim is an array of five Boolean values indicating the boot and
  debug state of the entity.

... one is allowed either to omit that Claim in an EAT or set some values of the Claim members to false. Therefore indicating that the boot state is, e.g. "secure_boot_enabled=> false", and still be able to create the EAT. Is that correct? If not, why include this member of the boot_state Claim at all? It always made me think until now that it allows for a device to not conduct "secure boot" and still be able to create an EAT.

Yes, you are right that in some cases it would make no sense to have the secure boot claim. It is basically an implicit claim. Here’s some where it does make sense to have an explicit secure boot claim.

The main attester might boot securely, but submods might not.

It is possible to build pure HW that implements EAT attestation. It might be a part of a SoC. That attestation HW doesn’t use the main CPU to implement the attester, but can report on how the main CPU booted.

Besides that, what I think we are actually talking about is implicit and explicit attestation.

Seems like you have to say which claims are implicit and which claims are explicit and in many attestations you need and get both.

For example, you called out a situation where the secure boot claim is implicit and questioned the need for the claim. I then called out a situation where the secure boot claim is explicit.

In one attestation the secure boot claim might be implicit and the GPS location is explicit.

LL

_______________________________________________

RATS mailing list

[email-masked]<mailto:[email-masked]>

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

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 3 Dec 2019 11:28:00 -0800

> On Dec 2, 2019, at 6:00 PM, Smith, Ned <[email-masked]> wrote:
> 
> Attester performs: RTM --- Component --- Component --- Component --- End State
> Verifier: Receives Evidence about the End State from the Attester and produces an Attestation Result of the form (End State is/is-not acceptable or it could also simply assert “End State” to the Relying Party)
> Relying Party:  Boot Policy identifies Verifiers trusted to say end state is/is-not acceptable or lists acceptable/unacceptable end states that RP compares to Attestation Results asserted End State.
>  

Yes, this makes sense.

> Verified Boot:
> Attesting Env (aka Root of Trust) is the RTV.
> Attested Env executes: --- Component(A) and becomes Attesting Env for --- Component(B) etc…
> For each stage of the boot process the Attesting Env Measures Attested Env; Attesting Env performs the Verifier Role and Relying Party Roles (as described above for Measured Boot). These are local Verfiers / Relying Parties. 

Conceptually and technically, I understand this frame up and its generality.

However, I think the spirit of work in RATS is that the verifier and relying party are not local. The spirit of the definition of relying party is that is separate from the device OEM, for example a bank or an enterprise, that wants to know about device.

Most implementations today use proprietary formats in their implementation of Verified Boot.  There are lots of idiosyncrasies to it that depend on the HW and OS, boot speed requirements, updatability requirements, manufacturing requirements and so on. It is not a design goal of ours that Evidence and Result formats be useful for local verification internal to Verified Boot. 

Since this is IETF, we should make the IP-based network protocols our focus.

Here’s how I’d make some sense of the use cases for these in RATS

Verified Boot only
The OEM of the device controls the SW on it. The end user does not. The OEM provisions attestation key material that is only accessible when Verified Boot succeeds. This is classic EAT.

Measure Boot only
The end user can install whatever SW they want. The OEM doesn’t control it. A remote Boot Measurement is sent as an attestation to the remote Verifier and on to the remote Relying Party. That Relying Party decides if they trust the device by comparing to known-good-values.

Verified Boot + Measured Boot
The OEM controls SW on the device. The end user does not. Attestation can be performed either EAT style or Measured Boot style or both at the same time. If Measured Boot style, then a TPM is probably needed and adds to the BoM cost. If EAT style, the extra BoM cost is in the key set up and a little SW and HW to prevent the keys use when Verified Boot fails. If both, then both BoM cost additions.

I think we want to support all three in RATS.

All that said, I don’t know that much about the use of Measured Boot, in particular end-end use cases with a remote verifier and relying party. It would be really helpful to have description of some real concrete examples.

LL

---

From: "Smith, Ned" <[email-masked]>
Date: Tue, 3 Dec 2019 20:14:34 +0000

See inline [nms]

From: Laurence Lundblade <[email-masked]>
Date: Tuesday, December 3, 2019 at 11:28 AM
To: "Smith, Ned" <[email-masked]>
Cc: Monty Wiseman <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Rats] Two types of secure attestation

On Dec 2, 2019, at 6:00 PM, Smith, Ned <[email-masked]<mailto:[email-masked]>> wrote:

·         Attester performs: RTM --- Component --- Component --- Component --- End State

·         Verifier: Receives Evidence about the End State from the Attester and produces an Attestation Result of the form (End State is/is-not acceptable or it could also simply assert “End State” to the Relying Party)

·         Relying Party:  Boot Policy identifies Verifiers trusted to say end state is/is-not acceptable or lists acceptable/unacceptable end states that RP compares to Attestation Results asserted End State.

Yes, this makes sense.

Verified Boot:

·         Attesting Env (aka Root of Trust) is the RTV.

·         Attested Env executes: --- Component(A) and becomes Attesting Env for --- Component(B) etc…

o    For each stage of the boot process the Attesting Env Measures Attested Env; Attesting Env performs the Verifier Role and Relying Party Roles (as described above for Measured Boot). These are local Verfiers / Relying Parties.

However, I think the spirit of work in RATS is that the verifier and relying party are not local. The spirit of the definition of relying party is that is separate from the device OEM, for example a bank or an enterprise, that wants to know about device.
[nms] Agree that the spirit of RATS is that Verifier is remote e.g. “Remote ATtestation procedureS”. However, the architecture should allow for (and not artificially constrain) RATS Roles to be only remote since there are common scenarios that aren’t remote.

Most implementations today use proprietary formats in their implementation of Verified Boot.  There are lots of idiosyncrasies to it that depend on the HW and OS, boot speed requirements, updatability requirements, manufacturing requirements and so on. It is not a design goal of ours that Evidence and Result formats be useful for local verification internal to Verified Boot.
[nms] Agree. In at least one iteration of the RATS architecture the Roles and Actors were separable / composable and in cases where multiple Roles were performed by the same Actor, it was considered ‘uninteresting’ for RATS to define interoperability.

Since this is IETF, we should make the IP-based network protocols our focus.
[nms] And interoperable claims structures.

The OEM of the device controls the SW on it. The end user does not. The OEM provisions attestation key material that is only accessible when Verified Boot succeeds. This is classic EAT.
[nms] The Attester claims that a particular boot sequence occurred, possibly without explicitly identifying which software was used? It is up to the claim definition to define what it means to report the ending state of a verified boot. This claim is an attestation in every sense of the word.

Measure Boot only
[nms] +1

Verified Boot + Measured Boot
The OEM controls SW on the device. The end user does not. Attestation can be performed either EAT style or Measured Boot style or both at the same time. If Measured Boot style, then a TPM is probably needed and adds to the BoM cost. If EAT style, the extra BoM cost is in the key set up and a little SW and HW to prevent the keys use when Verified Boot fails. If both, then both BoM cost additions.
[nms] DICE is probably a good example of hybrid of verified + measured boot. I don’t think it makes sense to stereotype RATS claims in terms of a particular RoT. Systems with TPM can also implement all of the above forms.

I think we want to support all three in RATS.
               [nms] Agree, but it may not be in the form of a single claim. It might make sense to use multiple claims. Possibly there should be profiles for how a set of claims might be needed to support one of the above three boot options?

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 3 Dec 2019 13:45:38 -0800

> On Dec 3, 2019, at 12:14 PM, Smith, Ned <[email-masked]> wrote:
>> Verified Boot:

No artificial constraints seems OK as long as it doesn’t involve any discussion time in the WG. We already have quite a lot to figure out and shouldn’t burn time on it.  My read is that is well outside the charter. 

> ...

Yes, interoperable claims carried over IP-based networks. 

>                [nms] Agree, but it may not be in the form of a single claim. It might make sense to use multiple claims. Possibly there should be profiles for how a set of claims might be needed to…

I’m not even sure there’s agreement that it should be in the same signed attestation messages. So far that YANG module gives the format for signing TPM output and that’s all it can sign. The EAT draft says how to sign other forms of attestation and we’re not so far defining claims where it carries TPM or TPM-like output.

LL