From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bedivere.hansenpartnership.com (bedivere.hansenpartnership.com [96.44.175.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0D815168A7 for ; Tue, 8 Aug 2023 19:37:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hansenpartnership.com; s=20151216; t=1691523476; bh=iWclFeWz6A/OZCUv6T7u98I9B1XbWJNfa3WMgB4bmP8=; h=Message-ID:Subject:From:To:Date:In-Reply-To:References:From; b=SXPWdVIe45JNSw71kqC/YZLMVTuHJjsPw+oKv/wEA0hU7MXzoEy2Q4zyDV/6G1GJd 6/fGwEmXHXJQ223OJLqmn9N7qC/ZQEZaN/MFHYjTNxuzjveCCeo6aZz84iLE+H3oP4 IaEn50JFxj3NTRZWS8wRDy5EojKopwgy9dyG+UG0= Received: from localhost (localhost [127.0.0.1]) by bedivere.hansenpartnership.com (Postfix) with ESMTP id 995E212868AE; Tue, 8 Aug 2023 15:37:56 -0400 (EDT) Received: from bedivere.hansenpartnership.com ([127.0.0.1]) by localhost (bedivere.hansenpartnership.com [127.0.0.1]) (amavis, port 10024) with ESMTP id 6GipOO7im5oG; Tue, 8 Aug 2023 15:37:56 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hansenpartnership.com; s=20151216; t=1691523476; bh=iWclFeWz6A/OZCUv6T7u98I9B1XbWJNfa3WMgB4bmP8=; h=Message-ID:Subject:From:To:Date:In-Reply-To:References:From; b=SXPWdVIe45JNSw71kqC/YZLMVTuHJjsPw+oKv/wEA0hU7MXzoEy2Q4zyDV/6G1GJd 6/fGwEmXHXJQ223OJLqmn9N7qC/ZQEZaN/MFHYjTNxuzjveCCeo6aZz84iLE+H3oP4 IaEn50JFxj3NTRZWS8wRDy5EojKopwgy9dyG+UG0= Received: from lingrow.int.hansenpartnership.com (unknown [IPv6:2601:5c4:4302:c21::c14]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by bedivere.hansenpartnership.com (Postfix) with ESMTPSA id 30A121286887; Tue, 8 Aug 2023 15:37:55 -0400 (EDT) Message-ID: <9c9c62f9243595a1faa3b0745fa8a1f8f018d9b8.camel@HansenPartnership.com> Subject: Re: [PATCH 0/4] keys: Introduce a keys frontend for attestation reports From: James Bottomley To: Dionna Amalie Glaze Cc: Dan Williams , Sathyanarayanan Kuppuswamy , dhowells@redhat.com, Brijesh Singh , Peter Zijlstra , Tom Lendacky , Borislav Petkov , Jarkko Sakkinen , Samuel Ortiz , Greg Kroah-Hartman , Andrew Morton , linux-coco@lists.linux.dev, keyrings@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org Date: Tue, 08 Aug 2023 15:37:53 -0400 In-Reply-To: References: <169057265210.180586.7950140104251236598.stgit@dwillia2-xfh.jf.intel.com> <64c5ed6eb4ca1_a88b2942a@dwillia2-xfh.jf.intel.com.notmuch> <64cdb5f25c56_2138e294f1@dwillia2-xfh.jf.intel.com.notmuch> <1180481830431165d49c5e64b92b81c396ebc9b1.camel@HansenPartnership.com> <64d17f5728fbc_5ea6e2943f@dwillia2-xfh.jf.intel.com.notmuch> <2425e00b-defb-c12b-03e5-c3d23b30be01@linux.intel.com> <64d263e44e401_2138e29486@dwillia2-xfh.jf.intel.com.notmuch> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.4 Precedence: bulk X-Mailing-List: linux-coco@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit On Tue, 2023-08-08 at 11:48 -0700, Dionna Amalie Glaze wrote: > > Isn't this more runtime attestation?  In which case you wouldn't > > use the boot report.  I assume someone somewhere is hacking the > > TPM-TLS protocol to also do RTMRs, but it strikes me we could just > > use a vTPM and the existing protocols. > > > > Even if you don't do anything as complex as TPM-TLS (and continuing > > runtime attestation), you can still make TLS conditioned on a > > private key released after a successful boot time attestation.  > > Since the boot evidence never changes, there's not much point doing > > it on each connection, so relying on a private key conditioned on > > boot evidence is just as good. > > > > James > > > > The TPM quote will need to be bound to the VM instance, so there will > still be a hardware attestation in there that incorporates the user's > challenge. Well, it's all in the protocol: A TLS-TPM system using a physical TPM has to do an EK/AK makecredential/activatecredential to verify it's talking to a real TPM. In the CC vTPM case that step is substituted by doing a vTPM attestation. However, the point is in each case the verification step is only done once before you trust the TPM. After that, it's the TPM key you trust because the proof, in either case, was that the key is TPM generated and the TPM should be tamper proof (enforced by the casing for a physical TPM and the situation in the VMPL or other software protection for the vTPM). > Anything less than that is subject to replay attacks, no? Am I > missing a clever trick? Trusting the vTPM is a one time thing. Once trust in the TPM is established, you don't need to be worried about replay and you can just use standard TPM primitives for everything onward, even when doing point in time runtime attestation. James