Re: [Rats] Two types of secure attestation

[Laurence Lundblade <[e-mail]>]

> On Nov 24, 2019, at 7:31 AM, Henk Birkholz <[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