Re: [Rats] Two types of secure attestation

[Henk Birkholz <[e-mail]>]

Hi Laurence,

I am a bit time constrained right now, but I think we mostly agree.

Thank you for you explanation about the boot_state Claim - it was really 
hard to wrap my mind around that. Is it okay to raise an issue that this 
concept might require more explanatory text in the EAT I-D?

I'll compose some text about the horrible yet remediateable confusion 
that is the "“secure boot”, “authenticated boot” and “trusted boot”, 
etc. pp scope. Maybe I'll do it with Monty, if he finds the time for 
that in the very near future.

I am very happy that we already agreed on Attestation Evidence, 
Attestation Result, (maybe) Appraisal Policy (formerly known as 
Reference Values), Endorsements & the roles Attester, Endorser (formerly 
known as Asserter), Verifier and Relying Party. There was significant 
progress at the last IETF meeting. Without Ned, Dave, Michael, Thomas & 
you this would not have been such a productive meeting.

Viele Grüße from Manchester,

Henk

On 24.11.19 21:01, 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
> 
>