Re: [Rats] FIDO TPM attestation

[Henk Birkholz <[e-mail]>]

Me too :-)

I actually pulled it into content for my slides. It perfectly shows the 
levels of assurances involved and why people typically choose to build 
architectures on the RoT assumption.

"TPM-Fail" occurred in a physical TPM and a Firmware TPM running in a 
TEE. The failed primitive is "shielded secret" due to a side-channel 
attack (timing measurements of crypto - again...). This is an 
implementation specific attack as only two of many TPM flavors were 
affected (for now), most are not.

What does this tell us? :-)

1.) The quality of a specification does not guarantee equally secure 
products based on that spec (this will be true for everything RATS, too).

2.) If you use phyiscal TPM, TEE-TPM (so called Firmware TPM), or even 
non-certifed code in a TEE. All these are never 100% secure.

3.) You need an assumption to build your trust models on (aka provide 
the basis for decisions what to trust and what not to trust) and these 
assumption are made for RoT (trusting either the TPM and the TEE-TPM 
product that failed here was a decision).

4.) In a well-defined trust model, trust can be revoked. I am relatively 
sure that some entities will come to the conclusion not to trust the 
"TPM-Fails" anymore. In some given scopes those are not RoT anymore.

Having said all that. There are and will be secure TEE software, some of 
it CC-certified, some not, TPM in phyiscal form, as Firmware TPM, or as 
virtual TPM - and all of them will never be 100% secure all the time. I 
think everyone is agreeing that this is always true wrt everything security.

In consequence, that is not the point. You can either give up on 
security or work with the assumptions of RoT here. If you are not 
assuming and requiring any existing security-procedures as a basis - the 
whole point of remote attestation procedures would be moot, using... GNU 
keyrings would be moot :-) And I do not think that is the case.

Coming back to Andreas' comment, there is a point to the scope and 
isolation of trusted primitive functions/services provided by an 
isolated secure environment. The better the isolation/shielding, the 
better the external certification, and the better the level 
"immutability" of the primitive functions/services, the higher the level 
of assurance is. In average, sans the always reemerging timing 
side-channel attacks, of course :)

Viele Grüße,

Henk



On 14.11.19 11:11, Schönwälder, Jürgen wrote:
> I just read this morning about <http://tpm.fail/>.
> 
> /js
> 
> On Thu, Nov 14, 2019 at 09:46:04AM +0000, Fuchs, Andreas wrote:
>> 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
>>
>> _______________________________________________
>> RATS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rats
>