Subject: [Rats] Standardizing TPM output in attestation evidence

From: Laurence Lundblade <[email-masked]>
Date: Wed, 4 Aug 2021 13:26:53 -0700

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?

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

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.

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.

LL

---

From: "Panwei (William)" <[email-masked]>
Date: Thu, 5 Aug 2021 10:07:33 +0000

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.

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

> -----Original Message-----
> From: RATS [mailto:[email-masked]] On Behalf Of Laurence
> Lundblade
> Sent: Thursday, August 5, 2021 4:27 AM
> To: rats <[email-masked]>
> Subject: [Rats] Standardizing TPM output in attestation evidence
> 
> 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.
> 
> 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.
> 
> 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 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.
> 
> 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.
> 
> 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).
> 
> 
> - 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.
> 
> LL
> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 5 Aug 2021 14:34:48 +0000

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.

> Panwei , August 5, 2021 6:08 AM
> 
> Hi Laurence,
> 
> 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.
> 
> 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.
> 

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

---

From: "Smith, Ned" <[email-masked]>
Date: Thu, 5 Aug 2021 17:15:25 +0000

>TPM itself isn't the Attesting Environment, so it doesn't produce the
> Evidence directly,...
The RATS Arch I-D suggests that a minimal Attester does two things (a) collect claims and (b) create (aka sign) Evidence. A TPM signs Evidence but doesn't collect claims. It is therefore only half of an Attester (Attesting Environment). 

>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.)
Another way to think about TPM evidence is the log contains 'Claims' and the PCRs contain the digests of the log that are encrypted by a private key (aka a digital signature), what is encrypted (aka signed) is a digest of digests. 
IMHO it is reasonable to sign the log directly. This provides another avenue for protecting the log besides the TPM. If the log was in a standard format then Verifiers would more easily be able to parse and comprehend it. The TCG are interested in a standardized log see https://trustedcomputinggroup.org/wp-content/uploads/TCG_IWG_CEL_v1_r0p30_13feb2021.pdf 
A Verifier has to parse the (Evidence) log in order to do semantic matching of reference values. This is independent of how the log is integrity protected. PCRs are a digest of digests. A signature is a digest of a message. The signature isn't the difficult part of interoperability IMO, the message is however.

See inline also. (NMS>)

On 8/5/21, 7:35 AM, "RATS on behalf of Eric Voit (evoit)" <[email-masked] on behalf of evoit=[email-masked]> wrote:

    Hi Laurence,

NMS> +1

NMS> +1

    - 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. 
NMS> TCG event logs are typically unsigned because there integrity is typically protected by a TPM. 
NMS> EAT and DICE Evidence are signed and therefore are safe to store in unprotected storage, but signing keys still have to be protected.

NMS> +1

    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.
NMS> +1. The focus should be on how to recognize Target and Attesting Environments so that the appropriate Claims / measurements can be ascribed to them. Attesting Environments also should have keys ascribed to them. Naming the Attesting Environments helps relate a key to that environment. 

    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.
NMS> +1. The layering and composite device patterns in the RATS Arch strongly suggests there are trust dependencies between the various Environments. This means Verifiers need to respect and check that these trust dependencies are correct.

    Eric

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 6 Aug 2021 19:26:52 -0700

Thanks all for reviewing and the useful comments.

My opinion is now that this should NOT be in the EAT draft. There’s too much work here and we want to get the EAT draft done.

I’m going to close the issue that Michael filed  <https://github.com/ietf-rats-wg/eat/issues/64>related to PCR in EAT.

Hopefully this gets taken up in another draft, maybe Kathleen’s? I think it is important to do some work here given how much the world thinks attestation == TPM.

Sound OK to everyone?

LL

> On Aug 5, 2021, at 10:15 AM, Smith, Ned <[email-masked]> wrote:
> 
>> https://sourceforge.net/p/linux-ima/wiki/Home/ <https://sourceforge.net/p/linux-ima/wiki/Home/>
>> 
> IMHO it is reasonable to sign the log directly. This provides another avenue for protecting the log besides the TPM. If the log was in a standard format then Verifiers would more easily be able to parse and comprehend it. The TCG are interested in a standardized log see https://trustedcomputinggroup.org/wp-content/uploads/TCG_IWG_CEL_v1_r0p30_13feb2021.pdf <https://trustedcomputinggroup.org/wp-content/uploads/TCG_IWG_CEL_v1_r0p30_13feb2021.pdf> 
> On 8/5/21, 7:35 AM, "RATS on behalf of Eric Voit (evoit)" <[email-masked] <mailto:[email-masked]> on behalf of evoit=[email-masked] <mailto:evoit=[email-masked]>> wrote:
> 
>    Hi Laurence,
> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>

---

From: "Smith, Ned" <[email-masked]>
Date: Mon, 16 Aug 2021 17:10:24 +0000

Are you saying you’ll close issue #64 as do-not-fix?

From: RATS <[email-masked]> on behalf of Laurence Lundblade <[email-masked]>
Date: Friday, August 6, 2021 at 7:27 PM
To: "Smith, Ned" <[email-masked]>
Cc: rats <[email-masked]>, "Eric Voit (evoit)" <evoit=[email-masked]>, "Panwei (William)" <[email-masked]>
Subject: Re: [Rats] Standardizing TPM output in attestation evidence

