Re: [Rats] Standardizing TPM output in attestation evidence

["Eric Voit (evoit)" <[e-mail]>]

Hi Laurence,

I agree with you and Panwei that TPM2 support for PCs/IoT could be interesting for this WG to investigate.

I don't think it is an easy match for the EAT draft for reasons embedded below.

> -----Original Message-----
> Panwei , August 5, 2021 6:08 AM
> 
> Hi Laurence,
> 
> Thanks for sharing your thoughts. I think the use case is reasonable.
> I agree with you that these types of devices may not use YANG, so some other
> means need to be provided, for example defining the CWT claims.
> 
> The CHARRA draft defines the attestation evidence suitable for devices using
> TPMs in YANG, but YANG doesn't provide security protection for the output of
> TPM. Actually the output of TPM is already signed by the TPM itself, what we
> need is to provide a secure transportation for the output, for example using
> NETCONF. TPM itself isn't the Attesting Environment, so it doesn't produce the
> Evidence directly, it needs other component's help to generate the YANG styled
> Evidence, and TPM's output is So this may be a little different than the current
> EAT claims. We have two options to handle the TPM's output, one is to define
> the traditional CWT claims, and the TPM's output is the "value" part of the claim,
> and then use the EAT attester's key to protect the claim. The other option is to
> just define the UCCS-style claims and use the secure transportation to transfer
> the claims and no need to sign the claims again.

Agree.  Nesting the signing of TPM claims again with an EAT attester key is of limited value.  Some method of proving both freshness and a binding between the two nested environments is needed. 

Proving the proper binding of nesting of claims and disproving a MITM to a Relying Party is non-trivial, and needs WG discussion.  (E.g., when the PC/IoT device doesn't have a unique key for each instance, how do you prove that the nested claims are not coming from a TPM which is elsewhere?)

> I don't know whether this should be defined in EAT draft or a separate draft. But
> I'd like to highlight that even if the device only has TPM and has no EAT
> attester/Attesting environment, the YANG data models may also not be suitable
> for this device and it has to use some other format data models.
> 
> Regards & Thanks!
> Wei Pan
>
> Laurence Lundblade, Wednesday, August 4, 2021 4:27 PM
> 
> There has been a side discussion about TPMs and EAT. This is to bring it to the
> main RATS list and to state more clearly the use case I have in mind.
> 
> The devices I’m thinking of are roughly this:
>  - Desktops, servers, IoT devices… (not network equipment, probably not mobile
> phones)
>  - They have an off-the-shelf TPM2 soldered on to their PCB
>  - Likely to be Intel CPUs, but not necessarily
> 
> We want these devices to do attestation and generate attestation evidence (all
> devices on the Internet should do attestation at some point!). We want that
> attestation evidence to include measurements taken by the TPM. We also want
> attestation evidence from parts of the device other than the TPM.
> 
> That’s the very general use case I have in mind very simply stated.
> 
> Assuming this use case makes sense, then how should this get standardized and
> implemented?

TPM based evidence is typically backed by logs.  E.g.: see IMA logs;
https://sourceforge.net/p/linux-ima/wiki/Home/

So standardizing TPM output is of limited value unless you also standardize log deliver and have something which can validate the logs which back the evidence.  (Or if you restrict the scope to specific Known Good Values, PCR banks, and hash algorithms.)
 
> There is protocol standardization in YANG now for TPM output, but I don’t think
> we want to use YANG for this. I don’t think YANG is in common use for these
> types of devices and has a particular interaction model.

I agree that YANG is not right for PCs/IoT.  However the Charra has other aspects which need to be addressed in any solution here:

- operational ownership of the TPM keys: Routers/switches can prove their individual identity based on locally managed keys.  PC/IoT typically don't want to have devices uniquely tracked.  Without such ownership, you might have to rely on TPM chip manufacturer as a root-of-trust.  In such a case, how do you prove that the environment surrounding the TPM is providing good hash values?  There are quite a number of constraints which need to be nailed down.

- freshness: a TPM needs a nonce or some other mechanism to protect against replay attacks.  This is why Charra exposes RPCs and not the raw TPM datastore structures.

- supporting evidence: per the comment above, TPM PCRs contained hashed evidence used to validate the full set of logs which are stored in more vulnerable locations. 

> I think EAT is a good
> candidate because it is an independently secured blob that can be carried by the
> protocols already in use with these devices.

I do think EAT can play here.  But I would want more requirements / information in the draft on how exactly the blob needs to be secured.  E.g., Where is the private key stored which secures this EAT blob?   It shouldn't be in some general application running on the main CPU.    Beyond this, what are the mechanisms for proofs of proper integration (and no MITM) between the nested signatures.
 
> This then requires that some output from the TPM be put into an EAT. It seems
> useful to standardize that here in RATS and it seems in scope for the charter.
> 
> I don’t have a strong opinion or detailed proposal for what TPM output goes
> into the EAT or the particular HW, SW and attestation architecture of the device.
> That’s something we can work out. I am pretty sure the device would have two
> attesters in a compound/layered arrangement. The attestation evidence
> produced by the TPM would be nested in the attestation evidence produced by
> the EAT attester.

Makes sense.  There needs to be significant thought placed into the nested structures.  Such needs were the reason for the "AR Augmented Evidence" structures within draft-voit-rats-attestation-results.

> I have some leaning towards putting this work in the EAT document, but it could
> also be in another document.
> 
> I think this is important for RATS because of the very strong association of TPMs
> with good attestation and for the goal to support attestation for all kinds of
> devices and environments (not just network equipment).
> 
> 
> A few things this is not about:
> 
> - This is not about changing the format that a TPM2 outputs. This is about the
> ability to use the off-the-shelf TPMs that are manufactured by the millions and
> sitting in warehouses today.
> 
> - This is not about local device boot architecture. This is about remote
> attestation, about attestation evidence transmitted to the verifier/relying party.

It might not be possible to fully get away from device boot architecture.  Lower numbered PCRs typically contain information on boot metrics.  And without being able to verify these boot metric are ok, nobody using a TPM will assume higher numbered PCRs indicate trustworthiness.

Eric
 
> LL
> _______________________________________________
> RATS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats