Re: [PATCH 0/4] keys: Introduce a keys frontend for attestation reports

[Huang, Kai]

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.