Re: [Rats] FIDO TPM attestation

[Henk Birkholz <[e-mail]>]

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).
> 
> 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 <[e-mail]> on behalf of Laurence Lundblade 
> <[e-mail]>
> *Date: *Friday, November 15, 2019 at 10:41 AM
> *To: *"Fuchs, Andreas" <[e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>
> *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
> 
> Don’t disagree with anything in your latest comment. :-)
> 
> LL
> 
> 
> 
>     On Nov 14, 2019, at 8:17 AM, Fuchs, Andreas
>     <[e-mail]
>     <mailto:[e-mail]>> wrote:
> 
>     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 [[e-mail]
>     <mailto:[e-mail]>]
>     *Sent:*Thursday, November 14, 2019 16:51
>     *To:*Fuchs, Andreas
>     *Cc:*[e-mail] <mailto:[e-mail]>
>     *Subject:*Re: [Rats] FIDO TPM attestation
> 
>         On Nov 14, 2019, at 1:46 AM, Fuchs, Andreas
>         <[e-mail]
>         <mailto:[e-mail]>> 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
> 
> 
> 
> 
> _______________________________________________
> RATS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats
>