Re: [Rats] Standardizing TPM output in attestation evidence

[Laurence Lundblade <[e-mail]>]

On Aug 16, 2021, at 10:10 AM, Smith, Ned <[e-mail]> wrote:
> 
> 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


>  
> From: RATS <[e-mail]> on behalf of Laurence Lundblade <[e-mail]>
> Date: Friday, August 6, 2021 at 7:27 PM
> To: "Smith, Ned" <[e-mail]>
> Cc: rats <[e-mail]>, "Eric Voit (evoit)" <evoit=[e-mail]>, "Panwei (William)" <[e-mail]>
> Subject: Re: [Rats] Standardizing TPM output in attestation evidence
>  
> 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 <[e-mail] <mailto:[e-mail]>> wrote:
>>  
>>> 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). 
>> 
>> 
>>> TPM based evidence is typically backed by logs.  E.g.: see IMA logs;
>>> https://sourceforge.net/p/linux-ima/wiki/Home/ <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.)
>> 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 <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)" <[e-mail] <mailto:[e-mail]> on behalf of evoit=[e-mail] <mailto:evoit=[e-mail]>> wrote:
>> 
>>    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.
>> 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
>> 
>> 
>>> 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/ <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. 
>> 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.
>> 
>> 
>>> 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.
>> NMS> +1
>> 
>> 
>>> 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.
>> 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. 
>> 
>> 
>>> 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.
>> 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
>>> _______________________________________________
>>> RATS mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>
>  
> _______________________________________________
> RATS mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>