Re: [EAT] [Rats] Introduction

[Laurence Lundblade <[e-mail]>]

Thanks for all that Andre,

The intention of EAT is try to span both the TCG, TrustZone and other technologies involved with attestation.  We haven't added text for measurement claims to the EAT draft yet, but some of us were planning on it and have some first drafts.

I say “try to” is because you can’t quite implement EAT using a standard TPM today. TPMs only sign certain data in a particular way, and it is not the CBOR/COSE format used by EAT or CWT (or JWT). The FIDO folks however have a way to use TPMs to sign FIDO attestations <https://fidoalliance.org/specs/fido-v2.0-ps-20150904/fido-key-attestation-v2.0-ps-20150904.html#tpm-attestation>. We may be able to do something similar.  We may also just define a way to tag and carry pure TPM remote attestations. Maybe there are 2-3 attestation variants for this.

I think the work here should be inclusive of TPM and non-TPM attestations, similar to what FIDO did for similar reasons. TPMs are very broadly deployed and used and there is deep experience with them.  Similarly TrustZone and similar technologies are in a billion plus smart phones and should to be included.

This is one of the reasons for forming a working group, rather than just defining some additional CWT / JWT claims. (I also think defining those claims in a universal way is interesting work). 


I have a few other comments on measurement.

My understanding is that the TPM measurements taken are boot are still quite good even though the TPM doesn’t make them. This is because it is done in stages. First some very trusted and very small code starts when the CPU comes out of reset. It’s only job is to load the next junk of code and measure it. It stores the measurement in the TPM. The next stage is similar but does more. In this scheme, no code ever measures itself and all code is measured before it starts running. 

TrustZone-based devices are not so standardized in how they boot and they haven’t done so much with measurement. However TrustZone is more capable than a TPM and can perform measurements of the non-secure world at any time. It doesn’t have to be at boot. This would allow some of the periodic configuration confirmation attestations that the router and network secure functions folks are talking about. 

LL





> On Sep 10, 2018, at 3:21 AM, AndreRein <[e-mail]> wrote:
> 
> From my perspective you are right that the current discussions around (remote) attestation are very TCG shaped and in general a TPM is often regarded as _the_ security anchor. In a way this makes a lot of sense, because the TPM offers a secure identity (Root of Trust for Reporting (RTR)) and a tamper-proof storage (Root of Trust for Storage (RTS)), both of which are required for an attestation process (at least how it is generally understood today). However, it is important to note that the measurements themselves are not performed by the TPM; the TPM is only used for the secure recording and reporting of measured values during the attestation. Depending on which parts of the system are to be attested, the actual measurements are provided by other (secure) components, starting from an initial (trusted) measurement component (Root of Trust for Measurement (RTM)).
>  
> I don't want to go too much into the technical details here, but I think it makes sense for a general specification of an attestation (and a corresponding protocol) to detach itself from the TPM as a term (I'm not saying that we do this actually) and instead argue on the basis of the RoTs involved. A TPM is an excellent reference implementation that provides certain RoTs in a very secure way, but a TPM provides only one implementation possibility that realizes parts of what is necessary to report a system’s state for conducting a (remote) attestation procedure.
>  
> Best regards,
>  
> Andre
>  
> From: RATS [mailto:[e-mail] <mailto:[e-mail]>] On Behalf Of Laurence Lundblade
> Sent: Sonntag, 9. September 2018 18:38
> To: Shawn Willden <swillden=[e-mail] <mailto:swillden=[e-mail]>>
> Cc: [e-mail] <mailto:[e-mail]>; Carsten Bormann <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>
> Subject: Re: [Rats] [EAT] Introduction
>  
> My understanding from the RATS BoF and talking to Henk, Marty and others is that it is about sending the attestations created by TPMs to a remote entity. These  attestation messages contain the usual measurements of the running SW that TPMs do. It is very TCG oriented. 
>  
> There is some possibility of defining a protocol to carry these attestations, but I don’t think anything has been written. 
>  
> There was a lot of interest in this from the network infrastructure folks that want to make sure routers, firewalls and such were booted and still running correctly. 
>  
> LL
>  
>  
>  
> 
> 
> On Sep 7, 2018, at 6:51 AM, Shawn Willden <swillden=[e-mail] <mailto:swillden=[e-mail]>> wrote:
>  
> Thanks. I need to get clear on what rats@ is about. Is there a draft?
>  
> On Fri, Sep 7, 2018 at 6:29 AM Carsten Bormann <[e-mail] <mailto:[e-mail]>> wrote:
> On Sep 6, 2018, at 18:37, Shawn Willden <swillden=[e-mail] <mailto:[e-mail]>> wrote:
> > 
> > Please excuse me if I'm violating some list etiquette with this introduction; it seemed like the best way to jump in. It appears that cross-posting between RATS and EAT is fairly common, so I think I'm good on that front :-)
> 
> Hi Shawn,
> 
> welcome to this discussion!
> 
> Indeed, as long as we are trying to find out what is what between eat@ and rats@, cross-posting is the way to go.
> 
> A thread of three of the messages triggered by your initial message went to eat@ only, though:
> 
> Archived-At: ⁨<https://mailarchive.ietf.org/arch/msg/eat/G5WvKAAXc16ixn30MbcfErLmUQ4 <https://mailarchive.ietf.org/arch/msg/eat/G5WvKAAXc16ixn30MbcfErLmUQ4>>⁩
> Archived-At: ⁨<https://mailarchive.ietf.org/arch/msg/eat/DxM8NcxqPsR6HZXDS1q24lUqMg8 <https://mailarchive.ietf.org/arch/msg/eat/DxM8NcxqPsR6HZXDS1q24lUqMg8>>⁩
> Archived-At: ⁨<https://mailarchive.ietf.org/arch/msg/eat/61cWm6byj-9tItyjUIi3PyGsCJk <https://mailarchive.ietf.org/arch/msg/eat/61cWm6byj-9tItyjUIi3PyGsCJk>>⁩
> 
> As these are essentially about rats@ content (proof of protection), it would be useful for rats@ people to read them, too (and then reply to both lists, please).
> 
> Grüße, Carsten
> 
> -- 
> Shawn Willden | Staff Software Engineer | [e-mail] <mailto:[e-mail]> | 801-477-4296
> _______________________________________________
> EAT mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/eat <https://www.ietf.org/mailman/listinfo/eat>
>  
> _______________________________________________
> EAT mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/eat <https://www.ietf.org/mailman/listinfo/eat>