Re: [Rats] Standardizing TPM output in attestation evidence

[Kathleen Moriarty <[e-mail]>]

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 <[e-mail]>
wrote:

> 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]> 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/
>
> 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)" <
> [e-mail] on behalf of 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/
>
>    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]
> https://www.ietf.org/mailman/listinfo/rats
>
>
> _______________________________________________
> RATS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats
>


-- 

Best regards,
Kathleen