On Wed, 2023-08-02 at 08:41 -0400, James Bottomley wrote:

On Wed, 2023-08-02 at 00:10 +0000, Huang, Kai wrote:

quoted

On Tue, 2023-08-01 at 08:30 -0400, James Bottomley wrote:

quoted

On Tue, 2023-08-01 at 08:03 -0400, James Bottomley wrote:

quoted

On Tue, 2023-08-01 at 11:45 +0000, Huang, Kai wrote:
[...]

quoted

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.

quoted

quoted

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.

quoted

  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!

quoted