Re: [Rats] Two types of secure attestation

[Monty Wiseman <[e-mail]>]

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]
> https://www.ietf.org/mailman/listinfo/rats