Message-ID: <070e2386c99137b59bea114032d22664dd7272f8.camel@intel.com>
Date:   Wed, 2 Aug 2023 00:10:03 +0000
From:   "Huang, Kai" <kai.huang@...el.com>
To:     "Williams, Dan J" <dan.j.williams@...el.com>,
        "James.Bottomley@...senPartnership.com" 
        <James.Bottomley@...senPartnership.com>,
        "dhowells@...hat.com" <dhowells@...hat.com>
CC:     "sameo@...osinc.com" <sameo@...osinc.com>,
        "jarkko@...nel.org" <jarkko@...nel.org>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "bp@...en8.de" <bp@...en8.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "sathyanarayanan.kuppuswamy@...ux.intel.com" 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>,
        "thomas.lendacky@....com" <thomas.lendacky@....com>,
        "dionnaglaze@...gle.com" <dionnaglaze@...gle.com>,
        "brijesh.singh@....com" <brijesh.singh@....com>,
        "keyrings@...r.kernel.org" <keyrings@...r.kernel.org>,
        "x86@...nel.org" <x86@...nel.org>,
        "linux-coco@...ts.linux.dev" <linux-coco@...ts.linux.dev>
Subject: Re: [PATCH 0/4] keys: Introduce a keys frontend for attestation
 reports

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?

> 
> 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
> 
> <new nonce> = hash( <relying party nonce> || <public key> )
> 
> 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.  Not sure the
benefit?  For instance, shouldn't we normally use symmetric key for exchanging
secrets after attestation?

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

Powered by blists - more mailing lists