Re: [Rats] FIDO TPM attestation

"Smith, Ned" <ned.smith@intel.com> Sat, 16 November 2019 00:58 UTC

Return-Path: <ned.smith@intel.com>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E372120088 for <rats@ietfa.amsl.com>; Fri, 15 Nov 2019 16:58:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhPkot_eF084 for <rats@ietfa.amsl.com>; Fri, 15 Nov 2019 16:58:44 -0800 (PST)
Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92D55120052 for <rats@ietf.org>; Fri, 15 Nov 2019 16:58:40 -0800 (PST)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Nov 2019 16:58:39 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.68,310,1569308400"; d="scan'208,217";a="208574469"
Received: from orsmsx102.amr.corp.intel.com ([10.22.225.129]) by orsmga006.jf.intel.com with ESMTP; 15 Nov 2019 16:58:39 -0800
Received: from orsmsx124.amr.corp.intel.com (10.22.240.120) by ORSMSX102.amr.corp.intel.com (10.22.225.129) with Microsoft SMTP Server (TLS) id 14.3.439.0; Fri, 15 Nov 2019 16:58:39 -0800
Received: from orsmsx109.amr.corp.intel.com ([169.254.11.161]) by ORSMSX124.amr.corp.intel.com ([169.254.2.83]) with mapi id 14.03.0439.000; Fri, 15 Nov 2019 16:58:39 -0800
From: "Smith, Ned" <ned.smith@intel.com>
To: Laurence Lundblade <lgl@island-resort.com>, "Fuchs, Andreas" <andreas.fuchs@sit.fraunhofer.de>
CC: "rats@ietf.org" <rats@ietf.org>
Thread-Topic: [Rats] FIDO TPM attestation
Thread-Index: AQHVmdgWfl9UYBF/L0GX4QO5u8BdHaeK8xUAgABl/wCAAAd9AIABukAA///jdAA=
Date: Sat, 16 Nov 2019 00:58:38 +0000
Message-ID: <DEEF16A1-0240-4713-9C39-7C590744493F@intel.com>
References: <62DD1AD3-6F1A-4B2B-8236-10ECCE254443@island-resort.com> <9F48E1A823B03B4790B7E6E69430724D0163BD29CD@EXCH2010B.sit.fraunhofer.de> <CEB0F75D-E703-41B9-8EEE-C95E848FBC8C@island-resort.com> <9F48E1A823B03B4790B7E6E69430724D0163BD5B5C@EXCH2010B.sit.fraunhofer.de> <39F4565A-F807-4DB2-B024-6BD2BC906DC5@island-resort.com>
In-Reply-To: <39F4565A-F807-4DB2-B024-6BD2BC906DC5@island-resort.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1f.0.191110
x-originating-ip: [10.24.10.107]
Content-Type: multipart/alternative; boundary="_000_DEEF16A1024047139C397C590744493Fintelcom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/WVO3hPWNOGmIjX-hV8wa8k1pZKw>
Subject: Re: [Rats] FIDO TPM attestation
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote Attestation Procedures <rats.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rats>, <mailto:rats-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats/>
List-Post: <mailto:rats@ietf.org>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rats>, <mailto:rats-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 16 Nov 2019 00:58:47 -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 <rats-bounces@ietf.org> on behalf of Laurence Lundblade <lgl@island-resort.com>
Date: Friday, November 15, 2019 at 10:41 AM
To: "Fuchs, Andreas" <andreas.fuchs@sit.fraunhofer.de>
Cc: "rats@ietf.org" <rats@ietf.org>
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 <andreas.fuchs@sit.fraunhofer.de<mailto:andreas.fuchs@sit.fraunhofer.de>> 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 [lgl@island-resort.com<mailto:lgl@island-resort.com>]
Sent: Thursday, November 14, 2019 16:51
To: Fuchs, Andreas
Cc: rats@ietf.org<mailto:rats@ietf.org>
Subject: Re: [Rats] FIDO TPM attestation

On Nov 14, 2019, at 1:46 AM, Fuchs, Andreas <andreas.fuchs@sit.fraunhofer.de<mailto:andreas.fuchs@sit.fraunhofer.de>> 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