From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: "Huang, Kai" <kai.huang@intel.com>,
"Williams, Dan J" <dan.j.williams@intel.com>,
"dhowells@redhat.com" <dhowells@redhat.com>
Cc: "sameo@rivosinc.com" <sameo@rivosinc.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"jarkko@kernel.org" <jarkko@kernel.org>,
"bp@alien8.de" <bp@alien8.de>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
"peterz@infradead.org" <peterz@infradead.org>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"sathyanarayanan.kuppuswamy@linux.intel.com"
<sathyanarayanan.kuppuswamy@linux.intel.com>,
"thomas.lendacky@amd.com" <thomas.lendacky@amd.com>,
"dionnaglaze@google.com" <dionnaglaze@google.com>,
"keyrings@vger.kernel.org" <keyrings@vger.kernel.org>,
"brijesh.singh@amd.com" <brijesh.singh@amd.com>,
"linux-coco@lists.linux.dev" <linux-coco@lists.linux.dev>,
"x86@kernel.org" <x86@kernel.org>
Subject: Re: [PATCH 0/4] keys: Introduce a keys frontend for attestation reports
Date: Tue, 01 Aug 2023 08:03:47 -0400 [thread overview]
Message-ID: <55cec220f20c497925f46074fc70eeccccff61c9.camel@HansenPartnership.com> (raw)
In-Reply-To: <6dec442c64faf2fecd21bcc77e4a6350e88948b9.camel@intel.com>
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.
James
next prev parent reply other threads:[~2023-08-01 12:04 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-28 19:30 [PATCH 0/4] keys: Introduce a keys frontend for attestation reports Dan Williams
2023-07-28 19:30 ` [PATCH 1/4] keys: Introduce tsm keys Dan Williams
2023-07-28 19:40 ` Jarkko Sakkinen
2023-07-31 16:33 ` Peter Gonda
2023-07-31 17:48 ` Dan Williams
2023-07-31 18:14 ` Peter Gonda
2023-07-31 18:41 ` Dan Williams
2023-07-31 19:09 ` Dionna Amalie Glaze
2023-07-31 20:10 ` Dan Williams
2023-08-04 16:34 ` Peter Gonda
2023-08-04 22:24 ` Dan Williams
2023-08-05 5:11 ` Dan Williams
2023-08-01 18:01 ` Jarkko Sakkinen
2023-08-04 2:40 ` Dan Williams
2023-08-04 16:37 ` Dionna Amalie Glaze
2023-08-04 16:46 ` James Bottomley
2023-08-04 17:07 ` Dionna Amalie Glaze
2023-08-04 17:12 ` James Bottomley
2023-07-28 19:31 ` [PATCH 2/4] virt: sevguest: Prep for kernel internal {get, get_ext}_report() Dan Williams
2023-07-28 19:31 ` [PATCH 3/4] mm/slab: Add __free() support for kvfree Dan Williams
2023-07-28 19:31 ` [PATCH 4/4] virt: sevguest: Add TSM key support for SNP_{GET, GET_EXT}_REPORT Dan Williams
2023-07-31 16:45 ` Peter Gonda
2023-07-31 18:05 ` Dan Williams
2023-07-31 18:28 ` Peter Gonda
2023-07-28 19:34 ` [PATCH 0/4] keys: Introduce a keys frontend for attestation reports Jarkko Sakkinen
2023-07-28 19:44 ` Dan Williams
2023-07-31 10:09 ` Jarkko Sakkinen
2023-07-31 17:33 ` Dan Williams
2023-07-31 22:41 ` Huang, Kai
2023-08-01 18:48 ` Jarkko Sakkinen
2023-07-29 18:17 ` James Bottomley
2023-07-30 4:56 ` Dan Williams
2023-07-30 12:59 ` James Bottomley
2023-07-31 17:24 ` Dan Williams
2023-08-01 11:45 ` Huang, Kai
2023-08-01 12:03 ` James Bottomley [this message]
2023-08-01 12:30 ` James Bottomley
2023-08-02 0:10 ` Huang, Kai
2023-08-02 12:41 ` James Bottomley
2023-08-02 23:13 ` Huang, Kai
2023-08-04 3:53 ` Dan Williams
2023-08-04 2:22 ` Dan Williams
2023-08-04 16:19 ` Daniel P. Berrangé
2023-08-04 21:49 ` Huang, Kai
2023-08-05 11:05 ` James Bottomley
2023-08-05 2:37 ` Dan Williams
2023-08-05 13:30 ` James Bottomley
2023-08-07 23:33 ` Dan Williams
2023-08-08 14:19 ` James Bottomley
2023-08-08 14:53 ` Peter Gonda
2023-08-08 14:54 ` Sathyanarayanan Kuppuswamy
2023-08-08 15:48 ` Dan Williams
2023-08-08 16:07 ` Dionna Amalie Glaze
2023-08-08 16:43 ` Dan Williams
2023-08-08 17:21 ` Dionna Amalie Glaze
2023-08-08 18:17 ` Dan Williams
2023-08-08 23:32 ` Huang, Kai
2023-08-09 3:27 ` Dan Williams
2023-08-09 16:14 ` Peter Gonda
2023-08-08 18:16 ` James Bottomley
2023-08-08 18:48 ` Dionna Amalie Glaze
2023-08-08 19:37 ` James Bottomley
2023-08-08 20:04 ` Dionna Amalie Glaze
2023-08-08 21:46 ` James Bottomley
2023-08-08 22:33 ` Dionna Amalie Glaze
2023-08-08 15:14 ` Dan Williams
2023-08-10 14:50 ` Jarkko Sakkinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55cec220f20c497925f46074fc70eeccccff61c9.camel@HansenPartnership.com \
--to=james.bottomley@hansenpartnership.com \
--cc=akpm@linux-foundation.org \
--cc=bp@alien8.de \
--cc=brijesh.singh@amd.com \
--cc=dan.j.williams@intel.com \
--cc=dhowells@redhat.com \
--cc=dionnaglaze@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=jarkko@kernel.org \
--cc=kai.huang@intel.com \
--cc=keyrings@vger.kernel.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=sameo@rivosinc.com \
--cc=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=thomas.lendacky@amd.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).