Re: [Rats] Two types of secure attestation

[Laurence Lundblade <[e-mail]>]

> On Dec 2, 2019, at 6:00 PM, Smith, Ned <[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…
> 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