Subject: [Rats] FIDO TPM attestation

From: Laurence Lundblade <[email-masked]>
Date: Tue, 12 Nov 2019 20:08:52 -0800

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

---

From: "Fuchs, Andreas" <[email-masked]>
Date: Thu, 14 Nov 2019 09:46:04 +0000

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 [[email-masked]] on behalf of Laurence Lundblade [[email-masked]]
Sent: Wednesday, November 13, 2019 05:08
To: [email-masked]
Subject: [Rats] FIDO TPM attestation

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

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Thu, 14 Nov 2019 10:11:10 +0000

I just read this morning about <http://tpm.fail/>.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 14 Nov 2019 11:51:30 +0100

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

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 14 Nov 2019 07:51:08 -0800

> On Nov 14, 2019, at 1:46 AM, Fuchs, Andreas <[email-masked]> wrote:
> 
> The FIDO code running inside a TEE is not standardized (to the level of TPM) and most certainly not CC-evaluated.

That’s not true.

The FIDO L3 and L3+ Certification program <https://fidoalliance.org/certification/authenticator-certification-levels/authenticator-level-3/> is CC (Common Criteria) based (AVA_VAN.3 and AVA_VAN.4).  

Many FIDO authenticators run on secure elements which provides roughly equivalent security to a TPM, however since the full authenticator protocol runs on the turing-complete secure element the full FIDO protocol is secured, not just the key storage. Here’s one <https://www.yubico.com/products/yubikey-hardware/yubikey%20neo/>.

Global Platform offers a CC-based certification program for TEE’s <https://www.commoncriteriaportal.org/files/ppfiles/anssi-profil_PP-2014_01.pdf>. FIDO is working on a certification program that will make use of that.

BSI has published a CC-based protection profile for FIDO <https://www.commoncriteriaportal.org/files/ppfiles/pp0096a_pdf.pdf>.

Android Keystore’s now supports StrongBox <https://proandroiddev.com/android-keystore-what-is-the-difference-between-strongbox-and-hardware-backed-keys-4c276ea78fd0>, which puts the keys in a secure element.

Qualcomm’s Snapdragon mobile phone chip has a secure-element like subsystem <https://www.qualcomm.com/news/releases/2019/06/25/qualcomm-snapdragon-855-becomes-first-mobile-soc-receive-smart-card> (not the TEE) that is CC-certified.

TEE and TEE-like offerings are stronger than they used to be, particular by supporting memory encryption.

Turing complete security products come in a range of security levels all the way up the security level offered by a TPM. EAT implementations can be just as secure and certified as TPM attestation.

LL

---

From: "Fuchs, Andreas" <[email-masked]>
Date: Thu, 14 Nov 2019 16:17:56 +0000

We were talking about FIDO as one of many applications running in a TEE.
They rely on correctness of other TEE-apps and/or the TEE kernel
(or should I rather say TEE operating system). Thus a turing complete solution
(maybe even with loadable apps) and OS cannot be as secure as a special-purpose
functional logic security provider.

Also, by design an on-chip TEE offering cannot be as secure as a physically
separated chip that incorporates smartcard technologies. You also highlight
this by providing yubikey as example which is both; a separate SC-like chip
and fixed functional logic (similar to TPMs).

To conclude: fixed functional logic and separate chips have higher assurance
levels than turing-complete (loadable) areas of the main cpu.

And to your original point: TPMs are the preferred solution for attestation
in contrast to to a TEE-based approach, just as YubiKeys et al are preferred
for FIDO in contrast to a TEE-based approach.

________________________________
From: Laurence Lundblade [[email-masked]]
Sent: Thursday, November 14, 2019 16:51
To: Fuchs, Andreas
Cc: [email-masked]
Subject: Re: [Rats] FIDO TPM attestation

On Nov 14, 2019, at 1:46 AM, Fuchs, Andreas <[email-masked]<mailto:[email-masked]>> wrote:

That’s not true.

The FIDO L3 and L3+ Certification program<https://fidoalliance.org/certification/authenticator-certification-levels/authenticator-level-3/> is CC (Common Criteria) based (AVA_VAN.3 and AVA_VAN.4).

Many FIDO authenticators run on secure elements which provides roughly equivalent security to a TPM, however since the full authenticator protocol runs on the turing-complete secure element the full FIDO protocol is secured, not just the key storage. Here’s one<https://www.yubico.com/products/yubikey-hardware/yubikey%20neo/>.

Global Platform offers a CC-based certification program for TEE’s<https://www.commoncriteriaportal.org/files/ppfiles/anssi-profil_PP-2014_01.pdf>. FIDO is working on a certification program that will make use of that.

