Messages in this thread | | | From | "Huang, Kai" <> | Subject | Re: [PATCH 0/4] keys: Introduce a keys frontend for attestation reports | Date | Wed, 2 Aug 2023 00:10:03 +0000 |
| |
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.
| |