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

[Huang, Kai]

On Wed, 2023-08-02 at 08:41 -0400, James Bottomley wrote:
> 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).

Thanks.

> 
> > > 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.
> 
> Well, no, the <new nonce> 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. 
> 

Based on my limit cryptography knowledge I guess you mean using attestation flow
for mutual authentication?  I was thinking we already have a TLS connection
established and attestation is to make sure the attesting party is truly the one
but not someone who is compromised.  Anyway thanks a lot for explaining!

> >