BSI has published a CC-based protection profile for FIDO<https://www.commoncriteriaportal.org/files/ppfiles/pp0096a_pdf.pdf>.

Android Keystore’s now supports StrongBox<https://proandroiddev.com/android-keystore-what-is-the-difference-between-strongbox-and-hardware-backed-keys-4c276ea78fd0>, which puts the keys in a secure element.

Qualcomm’s Snapdragon mobile phone chip has a secure-element like subsystem<https://www.qualcomm.com/news/releases/2019/06/25/qualcomm-snapdragon-855-becomes-first-mobile-soc-receive-smart-card> (not the TEE) that is CC-certified.

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 15 Nov 2019 10:40:48 -0800

Hi Andreas,

Here’s the frame up as I see it for EAT  and FIDO from most secure to least. I believe EAT implementations can eventually be as secure as a TPM and we want to design EAT so such high-security implementations will eventually be in the market.

Hardware-Only (No SW!)
EAT with a small number of claims (HW Version, HW OEM, boot / debug state, simple TPM-like measurement) is possible in pure HW. 
Pretty sure many TPMs are implemented in pure HW.
Certifiable to very high levels.
FIDO is too complex for pure HW.

Secure Element and similar
EAT with a lot of claims
Simpler FIDO implementations without biometrics.
Some may consider this less secure than pure HW because complexity is higher, but I don’t think there is an absolute rule here.
Pretty sure this can be CC certified at the same level as HW only.

Separate CPU
You can add a CPU like an Arm Cortex M3 to your circuit board or to your SoC. Some of off-the-shelf CPUs even have some HW defenses (the SC version of the M3). It can run some super simple SW, simpler than a secure element.
EAT with a lot of claims
Most all FIDO
I’d peg security and certifiability as somewhere between the secure element and the TEE depending on the HW design. Both can be pretty high.

TEE, SGX, VBS
EAT with a lot of claims
Most all FIDO
Usually cannot implement advanced HW chip defenses because these are a mode of super-fast large CPUs and these defense would slow them down to much and consume too much power.
Not certifiable at the same levels as the above, but still certifiable in pretty thorough ways like the CC-based GP TEE PP (link below)
SW complexity is a lot higher so either certification cost is higher or certification is less thorough

Don’t disagree with anything in your latest comment. :-)

LL

> On Nov 14, 2019, at 8:17 AM, Fuchs, Andreas <[email-masked]> wrote:
> 
> From: Laurence Lundblade [[email-masked] <mailto:[email-masked]>]
> Cc: [email-masked] <mailto:[email-masked]>
>> On Nov 14, 2019, at 1:46 AM, Fuchs, Andreas <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: "Smith, Ned" <[email-masked]>
Date: Sat, 16 Nov 2019 00:58:38 +0000

This thread illustrates the need for attestation. But also the need for provenance (of the attesting environment).

There are many ways to implement “security” that have different trustworthiness properties.

RATS claims definition might consider how best to express such properties. For example, if it is CC certified.

Attestation functionality (and nothing more?) ideally is held to the highest standards for correct implementation and design so that it can be trusted to report on the target of attestation.

If we refer to the “Attestation functionality” as the “attesting environment” and the target of attestation as the “attested environment” then RATS drafts can distinguish between which claims are “trusted” vs which claims are “attested” by a given endpoint.

Something like a vendor issued certificate (with embedded private key) is a way to provide provenance of the attesting environment and an opportunity to include trustworthiness claims (e.g. CC certified). These claims can be asserted by a vendor, by including them in something signed by the vendor (e.g. certificate, manifest). Given RATS WG has decided to wait to define claims for “attesting environments” – since they are claims asserted by vendors / manufacturers. Maybe that work isn’t a high priority.

In either case, it doesn’t make sense for RATS WG (outside of gaining technical context) to rationalize which technology is more/less secure. This is a policy decision applied by Verifiers and Relying Parties. RATS WG should think about what claims should be expressed and how best to instantiate them IMHO.

-Ned

From: RATS <[email-masked]> on behalf of Laurence Lundblade <[email-masked]>
Date: Friday, November 15, 2019 at 10:41 AM
To: "Fuchs, Andreas" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Rats] FIDO TPM attestation

Hi Andreas,

Hardware-Only (No SW!)
·         EAT with a small number of claims (HW Version, HW OEM, boot / debug state, simple TPM-like measurement) is possible in pure HW.
·         Pretty sure many TPMs are implemented in pure HW.
·         Certifiable to very high levels.
·         FIDO is too complex for pure HW.

Secure Element and similar
·         EAT with a lot of claims
·         Simpler FIDO implementations without biometrics.
·         Some may consider this less secure than pure HW because complexity is higher, but I don’t think there is an absolute rule here.
·         Pretty sure this can be CC certified at the same level as HW only.

