Re: [Rats] FIDO TPM attestation
Henk Birkholz <henk.birkholz@sit.fraunhofer.de> Thu, 14 November 2019 10:51 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 480B9120088 for <rats@ietfa.amsl.com>; Thu, 14 Nov 2019 02:51:42 -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 6EajSW9z9Qy4 for <rats@ietfa.amsl.com>; Thu, 14 Nov 2019 02:51:40 -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 C9A69120019 for <rats@ietf.org>; Thu, 14 Nov 2019 02:51:38 -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 xAEApZeZ014495 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Thu, 14 Nov 2019 11:51:36 +0100
Received: from [192.168.16.50] (79.234.112.245) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.468.0; Thu, 14 Nov 2019 11:51:30 +0100
To: "Schönwälder, Jürgen" <J.Schoenwaelder@jacobs-university.de>, "Fuchs, Andreas" <andreas.fuchs@sit.fraunhofer.de>
CC: "rats@ietf.org" <rats@ietf.org>, Laurence Lundblade <lgl@island-resort.com>
References: <62DD1AD3-6F1A-4B2B-8236-10ECCE254443@island-resort.com> <9F48E1A823B03B4790B7E6E69430724D0163BD29CD@EXCH2010B.sit.fraunhofer.de> <20191114101109.jap6uy3oahlusopz@anna.jacobs.jacobs-university.de>
From: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Message-ID: <3c66bb6b-3c53-18df-c9bb-08f88ab38d10@sit.fraunhofer.de>
Date: Thu, 14 Nov 2019 11:51:30 +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: <20191114101109.jap6uy3oahlusopz@anna.jacobs.jacobs-university.de>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: [79.234.112.245]
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/sFV3GsYBUSy3VVUZTWzG3FbJbvA>
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: Thu, 14 Nov 2019 10:51:42 -0000
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 On 14.11.19 11:11, Schönwälder, Jürgen wrote: > I just read this morning about <http://tpm.fail/>. > > /js > > On Thu, Nov 14, 2019 at 09:46:04AM +0000, Fuchs, Andreas wrote: >> 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 [rats-bounces@ietf.org] on behalf of Laurence Lundblade [lgl@island-resort.com] >> Sent: Wednesday, November 13, 2019 05:08 >> To: rats@ietf.org >> Subject: [Rats] FIDO TPM attestation >> >> 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 >> _______________________________________________ >> RATS mailing list >> RATS@ietf.org >> https://www.ietf.org/mailman/listinfo/rats >> >> _______________________________________________ >> 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