Received: by 2002:a05:6358:700f:b0:131:369:b2a3 with SMTP id 15csp930297rwo; Wed, 2 Aug 2023 06:26:36 -0700 (PDT) X-Google-Smtp-Source: APBJJlEkvLM3CghdibapjAnF/EAdtWtuTYMZmrvt+ijZkQEQ5h61Uvb8AyEJ+GPoC9+P5FwyR2xB X-Received: by 2002:a19:8c10:0:b0:4fb:8bab:48b6 with SMTP id o16-20020a198c10000000b004fb8bab48b6mr5167912lfd.52.1690982796264; Wed, 02 Aug 2023 06:26:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1690982796; cv=none; d=google.com; s=arc-20160816; b=krHk27XCTEu7HfsqZyI3IFrU0Ba8SNuCnM7nYm/bjkLOVwaTBKergbGV+Uxk40eIR9 qDcyqaCeX+qrpt6mw20UhlEhibyIB0Cu7OBw5ZD1agc2can8D0PmClpoxPtPvVZoOgHs rdbBICbSV/yUNNQ/B1ZA73rLDGIK0QeGaZI2jPVdtW/ePD7OWzDaOsw7o6ocpprfV2h3 3kNRTHL8f8pM1lKowVCaN89WiDAcRefinHmM253KB7iryWmr19IPV0m0MwB8VYKPVELT 9R9UwCM8RHs8ZyQ8orGBRbBrFlnQHJOqZvjwkwBjPszQVc0pB7W2G1ObqpHEUn/XEkWU YcvQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id:dkim-signature:dkim-signature; bh=jsaM6HphEzTy5Akf/kuiZEAZWway9RZlqLKRfHryTgo=; fh=f8nTrJaLJ3PsKWIESMVq5ed97yZ2SYEWdw5zCWLAz4g=; b=hKWwnZZxhlScX9xmxpCqZ/dbzOQ7f4ji0nbA98sDIWSViIUmBxlaChMTUZxdNtJUwt E+xOrxYjzRpcHMxVyZOWvb6Mj9lOrRpkwEPe0Mhw+Pyobm98QoMAcUn3d8BB7etpm8QR 3aWok/xV/KOS3yxyqUX8JSNtcubJ/hbcHe7Je2LQjjRQbs1qsbRLgJz0INM4uEcbZADw K3f4m7gJAe6s7M4sfq+dDcvw9M/vgVGpYxdsLSM6SXhR6PkIv+LWjMtgBa8NXTPHzXhn Jbq82X9y2QN9QF58l4mHP0DPwDXVF1DuNVbgN6ekt+DsCLNHszltKA/LLQMcPsYWEjoF furw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@hansenpartnership.com header.s=20151216 header.b=wYfpWYWZ; dkim=pass header.i=@hansenpartnership.com header.s=20151216 header.b=wYfpWYWZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=hansenpartnership.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id d11-20020aa7ce0b000000b00522d81b7ccbsi4105331edv.156.2023.08.02.06.26.10; Wed, 02 Aug 2023 06:26:36 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@hansenpartnership.com header.s=20151216 header.b=wYfpWYWZ; dkim=pass header.i=@hansenpartnership.com header.s=20151216 header.b=wYfpWYWZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=hansenpartnership.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234611AbjHBMnM (ORCPT + 99 others); Wed, 2 Aug 2023 08:43:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35180 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234587AbjHBMnK (ORCPT ); Wed, 2 Aug 2023 08:43:10 -0400 Received: from bedivere.hansenpartnership.com (bedivere.hansenpartnership.com [96.44.175.130]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C2C442722; Wed, 2 Aug 2023 05:42:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hansenpartnership.com; s=20151216; t=1690980111; bh=OVp9/5eXr90ixhPTEpgp22DDNgheas8aSJabvLl6ZBc=; h=Message-ID:Subject:From:To:Date:In-Reply-To:References:From; b=wYfpWYWZtLtDmi4p2IyLnx+xqeaHzaQudIjkJwIUIxiRaQpjrZ35/sbaEkKvH5Z+e 3Y5arjwM9mWrkKn95lfLoVubYX8mtVZf9aN+8yGEuEE4I7jg4QXYOvu5DvlvXgtZW8 02+KFkY9yagBAn+CTxacejwVEfCaAvbvVnvQBWCk= Received: from localhost (localhost [127.0.0.1]) by bedivere.hansenpartnership.com (Postfix) with ESMTP id C4E0A128006A; Wed, 2 Aug 2023 08:41:51 -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 JV7x_JQ4eBds; Wed, 2 Aug 2023 08:41:51 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hansenpartnership.com; s=20151216; t=1690980111; bh=OVp9/5eXr90ixhPTEpgp22DDNgheas8aSJabvLl6ZBc=; h=Message-ID:Subject:From:To:Date:In-Reply-To:References:From; b=wYfpWYWZtLtDmi4p2IyLnx+xqeaHzaQudIjkJwIUIxiRaQpjrZ35/sbaEkKvH5Z+e 3Y5arjwM9mWrkKn95lfLoVubYX8mtVZf9aN+8yGEuEE4I7jg4QXYOvu5DvlvXgtZW8 02+KFkY9yagBAn+CTxacejwVEfCaAvbvVnvQBWCk= 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 EECA01280255; Wed, 2 Aug 2023 08:41:49 -0400 (EDT) Message-ID: <5a76c56a10f6512d0613577a412d2644945dbe77.camel@HansenPartnership.com> Subject: Re: [PATCH 0/4] keys: Introduce a keys frontend for attestation reports From: James Bottomley To: "Huang, Kai" , "Williams, Dan J" , "dhowells@redhat.com" Cc: "sameo@rivosinc.com" , "jarkko@kernel.org" , "akpm@linux-foundation.org" , "gregkh@linuxfoundation.org" , "peterz@infradead.org" , "bp@alien8.de" , "linux-kernel@vger.kernel.org" , "sathyanarayanan.kuppuswamy@linux.intel.com" , "thomas.lendacky@amd.com" , "dionnaglaze@google.com" , "brijesh.singh@amd.com" , "keyrings@vger.kernel.org" , "x86@kernel.org" , "linux-coco@lists.linux.dev" Date: Wed, 02 Aug 2023 08:41:47 -0400 In-Reply-To: <070e2386c99137b59bea114032d22664dd7272f8.camel@intel.com> References: <169057265210.180586.7950140104251236598.stgit@dwillia2-xfh.jf.intel.com> <64c5ed6eb4ca1_a88b2942a@dwillia2-xfh.jf.intel.com.notmuch> <6dec442c64faf2fecd21bcc77e4a6350e88948b9.camel@intel.com> <55cec220f20c497925f46074fc70eeccccff61c9.camel@HansenPartnership.com> <070e2386c99137b59bea114032d22664dd7272f8.camel@intel.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.4 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_BLOCKED, SPF_HELO_PASS,SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2023-08-02 at 00:10 +0000, Huang, Kai wrote: > On Tue, 2023-08-01 at 08:30 -0400, James Bottomley wrote: > > On Tue, 2023-08-01 at 08:03 -0400, James Bottomley wrote: > > > On Tue, 2023-08-01 at 11:45 +0000, Huang, Kai wrote: > > > [...] > > > > > > > > Sorry perhaps a dumb question to ask: > > > > > > > > As it has been adequately put, the remote verifiable report > > > > normally contains a nonce.  For instance, it can be a per- > > > > session or per-request nonce from the remote verification > > > > service to the confidential VM.   > > > > > > > > IIUC, exposing attestation report via /sysfs means many > > > > processes (in the confidential VM) can potentially see the > > > > report and the nonce. My question is whether such nonce should > > > > be considered as a secret thus should be only visible to the > > > > process which is responsible for talking to the remote > > > > verification service?  > > > > Using IOCTL seems can avoid such exposure. > > > > > > OK, so the nonce seems to be a considerably misunderstood piece > > > of this (and not just by you), so I'll try to go over carefully > > > what it is and why.  The problem we have in pretty much any > > > signature based attestation evidence scheme is when I, the > > > attesting party, present the signed evidence to you, the relying > > > part, how do you know I got it today from the system in question > > > not five days ago when I happen to have engineered the correct > > > conditions?  The solution to this currency problem is to > > > incorporate a challenge supplied by the relying party (called a > > > nonce) into the signature.  The nonce must be unpredictable > > > enough that the attesting party can't guess it beforehand and it > > > must be unique so that the attesting party can't go through its > > > records and find an attestation signature with the same > > > nonce and supply that instead. > > > > > > This property of unpredictability and uniqueness is usually > > > satisfied simply by sending a random number.  However, as you can > > > also see, since the nonce is supplied by the relying party to the > > > attesting party, it eventually gets known to both, so can't be a > > > secret to one or the other.  Because of the unpredictability > > > requirement, it's generally frowned on to have nonces based on > > > anything other than random numbers, because that might lead to > > > predictability. > > Thanks for explaining! > > So in other words, in general nonce shouldn't be a secret due to it's > unpredictability, thus using /sysfs to expose attestation report > should be OK? There's no reason I can think of it should be secret (well, except security through obscurity in case someone is monitoring for a replay). > > I suppose there is a situation where you use the nonce to bind > > other details of the attesting party.  For instance, in > > confidential computing, the parties often exchange secrets after > > successful attestation.  To do this, the attesting party generates > > an ephemeral public key.  It then communicates the key binding by > > constructing a new nonce as > > > > = hash( || ) > > > > and using that new nonce in the attestation report signature. > > This looks like taking advantage of the attestation flow to carry > additional info that can be communicated _after_ attestation is done. Well, no, the must be part of the attestation report. >   Not sure the benefit?  For instance, shouldn't we normally use > symmetric key for exchanging secrets after attestation? Yes, but how do you get the symmetric key? A pre-chosen symmetric key would have to be in the enclave as an existing secret, which can't be done if you have to provision secrets. The way around this is to use a key agreement to generate a symmetric key on the fly. The problem, when you are doing things like Diffie Hellman Ephemeral (DHE) to give you this transport encryption key is that of endpoint verification. You can provision a public certificate in the enclave to verify the remote (so a malicious remote can't inject false secrets), but the remote needs some assurance that it has established communication with the correct local (otherwise it would give up its secrets to anyone). A binding of the local public DHE key to the attestation report can do this. > > So the relying party can also reconstruct the new nonce (if it > > knows the key) and verify that it has a current attestation report > > *and* that the attesting party wants secrets encrypted to > key>.  This scheme does rely on the fact that the thing generating > > the attestation signature must only send reports to the owner of > > the enclave, so that untrusted third parties, like the host owner, > > can't generate a report with their own nonce and thus fake out the > > key exchange. > > Sorry I am not sure I am following this. If you use an attestation report for binding, you have to be sure no third party could generate the report and give a false binding. For instance, this isn't true of a TPM2_Quote because anyone who can get into the tss group can generate one. James >   For TDX only the confidential VM can put the nonce to the report > (because the specific instruction to get the local-verifiable report > out from firmware can only be made from the confidential VM). > Not sure other vendors' implementations though. >