lkml.org 
[lkml]   [2023]   [Aug]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH 0/4] keys: Introduce a keys frontend for attestation reports
    Date
    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.

    \
     
     \ /
      Last update: 2023-08-02 02:11    [W:7.957 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site