I’m going to close the issue that Michael filed <https://github.com/ietf-rats-wg/eat/issues/64> related to PCR in EAT.

Sound OK to everyone?

LL

On Aug 5, 2021, at 10:15 AM, Smith, Ned <[email-masked]<mailto:[email-masked]>> wrote:

See inline also. (NMS>)

On 8/5/21, 7:35 AM, "RATS on behalf of Eric Voit (evoit)" <[email-masked]<mailto:[email-masked]> on behalf of evoit=[email-masked]<mailto:evoit=[email-masked]>> wrote:

   Hi Laurence,

-----Original Message-----

Hi Laurence,

Regards & Thanks!
Wei Pan

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

Assuming this use case makes sense, then how should this get standardized and
implemented?

I think EAT is a good

I have some leaning towards putting this work in the EAT document, but it could
also be in another document.

   Eric

LL
_______________________________________________
RATS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rats

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 16 Aug 2021 20:10:29 -0700

> Are you saying you’ll close issue #64 as do-not-fix?

Yes (but I haven’t started using that label yet in the EAT git hub).

No objection to the work, just think it should be another document.

LL

>> On Aug 5, 2021, at 10:15 AM, Smith, Ned <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 20 Aug 2021 08:16:53 -0400

Panwei,

I agree and that's what's proposed in my draft, to share the log output or
a link to the TPM log. I don't think we need to replicate the format of the
TPM and for the design in attestation sets, you'd include all of the
relevant logs (or a pointer if that can work) to the TPM log, PCR log, or
other relevant signed log on other platforms (TBD) that align to a set of
policies or measurements to that defined set.

Best regards,
Kathleen

On Thu, Aug 5, 2021 at 6:07 AM Panwei (William) <[email-masked]>
wrote:

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

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 20 Aug 2021 08:21:11 -0400

Thanks, Laurence. I think that's the best approach and we can work through
how to represent the evidence from a set contained in other signed log
formats. This was likely a good discussion to point out the differences in
drafts, thank you.

Best regards,
Kathleen

On Fri, Aug 6, 2021 at 10:27 PM Laurence Lundblade <[email-masked]>
wrote:

> My opinion is now that this should NOT be in the EAT draft. There’s too
> much work here and we want to get the EAT draft done.
>
> I’m going to close the issue that Michael filed
> <https://github.com/ietf-rats-wg/eat/issues/64>related to PCR in EAT.
>
> Hopefully this gets taken up in another draft, maybe Kathleen’s? I think
> it is important to do some work here given how much the world thinks
> attestation == TPM.
>
> Sound OK to everyone?
>
> LL
>
>
> The RATS Arch I-D suggests that a minimal Attester does two things (a)
> collect claims and (b) create (aka sign) Evidence. A TPM signs Evidence but
> doesn't collect claims. It is therefore only half of an Attester (Attesting
> Environment).
>
> 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.)
>
> Another way to think about TPM evidence is the log contains 'Claims' and
> the PCRs contain the digests of the log that are encrypted by a private key
> (aka a digital signature), what is encrypted (aka signed) is a digest of
> digests.
> IMHO it is reasonable to sign the log directly. This provides another
> avenue for protecting the log besides the TPM. If the log was in a standard
> format then Verifiers would more easily be able to parse and comprehend it.
> The TCG are interested in a standardized log see
> https://trustedcomputinggroup.org/wp-content/uploads/TCG_IWG_CEL_v1_r0p30_13feb2021.pdf
>
> A Verifier has to parse the (Evidence) log in order to do semantic
> matching of reference values. This is independent of how the log is
> integrity protected. PCRs are a digest of digests. A signature is a digest
> of a message. The signature isn't the difficult part of interoperability
> IMO, the message is however.
>
> See inline also. (NMS>)
>
> On 8/5/21, 7:35 AM, "RATS on behalf of Eric Voit (evoit)" <
> [email-masked] on behalf of evoit=[email-masked]>
> wrote:
>
>    Hi Laurence,
>
> other
> using
>    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.
> NMS> +1
>
>
>    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?)
> NMS> +1
>
> draft. But
> (all
>    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.)
>
> think
>    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.
> NMS> EAT and DICE Evidence are signed and therefore are safe to store in
> unprotected storage, but signing keys still have to be protected.
>
> I think EAT is a good
>    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.
> NMS> +1
>
> seems
>    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.
> NMS> +1. The focus should be on how to recognize Target and Attesting
> Environments so that the appropriate Claims / measurements can be ascribed
> to them. Attesting Environments also should have keys ascribed to them.
> Naming the Attesting Environments helps relate a key to that environment.
>
> the
>    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.
> NMS> +1. The layering and composite device patterns in the RATS Arch
> strongly suggests there are trust dependencies between the various
> Environments. This means Verifiers need to respect and check that these
> trust dependencies are correct.
>
>    Eric
>
> LL

-- 

Best regards,
Kathleen