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;
Date:   Thu, 3 Aug 2023 20:53:44 -0700
From:   Dan Williams <dan.j.williams@intel.com>
To:     James Bottomley <James.Bottomley@hansenpartnership.com>,
        "Huang, Kai" <kai.huang@intel.com>,
        "Williams, Dan J" <dan.j.williams@intel.com>,
        "dhowells@redhat.com" <dhowells@redhat.com>
CC:     "sameo@rivosinc.com" <sameo@rivosinc.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "jarkko@kernel.org" <jarkko@kernel.org>,
        "bp@alien8.de" <bp@alien8.de>,
        "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
        "peterz@infradead.org" <peterz@infradead.org>,
        "akpm@linux-foundation.org" <akpm@linux-foundation.org>,
        "sathyanarayanan.kuppuswamy@linux.intel.com" 
        <sathyanarayanan.kuppuswamy@linux.intel.com>,
        "thomas.lendacky@amd.com" <thomas.lendacky@amd.com>,
        "dionnaglaze@google.com" <dionnaglaze@google.com>,
        "keyrings@vger.kernel.org" <keyrings@vger.kernel.org>,
        "brijesh.singh@amd.com" <brijesh.singh@amd.com>,
        "linux-coco@lists.linux.dev" <linux-coco@lists.linux.dev>,
        "x86@kernel.org" <x86@kernel.org>
Subject: Re: [PATCH 0/4] keys: Introduce a keys frontend for attestation
 reports
