Re: [Rats] FIDO TPM attestation

Laurence Lundblade <lgl@island-resort.com> Fri, 15 November 2019 18:40 UTC

Return-Path: <lgl@island-resort.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 674C012008C for <rats@ietfa.amsl.com>; Fri, 15 Nov 2019 10:40:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level:
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 KrfRpC9skV0P for <rats@ietfa.amsl.com>; Fri, 15 Nov 2019 10:40:49 -0800 (PST)
Received: from p3plsmtpa08-05.prod.phx3.secureserver.net (p3plsmtpa08-05.prod.phx3.secureserver.net [173.201.193.106]) (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 9877C120013 for <rats@ietf.org>; Fri, 15 Nov 2019 10:40:49 -0800 (PST)
Received: from [10.141.0.74] ([45.56.150.139]) by :SMTPAUTH: with ESMTPA id VgWWiO3hrcNOHVgWWihbJT; Fri, 15 Nov 2019 11:40:48 -0700
From: Laurence Lundblade <lgl@island-resort.com>
Message-Id: <39F4565A-F807-4DB2-B024-6BD2BC906DC5@island-resort.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_8E29825C-74EC-4FBF-8239-800D8FF80298"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Fri, 15 Nov 2019 10:40:48 -0800
In-Reply-To: <9F48E1A823B03B4790B7E6E69430724D0163BD5B5C@EXCH2010B.sit.fraunhofer.de>
Cc: "rats@ietf.org" <rats@ietf.org>
To: "Fuchs, Andreas" <andreas.fuchs@sit.fraunhofer.de>
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>
X-Mailer: Apple Mail (2.3445.104.11)
X-CMAE-Envelope: MS4wfMqyTSBm/ho0gpp2waKH1K6Whl5Lrve/DiQyIpuQ5e4vV9AWTDWR0SE+gq7W1EyYt4g3D0YQndT87ARD7ltht1QnjqxebG916XlZiZ8QqvGxcTKZIYvr kNA3PMGvpgwDQ54Dz1zSKnR9XG0imimd/fikJ1ANyijqq8LM00ApP4by9UQAlgmqBOIVoatf8h0KbvdiDUyOvZZg/ZaylYecTW8=
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/OXZWLP2oYYliYQW3E8fjYJMeGt8>
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: Fri, 15 Nov 2019 18:40:52 -0000

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> 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