Re: [Rats] Two types of secure attestation

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

See inline [nms]

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




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

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.


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.

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


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.
[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
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.
[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?

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