Separate CPU
You can add a CPU like an Arm Cortex M3 to your circuit board or to your SoC. Some of off-the-shelf CPUs even have some HW defenses (the SC version of the M3). It can run some super simple SW, simpler than a secure element.
·         EAT with a lot of claims
·         Most all FIDO
·         I’d peg security and certifiability as somewhere between the secure element and the TEE depending on the HW design. Both can be pretty high.

TEE, SGX, VBS
·         EAT with a lot of claims
·         Most all FIDO
·         Usually cannot implement advanced HW chip defenses because these are a mode of super-fast large CPUs and these defense would slow them down to much and consume too much power.
·         Not certifiable at the same levels as the above, but still certifiable in pretty thorough ways like the CC-based GP TEE PP (link below)
·         SW complexity is a lot higher so either certification cost is higher or certification is less thorough

LL

On Nov 14, 2019, at 8:17 AM, Fuchs, Andreas <[email-masked]<mailto:[email-masked]>> wrote:

________________________________
From: Laurence Lundblade [[email-masked]<mailto:[email-masked]>]
Sent: Thursday, November 14, 2019 16:51
To: Fuchs, Andreas
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Rats] FIDO TPM attestation

That’s not true.

LL

---

From: Henk Birkholz <[email-masked]>
Date: Mon, 18 Nov 2019 07:45:27 +0100

iotdir hat on.

As maps are not multimaps it can be useful to do kinder these proposals:

1.) If a value is a primitive or simple type, just use that. Qualifiers 
are collapsed in claims. Results in computational explosion and a big 
increase in registered claims.

2.) If a value requires one ore more qualifiers aggregate these in an 
array of well-defined sequence.

3.) If there are "token-wide" applicable qualifiers, make them the root 
structure and bundle claims in corresponding sub-claim-sets.

4.) If there are various sets of of qualifying claims for each core EAT 
claim, enumerate these identifiers and create a composite of 3.) and 
4.): use an array - first item is the value to be qualified, the second 
item is either a) an array of indexes/labels of qualifiers or b) a 
sub-claim-set of qualifying claims for the claim to be qualified.

5.) If all qualifiers always apply to all claims in an EAT, add an 
"header" claim-set with appropriate map members (or a single claim with 
an array value including appropriate label/indexes) to the private part 
of the COSE header.

Sorry, if this sounds a bit complicated. It actually isn't. But 1-5 
highlights that there are a) various ways to approach this and b) that 
adding a selection of various qualifiers to each individual claim has to 
be well structured and requires thinking ahead.

Viele Grüße,

Henk

