Re: [Rats] Two types of secure attestation

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

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.

Besides that, what I think we are actually talking about is implicit and 
explicit attestation.

The "non-TPM-style" RATS Laurence is talking about seem to be implicit 
remote attestation and that if of course of "equal stature" to the 
implicit remote attestation that uses a TPM. I am not arguing with that 
- I am agreeing with that! :)

Viele Grüße,

Henk

On 23.11.19 20:20, Smith, Ned wrote:
> @laurence - By “this” you mean the difference between implicit and 
> explicit attestation?
> 
> *From: *RATS <rats-bounces@ietf.org> on behalf of Laurence Lundblade 
> <lgl@island-resort.com>
> *Date: *Saturday, November 23, 2019 at 8:44 AM
> *To: *Henk Berkholz <henk.birkholz@sit.fraunhofer.de>
> *Cc: *"rats@ietf.org" <rats@ietf.org>, Kathleen Moriarty 
> <kathleen.moriarty.ietf@gmail.com>, "Smith, Ned" <ned.smith@intel.com>
> *Subject: *Re: [Rats] Two types of secure attestation
> 
>     On Nov 21, 2019, at 6:26 PM, Henk Birkholz
>     <henk.birkholz@sit.fraunhofer.de
>     <mailto:henk.birkholz@sit.fraunhofer.de>> wrote:
> 
>     There are no semantic difference between the "simple non-TPM EAT"
>     scenario and the TPM-based implicit remote attestation scenario.
>     They are if fact the "same types of secure attestation”.
> 
> I don’t have any need to drive taxonomic distinction when unnecessary, 
> but note that the YANG module has to have explicit different facilities 
> to be able to handle both.
> 
> The verifier implementations for these two types are also very 
> different. in the "non-TPM EAT” scenario no known-good-values for SW 
> hashes are need to be supplied to the verifier.
> 
> I don’t think these are the only differences that we’ll encounter in 
> real implementations.
> 
> This should probably all be described the architecture document. Seems 
> as significant as the passport vs background check distinction.
> 
> LL
> 
> 
> 
> 
> _______________________________________________
> RATS mailing list
> RATS@ietf.org
> https://www.ietf.org/mailman/listinfo/rats
> 