Message-ID: <64cc764848504_782a329438@dwillia2-xfh.jf.intel.com.notmuch>
References: <169057265210.180586.7950140104251236598.stgit@dwillia2-xfh.jf.intel.com>
 <a507ef3302d3afff58d82528ee17e82df1f21de0.camel@HansenPartnership.com>
 <64c5ed6eb4ca1_a88b2942a@dwillia2-xfh.jf.intel.com.notmuch>
 <c6576d1682b576ba47556478a98f397ed518a177.camel@HansenPartnership.com>
 <6dec442c64faf2fecd21bcc77e4a6350e88948b9.camel@intel.com>
 <55cec220f20c497925f46074fc70eeccccff61c9.camel@HansenPartnership.com>
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <55cec220f20c497925f46074fc70eeccccff61c9.camel@HansenPartnership.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?iso-8859-1?Q?S+N3EGxFAh/6gg4nnyRrZzDSxaPwMFsELnWQWFkvcwzXJ3aPl0sWfHSR7h?=
 =?iso-8859-1?Q?WCvPwNiYDNtv23gAUj2JKA3Ixc42cQlocpWMtahm4N4aoYugcN1KS2v3DR?=
 =?iso-8859-1?Q?RWrDCp9jLEQA5WP75vS+4YdV8fEnmeheoWaOsyR70GXwrnavvvZUstadLe?=
 =?iso-8859-1?Q?4aM5f/hAv/MvnbRwe15k4zMZaZLxD94JMn0szdBlS90sRy7q/SPYUAGzHx?=
 =?iso-8859-1?Q?YJke5JtKkbIp6keV1mw0D5gsHKVBz+rMJntq8CYrgGcEL4VJK4haXh00dg?=
 =?iso-8859-1?Q?RJARPBylcNz326+uovc94BE2G2ae/ZBabBX2fLgdCpePgwIxJkLkdfkFi0?=
 =?iso-8859-1?Q?ts07sF0Mk9eBXCDmot3wELuScbEU0NbJ2Ro13EEXE+r8sU8WJiF4mv18eV?=
 =?iso-8859-1?Q?xuPsT67aHub6GA4ShrOMVYOr62Ets5J4hYfctw/q87Th8Gg1ytahsDTuLc?=
 =?iso-8859-1?Q?P7s/N6rFKrPe6EtepyN31PEAaXxMOHgehjoQOdmz5/g+lTs0HGrgGEdfBK?=
 =?iso-8859-1?Q?iI0zjtMhLgUV8umgyEpV+q8tjpks5D3DpYYe8/hLGPWud1I29X03iF+AwZ?=
 =?iso-8859-1?Q?fFR+MLFUIZN/XfA8mMhFy2/rQv6kWMfA9JslkoDORLZPAOWUBDClCwFXwy?=
 =?iso-8859-1?Q?tmS2oH8kITZ3h+rP6TU4NOoG5GfMOhtneqLhH11yw2mLErvAZ1/OJYf1b/?=
 =?iso-8859-1?Q?b0cSX0m0e++uWcLU5yJ1xBLoRZR4F98CIJ9ga9YhgZdU3B0pMoqhxRpqBu?=
 =?iso-8859-1?Q?qIxX4HaL0iDa8q8IXq5H/Vl1auUawg2ZPcUoJkzPslqs7T9R7H1tHSGLvC?=
 =?iso-8859-1?Q?xkoYtRRTo+EWcrHK8mr2s1/Y7hX0h7Ud6QwphdTBbfeNx3JGq+kns5qILM?=
 =?iso-8859-1?Q?+NxLOhPNtxhMBC/h+07amXDUfn24jcMzafZKPet0QurCiT4ZtHOUkOwYQ1?=
 =?iso-8859-1?Q?r2ygOdtthuaRO50of6udIdoxbBvxYukyA2xBN3v5U57+wp/sOgGFZaKPNO?=
 =?iso-8859-1?Q?0Mq1qI1HY1VeukgPkF6d6K7BySwlSLyXsQwc/ZxtBj0kc27lzdk50uyk+O?=
 =?iso-8859-1?Q?sO3rD4U9y7/pPinDe9dsa5hlAUYlQwjXbiH4JROK83POiTt/+S25jP2t3H?=
 =?iso-8859-1?Q?OxBpBjWZvfCrnCLCOSP91x/8IFMG8vmN9LPq7+jHIoJ56nf1We8p6UXQT0?=
 =?iso-8859-1?Q?mars4gsJPk7ilLgD2HBCgl5nvYC5sYMqrbvUls+KHiXZ7GvQJbHMl8VseE?=
 =?iso-8859-1?Q?E9Zraixvyij3Jc3ZIEBHXZbKB1DJHFbmvegMwy8tavxbpX0N/0RVvF6hXA?=
 =?iso-8859-1?Q?+5+sbcQ2tLmHgWu4ANK6J5aSiLNwFzEDU2HsTNKihsH8x4Xj+Yjt7uPxDK?=
 =?iso-8859-1?Q?XJ0j3DqGLYl3A6gPO+j0Hkb9tXrF7jfF0vEI4U9vHX7EWod4cslIC/Xdci?=
 =?iso-8859-1?Q?FN623p6TV9uzhxlmE4CpEGkm3r+wC8g/XIlavpLLGXl+ItjSfuNc3XGBrI?=
 =?iso-8859-1?Q?g8N4YGfu2GwUZyLOqEUmbKWiVexb7aCU7os0iRtFRRhhXEz62IY8LXOQnf?=
 =?iso-8859-1?Q?Ghey+UqfFtrq9EEE8pLY+mQwas6T652XrxeOiI5PzPdJm7dT9z197qNA5K?=
 =?iso-8859-1?Q?0eqToYZ0xBdtHfb9tXw6iclgWgPTbkAu4J3JwnZqwxrPIp8id9vk62kQ?=
 =?iso-8859-1?Q?=3D=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 11180427-b3ec-46b7-e92d-08db949e67fc
X-MS-Exchange-CrossTenant-AuthSource: PH8PR11MB8107.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Aug 2023 03:53:47.4937
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: U0WP1SI6n3B5kJQcg+o8GofvB3IPX6U2DrUAxYmTETGuJRVSctkcVCKyJwGq2cT74d1eVEXLmYmCIaG/jUPOWBKMlxHr4Co1cCVbyvoxYMk=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR11MB7626
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,
        RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,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: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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.

The kernel could enforce that a nonce be provided by some convention,
perhaps a user-type key of the same name as the tsm-type key.

That enforces that the payload is always combined with a nonce to
discourage insecure practice building a system that just conveys a raw
pub-key.