Re: [Rats] FIDO TPM attestation

["Fuchs, Andreas" <[e-mail]>]

The reason for this is that a TEE is a touring-complete execution environment for arbitrary code,
whilst the TPM further has a well-define precise functional logic instead of arbitrary code.
Thus only protocols that have the TPM's functional logic in mind can leverage it to the fullest and
FIDO unfortunately did not do so.

However, this fact that the TPM is well-define and precise proposes the big advantage since it provides
a much higher level of assurance. Not only the execution environment (i.e. TEE vs TPM chip) is
standardized and CC-evaluated, but the function logic (i.e. TPM command set) as well. The FIDO code
running inside a TEE is not standardized (to the level of TPM) and most certainly not CC-evaluated.

Therefore, the TPM is the preferred solution for anchoring trust with high assurance levels and it is the
duty of attestation protocols to account for its well-defined functional logic in order to establish maximum
trust in a device or statement.

Best regards,
Andreas
________________________________________
From: RATS [[e-mail]] on behalf of Laurence Lundblade [[e-mail]]
Sent: Wednesday, November 13, 2019 05:08
To: [e-mail]
Subject: [Rats] FIDO TPM attestation

Here’s evidence that remote TPM attestation is not just for routers and is used in non-YANG environments: https://fidoalliance.org/specs/fido-v2.0-ps-20150904/fido-key-attestation-v2.0-ps-20150904.html#tpm-attestation.

In non-TPM FIDO attestation, the whole attester is in the TEE or such. In TPM FIDO attestation only the key storage and signing is in the TPM. There is reliance on components outside of the TPM for the security of the attestation, so it isn’t the preferred form.

This is a reason to consider the TPM Token I’ve mentioned. It would allow remote TPM-based attestation to be used anywhere there is a TPM for use cases beyond routers and YANG.

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