linux-kernel - Re: [PATCH 0/4] keys: Introduce a keys frontend for attestation reports

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <64cc764848504_782a329438@dwillia2-xfh.jf.intel.com.notmuch>
Date:   Thu, 3 Aug 2023 20:53:44 -0700
From:   Dan Williams <dan.j.williams@...el.com>
To:     James Bottomley <James.Bottomley@...senpartnership.com>,
        "Huang, Kai" <kai.huang@...el.com>,
        "Williams, Dan J" <dan.j.williams@...el.com>,
        "dhowells@...hat.com" <dhowells@...hat.com>
CC:     "sameo@...osinc.com" <sameo@...osinc.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "jarkko@...nel.org" <jarkko@...nel.org>,
        "bp@...en8.de" <bp@...en8.de>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "sathyanarayanan.kuppuswamy@...ux.intel.com" 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>,
        "thomas.lendacky@....com" <thomas.lendacky@....com>,
        "dionnaglaze@...gle.com" <dionnaglaze@...gle.com>,
        "keyrings@...r.kernel.org" <keyrings@...r.kernel.org>,
        "brijesh.singh@....com" <brijesh.singh@....com>,
        "linux-coco@...ts.linux.dev" <linux-coco@...ts.linux.dev>,
        "x86@...nel.org" <x86@...nel.org>
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.