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 23:13:58 +0000 |
| |
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!
> >
| |