Re: [Rats] Two types of secure attestation

["Smith, Ned" <[e-mail]>]

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 <[e-mail]> on behalf of Laurence Lundblade <[e-mail]>
Date: Friday, November 29, 2019 at 2:10 PM
To: Monty Wiseman <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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

[e-mail]<mailto:[e-mail]>

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