Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Message-ID: <1575342724.24227.41.camel@linux.ibm.com>
Subject: Re: One question about trusted key of keyring in Linux kernel.
From:   James Bottomley <jejb@linux.ibm.com>
To:     "Zhao, Shirley" <shirley.zhao@intel.com>,
        Mimi Zohar <zohar@linux.ibm.com>,
        Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
        Jonathan Corbet <corbet@lwn.net>
Cc:     "linux-integrity@vger.kernel.org" <linux-integrity@vger.kernel.org>,
        "keyrings@vger.kernel.org" <keyrings@vger.kernel.org>,
        "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "'Mauro Carvalho Chehab'" <mchehab+samsung@kernel.org>,
        "Zhu, Bing" <bing.zhu@intel.com>,
        "Chen, Luhai" <luhai.chen@intel.com>
Date:   Mon, 02 Dec 2019 19:12:04 -0800
In-Reply-To: <A888B25CD99C1141B7C254171A953E8E4909E62E@shsmsx102.ccr.corp.intel.com>
References: <A888B25CD99C1141B7C254171A953E8E49094313@shsmsx102.ccr.corp.intel.com>
         <1573659978.17949.83.camel@linux.ibm.com>
         <A888B25CD99C1141B7C254171A953E8E49095F9B@shsmsx102.ccr.corp.intel.com>
         <1574877977.3551.5.camel@linux.ibm.com>
         <A888B25CD99C1141B7C254171A953E8E49096521@shsmsx102.ccr.corp.intel.com>
         <1575057916.6220.7.camel@linux.ibm.com>
         <A888B25CD99C1141B7C254171A953E8E4909BA3B@shsmsx102.ccr.corp.intel.com>
         <1575260220.4080.17.camel@linux.ibm.com>
         <A888B25CD99C1141B7C254171A953E8E4909D360@shsmsx102.ccr.corp.intel.com>
         <1575267453.4080.26.camel@linux.ibm.com>
         <A888B25CD99C1141B7C254171A953E8E4909E381@shsmsx102.ccr.corp.intel.com>
         <1575269075.4080.31.camel@linux.ibm.com>
         <A888B25CD99C1141B7C254171A953E8E4909E399@shsmsx102.ccr.corp.intel.com>
         <1575312932.24227.13.camel@linux.ibm.com>
         <A888B25CD99C1141B7C254171A953E8E4909E62E@shsmsx102.ccr.corp.intel.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, 2019-12-03 at 02:11 +0000, Zhao, Shirley wrote:
> Thanks so much for you feedback, James. 
> And glad to hear that the API will be made more friendly. 
> 
> But I have a little confused about the call stack. 
> From the document, https://github.com/torvalds/linux/blob/master/Docu
> mentation/security/keys/trusted-encrypted.rst and 
> https://github.com/zfsonlinux/dracut/tree/master/modules.d/97masterke
> y, the trusted key is a random number and generated by TPM2.0 and
> sealed with TPM2.0 2048 RSA key. 

Well, um, that document seems to be based on TPM 1.2 ... a lot of what
it says isn't quite true for TPM 2.0.  For instance all TPM 2.0 primary
keys come with a symmetric component, so the sealed data in TPM 2.0 is
actually symmetrically encrypted to a primary key.

> The 2048 RSA key is generated by tpm2_createprimary, and it can be
> got by the TPM2.0 handle, just the "keyhandle" used in the following
> keyctl command. 
> $ keyctl add trusted kmk "new 32 keyhandle=0x81000001 hash=sha256
> policydigest=`cat pcr7.policy`" @u

The problem TPM 2.0 has is that most of them can't generate prime
numbers very fast, so even through the kernel could generate the RSA
primary, it would usually take far too long, so if you want to use a
RSA primary you have to pre-generate one and place it in NV storage;
the TCG recommends doing this at handle 81000001, which is what you
have above.  However, the more modern way is to derive an elliptic
curve key primary key every time ... EC keys can be generated by most
TPMs in 10s of milliseconds, so the primary doesn't need to be present
in NVRAM.

THe kernel should be using the EC primary method for the parent.  The
only exception is when the key has an intermediate parent, and then it
can be simply loaded from a file.

> If reboot, to re-load the trusted key back to keyring, just call
> tpm2_unseal is enough, don't need to call tpm2_load to load the
> TPM2.0 2048 RSA key.
> If the trusted key is also protected by policy, then the policy will
> be checked during tpm2_unseal. 
> 
> After check the source code, the call stack is mostly like: 
> SYSCALL_DEFINE5(add_key,...) --> key_create_or_update() -->
> __key_instantiate_and_link() -->  trusted_instantiate() -->
> tpm2_unseal_trusted() --> tpm2_unseal_cmd().

Well, the API is confusing, but the code seems to imply the parent
should be present somehow.  A key in NVRAM, like 81000001 is always
present so it doesn't need to be loaded it can just be used as is.

> Another problem here is, to build the policy to unseal the key, it
> need to start an policy session, and transfer the session handle to
> TPM2.0 unseal command. 
> In my keyctl command, I use tpm2.0 command to start the session and
> get the handle, put it into the keyctl command like:
> keyctl add trusted kmk "load `cat kmk.blob` keyhandle=0x81000001
> policyhandle=0x3000000" @u

As I said, using policy handles simply won't scale, so we need to use
the actual policy instead ... thus the policy should be passed into the
kernel  as part of the trusted key and the kernel itself would generate
a policy session from the policy statements ... this approach is aready
proven to be useful and functional in the tpm2 openssl engine code.

James