Messages in this thread | | | Date | Thu, 3 Aug 2023 20:53:44 -0700 | From | Dan Williams <> | Subject | Re: [PATCH 0/4] keys: Introduce a keys frontend for attestation reports |
| |
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.
The kernel could enforce that a nonce be provided by some convention, perhaps a user-type key of the same name as the tsm-type key.
That enforces that the payload is always combined with a nonce to discourage insecure practice building a system that just conveys a raw pub-key.
| |