Re: [Rats] FIDO TPM attestation
Henk Birkholz <henk.birkholz@sit.fraunhofer.de> Mon, 18 November 2019 06:45 UTC
Return-Path: <henk.birkholz@sit.fraunhofer.de>
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 94FAB12089E for <rats@ietfa.amsl.com>; Sun, 17 Nov 2019 22:45:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 jxjkbIyR2gGX for <rats@ietfa.amsl.com>; Sun, 17 Nov 2019 22:45:43 -0800 (PST)
Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) (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 EF52F1200B3 for <rats@ietf.org>; Sun, 17 Nov 2019 22:45:41 -0800 (PST)
Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.15.2/8.15.2/Debian-10) with ESMTPS id xAI6jbxm001986 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Mon, 18 Nov 2019 07:45:38 +0100
Received: from [31.133.159.37] (31.133.159.37) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.468.0; Mon, 18 Nov 2019 07:45:32 +0100
To: "Smith, Ned" <ned.smith@intel.com>, Laurence Lundblade <lgl@island-resort.com>, "Fuchs, Andreas" <andreas.fuchs@sit.fraunhofer.de>
CC: "rats@ietf.org" <rats@ietf.org>
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> <DEEF16A1-0240-4713-9C39-7C590744493F@intel.com>
From: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Message-ID: <1412ac1d-29fd-38ef-c2b3-d8ff74d672af@sit.fraunhofer.de>
Date: Mon, 18 Nov 2019 07:45:27 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <DEEF16A1-0240-4713-9C39-7C590744493F@intel.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: [31.133.159.37]
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/_3sIA0I1lJ18Qxptr_RQX1dAGvI>
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: Mon, 18 Nov 2019 06:45:46 -0000
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 <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. > > 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 > RATS@ietf.org > https://www.ietf.org/mailman/listinfo/rats >
- [Rats] FIDO TPM attestation Laurence Lundblade
- Re: [Rats] FIDO TPM attestation Fuchs, Andreas
- Re: [Rats] FIDO TPM attestation Schönwälder
- Re: [Rats] FIDO TPM attestation Henk Birkholz
- Re: [Rats] FIDO TPM attestation Laurence Lundblade
- Re: [Rats] FIDO TPM attestation Fuchs, Andreas
- Re: [Rats] FIDO TPM attestation Laurence Lundblade
- Re: [Rats] FIDO TPM attestation Smith, Ned
- Re: [Rats] FIDO TPM attestation Henk Birkholz
- Re: [Rats] FIDO TPM attestation Henk Birkholz