On 16.11.19 01:58, Smith, Ned wrote:
> This thread illustrates the need for attestation. But also the need for 
> provenance (of the attesting environment).
> 
> RATS claims definition might consider how best to express such 
> properties. For example, if it is CC certified.
> 
> Attestation functionality (and nothing more?) ideally is held to the 
> highest standards for correct implementation and design so that it can 
> be trusted to report on the target of attestation.
> 
> If we refer to the “Attestation functionality” as the “attesting 
> environment” and the target of attestation as the “attested environment” 
> then RATS drafts can distinguish between which claims are “trusted” vs 
> which claims are “attested” by a given endpoint.
> 
> Something like a vendor issued certificate (with embedded private key) 
> is a way to provide provenance of the attesting environment and an 
> opportunity to include trustworthiness claims (e.g. CC certified). These 
> claims can be asserted by a vendor, by including them in something 
> signed by the vendor (e.g. certificate, manifest). Given RATS WG has 
> decided to wait to define claims for “attesting environments” – since 
> they are claims asserted by vendors / manufacturers. Maybe that work 
> isn’t a high priority.
> 
> In either case, it doesn’t make sense for RATS WG (outside of gaining 
> technical context) to rationalize which technology is more/less secure. 
> This is a policy decision applied by Verifiers and Relying Parties. RATS 
> WG should think about what claims should be expressed and how best to 
> instantiate them IMHO.
> 
> -Ned
> 
> *From: *RATS <[email-masked]> on behalf of Laurence Lundblade 
> <[email-masked]>
> *Date: *Friday, November 15, 2019 at 10:41 AM
> *To: *"Fuchs, Andreas" <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *Re: [Rats] FIDO TPM attestation
> 
> Hi Andreas,
> 
> Here’s the frame up as I see it for EAT  and FIDO from most secure to 
> least. I believe EAT implementations can eventually be as secure as a 
> TPM and we want to design EAT so such high-security implementations will 
> eventually be in the market.
> 
> *Hardware-Only (No SW!)*
> 
> ·EAT with a small number of claims (HW Version, HW OEM, boot / debug 
> state, simple TPM-like measurement) is possible in pure HW.
> 
> ·Pretty sure many TPMs are implemented in pure HW.
> 
> ·Certifiable to very high levels.
> 
> ·FIDO is too complex for pure HW.
> 
> *Secure Element and similar*
> 
> ·EAT with a lot of claims
> 
> ·Simpler FIDO implementations without biometrics.
> 
> ·Some may consider this less secure than pure HW because complexity is 
> higher, but I don’t think there is an absolute rule here.
> 
> ·Pretty sure this can be CC certified at the same level as HW only.
> 
> *Separate CPU*
> 
> You can add a CPU like an Arm Cortex M3 to your circuit board or to your 
> SoC. Some of off-the-shelf CPUs even have some HW defenses (the SC 
> version of the M3). It can run some super simple SW, simpler than a 
> secure element.
> 
> ·EAT with a lot of claims
> 
> ·Most all FIDO
> 
> ·I’d peg security and certifiability as somewhere between the secure 
> element and the TEE depending on the HW design. Both can be pretty high.
> 
> *TEE, SGX, VBS*
> 
> ·EAT with a lot of claims
> 
> ·Most all FIDO
> 
> ·Usually cannot implement advanced HW chip defenses because these are a 
> mode of super-fast large CPUs and these defense would slow them down to 
> much and consume too much power.
> 
> ·Not certifiable at the same levels as the above, but still certifiable 
> in pretty thorough ways like the CC-based GP TEE PP (link below)
> 
> ·SW complexity is a lot higher so either certification cost is higher or 
> certification is less thorough
> 
>     On Nov 14, 2019, at 8:17 AM, Fuchs, Andreas
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
>     ------------------------------------------------------------------------
> 
>     *From:*Laurence Lundblade [[email-masked]
>     <mailto:[email-masked]>]
>     *Sent:*Thursday, November 14, 2019 16:51
>     *To:*Fuchs, Andreas
>     *Cc:[email-masked] <mailto:[email-masked]>
>     *Subject:*Re: [Rats] FIDO TPM attestation
> 
>         On Nov 14, 2019, at 1:46 AM, Fuchs, Andreas
>         <[email-masked]
>         <mailto:[email-masked]>> wrote:
> 
>         The FIDO code running inside a TEE is not standardized (to the
>         level of TPM) and most certainly not CC-evaluated.
> 
>     That’s not true.
> 
>         TheFIDO L3 and L3+ Certification program
>         <https://fidoalliance.org/certification/authenticator-certification-levels/authenticator-level-3/> is
>         CC (Common Criteria) based (AVA_VAN.3 and AVA_VAN.4).
> 
>         Many FIDO authenticators run on secure elements which provides
>         roughly equivalent security to a TPM, however since the full
>         authenticator protocol runs on the turing-complete secure
>         element the full FIDO protocol is secured, not just the key
>         storage. Here’s one
>         <https://www.yubico.com/products/yubikey-hardware/yubikey%20neo/>.
> 
>         Global Platform offers a CC-based certification program for
>         TEE’s
>         <https://www.commoncriteriaportal.org/files/ppfiles/anssi-profil_PP-2014_01.pdf>.
>         FIDO is working on a certification program that will make use of
>         that.
> 
>         BSI has published a CC-based protection profile for FIDO
>         <https://www.commoncriteriaportal.org/files/ppfiles/pp0096a_pdf.pdf>.
> 
>         Android Keystore’s now supports StrongBox
>         <https://proandroiddev.com/android-keystore-what-is-the-difference-between-strongbox-and-hardware-backed-keys-4c276ea78fd0>,
>         which puts the keys in a secure element.
> 
>         Qualcomm’s Snapdragon mobile phone chip has a secure-element
>         like subsystem
>         <https://www.qualcomm.com/news/releases/2019/06/25/qualcomm-snapdragon-855-becomes-first-mobile-soc-receive-smart-card> (not
>         the TEE) that is CC-certified.
> 
>         TEE and TEE-like offerings are stronger than they used to be,
>         particular by supporting memory encryption.
> 
>     Turing complete security products come in a range of security levels
>     all the way up the security level offered by a TPM. EAT
>     implementations can be just as secure and certified as TPM attestation.
> 
>     LL
> 
> 
> 
>

---

From: Henk Birkholz <[email-masked]>
Date: Mon, 18 Nov 2019 07:49:08 +0100

There should be "hints" (this a common and often used concept) that 
provide qualification to Attestation Evidence with respect to its 
intended protection. Policies should be able to decide how and why to 
rely on these protection hints, I think.

Hints could be implied by signature semantics, though. If not they 
should be made explicit.

Viele Grüße,

Henk

[..]