Re: One question about trusted key of keyring in Linux kernel.

Re: One question about trusted key of keyring in Linux kernel.

[Mimi Zohar]

On Wed, 2019-11-13 at 01:22 +0000, Zhao, Shirley wrote:
> Hi, all,
> 
> This is Shirley from Intel. I have one question about trusted key of
> keyring in kernel. Please help.
> 
> According the to description in https://github.com/torvalds/linux/bl
> ob/master/Documentation/security/keys/trusted-encrypted.rst.
> Trusted key will be saved in TPM with PCR policy protected.

"Trusted Keys use a TPM both to generate and to seal the keys. Keys
are sealed under a 2048 bit RSA key in the TPM, ..."

Trusted keys are not TPM keys.  They are not stored in the TPM.

> 
> Then, I running the following command to create a trusted key.
> keyctl add trusted test_trusted "new 32 keyhandle=0x81000001" @u
> 
> I also tried the following command, it can add one trusted key, too.
> keyctl add trusted test_trusted "new 32 keyhandle=0x81000001
> pcrinfo=`cat pcr7.blob`" @u
> 
> But after reboot, this key will be removed.
> I need to re-added during boot.

Right, they need to be re-loaded on boot.  Refer to the dracut
module /modules.d/97masterkey for loading a trusted key during boot.

> 
> Then the question is since this key is saved in TPM, how to get it
> back from TPM?

Trusted keys are not stored in the TPM.  Refer to the ima-evm-utils
README for examples of creating a trusted key (kmk) and an encrypted
key (evm-key).

> 
> From the document, I need to use "keyctl pipe" to save the key into
> a blob, then load it.
> But the blob contend key text, and this is a file on hard disk, it
> is not safe to protect the key.
> 
> So what can TPM do here?

The hex ascii encoded trusted key is sealed under the TPM SRK.

Mimi

Re: One question about trusted key of keyring in Linux kernel.

[Jarkko Sakkinen]

On Wed, Nov 13, 2019 at 01:22:24AM +0000, Zhao, Shirley wrote:
>    Hi, all,
> 
>     
> 
>    This is Shirley from Intel. I have one question about trusted key of
>    keyring in kernel. Please help.

Please read "email etiquete" from

  https://kernelnewbies.org/PatchCulture

Thank you.

/Jarkko

RE: One question about trusted key of keyring in Linux kernel.

[Zhao, Shirley]

Thanks for your feedback, Mimi. 
But the document of dracut can't solve my problem. 

I did more test these days and try to descript my question in more detail. 

In my scenario, the trusted key will be sealed into TPM with PCR policy. 
And there are some related options in manual like 
       hash=         hash algorithm name as a string. For TPM 1.x the only
                     allowed value is sha1. For TPM 2.x the allowed values
                     are sha1, sha256, sha384, sha512 and sm3-256.
       policydigest= digest for the authorization policy. must be calculated
                     with the same hash algorithm as specified by the 'hash='
                     option.
       policyhandle= handle to an authorization policy session that defines the
                     same policy and with the same hash algorithm as was used to
                     seal the key. 

Here is my test step. 
Firstly, the pcr policy is generated as below: 
$ tpm2_createpolicy --policy-pcr --pcr-list sha256:7 --policy pcr7_bin.policy > pcr7.policy

Pcr7.policy is the ascii hex of policy:
$ cat pcr7.policy
321fbd28b60fcc23017d501b133bd5dbf2889814588e8a23510fe10105cb2cc9

Then generate the trusted key and configure policydigest and get the key ID: 
$ keyctl add trusted kmk "new 32 keyhandle=0x81000001 hash=sha256 policydigest=`cat pcr7.policy`" @u
874117045

Save the trusted key. 
$ keyctl pipe 874117045 > kmk.blob

Reboot and load the key. 
Start a auth session to generate the policy:
$ tpm2_startauthsession -S session.ctx
session-handle: 0x3000000
$ tpm2_pcrlist -L sha256:7 -o pcr7.sha256
$ tpm2_policypcr -S session.ctx -L sha256:7 -F pcr7.sha256 -f pcr7.policy
policy-digest: 0x321FBD28B60FCC23017D501B133BD5DBF2889814588E8A23510FE10105CB2CC9

Input the policy handle to load trusted key:
$ keyctl add trusted kmk "load `cat kmk.blob` keyhandle=0x81000001 policyhandle=0x3000000" @u
add_key: Operation not permitted

The error should be policy check failed, because I use TPM command to unseal directly with error of policy check failed. 
$ tpm2_unseal -c 0x81000001 -L sha256:7
ERROR on line: "81" in file: "./lib/log.h": Tss2_Sys_Unseal(0x99D) - tpm:session(1):a policy check failed
ERROR on line: "213" in file: "tools/tpm2_unseal.c": Unseal failed!
ERROR on line: "166" in file: "tools/tpm2_tool.c": Unable to run tpm2_unseal

So my question is:
1. How to use the option, policydigest, policyhandle?? Is there any example? 
2. What's wrong with my test step? 

Thanks. 

- Shirley 



-----Original Message-----
From: Mimi Zohar <zohar@linux.ibm.com> 
Sent: Wednesday, November 13, 2019 11:46 PM
To: Zhao, Shirley <shirley.zhao@intel.com>; James Bottomley <jejb@linux.ibm.com>; Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>; Jonathan Corbet <corbet@lwn.net>
Cc: linux-integrity@vger.kernel.org; keyrings@vger.kernel.org; linux-doc@vger.kernel.org; linux-kernel@vger.kernel.org; 'Mauro Carvalho Chehab' <mchehab+samsung@kernel.org>
Subject: Re: One question about trusted key of keyring in Linux kernel.

On Wed, 2019-11-13 at 01:22 +0000, Zhao, Shirley wrote:
> Hi, all,
> 
> This is Shirley from Intel. I have one question about trusted key of 
> keyring in kernel. Please help.
> 
> According the to description in https://github.com/torvalds/linux/bl
> ob/master/Documentation/security/keys/trusted-encrypted.rst.
> Trusted key will be saved in TPM with PCR policy protected.

"Trusted Keys use a TPM both to generate and to seal the keys. Keys are sealed under a 2048 bit RSA key in the TPM, ..."

Trusted keys are not TPM keys.  They are not stored in the TPM.

> 
> Then, I running the following command to create a trusted key.
> keyctl add trusted test_trusted "new 32 keyhandle=0x81000001" @u
> 
> I also tried the following command, it can add one trusted key, too.
> keyctl add trusted test_trusted "new 32 keyhandle=0x81000001 
> pcrinfo=`cat pcr7.blob`" @u
> 
> But after reboot, this key will be removed.
> I need to re-added during boot.

Right, they need to be re-loaded on boot.  Refer to the dracut module /modules.d/97masterkey for loading a trusted key during boot.

> 
> Then the question is since this key is saved in TPM, how to get it 
> back from TPM?

Trusted keys are not stored in the TPM.  Refer to the ima-evm-utils README for examples of creating a trusted key (kmk) and an encrypted key (evm-key).

> 
> From the document, I need to use "keyctl pipe" to save the key into a 
> blob, then load it.
> But the blob contend key text, and this is a file on hard disk, it is 
> not safe to protect the key.
> 
> So what can TPM do here?

The hex ascii encoded trusted key is sealed under the TPM SRK.

Mimi

Re: One question about trusted key of keyring in Linux kernel.

[Mimi Zohar]

On Tue, 2019-11-26 at 07:32 +0000, Zhao, Shirley wrote:
> Thanks for your feedback, Mimi. 
> But the document of dracut can't solve my problem. 
> 
> I did more test these days and try to descript my question in more detail. 
> 
> In my scenario, the trusted key will be sealed into TPM with PCR policy. 
> And there are some related options in manual like 
>        hash=         hash algorithm name as a string. For TPM 1.x the only
>                      allowed value is sha1. For TPM 2.x the allowed values
>                      are sha1, sha256, sha384, sha512 and sm3-256.
>        policydigest= digest for the authorization policy. must be calculated
>                      with the same hash algorithm as specified by the 'hash='
>                      option.
>        policyhandle= handle to an authorization policy session that defines the
>                      same policy and with the same hash algorithm as was used to
>                      seal the key. 
> 
> Here is my test step. 
> Firstly, the pcr policy is generated as below: 
> $ tpm2_createpolicy --policy-pcr --pcr-list sha256:7 --policy pcr7_bin.policy > pcr7.policy
> 
> Pcr7.policy is the ascii hex of policy:
> $ cat pcr7.policy
> 321fbd28b60fcc23017d501b133bd5dbf2889814588e8a23510fe10105cb2cc9
> 
> Then generate the trusted key and configure policydigest and get the key ID: 
> $ keyctl add trusted kmk "new 32 keyhandle=0x81000001 hash=sha256 policydigest=`cat pcr7.policy`" @u
> 874117045
> 
> Save the trusted key. 
> $ keyctl pipe 874117045 > kmk.blob
> 
> Reboot and load the key. 
> Start a auth session to generate the policy:
> $ tpm2_startauthsession -S session.ctx
> session-handle: 0x3000000
> $ tpm2_pcrlist -L sha256:7 -o pcr7.sha256
> $ tpm2_policypcr -S session.ctx -L sha256:7 -F pcr7.sha256 -f pcr7.policy
> policy-digest: 0x321FBD28B60FCC23017D501B133BD5DBF2889814588E8A23510FE10105CB2CC9
> 
> Input the policy handle to load trusted key:
> $ keyctl add trusted kmk "load `cat kmk.blob` keyhandle=0x81000001 policyhandle=0x3000000" @u
> add_key: Operation not permitted
> 
> The error should be policy check failed, because I use TPM command to unseal directly with error of policy check failed. 
> $ tpm2_unseal -c 0x81000001 -L sha256:7
> ERROR on line: "81" in file: "./lib/log.h": Tss2_Sys_Unseal(0x99D) - tpm:session(1):a policy check failed
> ERROR on line: "213" in file: "tools/tpm2_unseal.c": Unseal failed!
> ERROR on line: "166" in file: "tools/tpm2_tool.c": Unable to run tpm2_unseal
> 
> So my question is:
> 1. How to use the option, policydigest, policyhandle?? Is there any example? 
> 2. What's wrong with my test step? 

When reporting a problem please state which kernel is experiencing
this problem.  Recently there was a trusted key regression.  Refer to
commit e13cd21ffd50 "tpm: Wrap the buffer from the caller to tpm_buf
in tpm_send()" for the details.

Before delving into this particular problem, first please make sure
you are able to create, save, remove, and then reload a trusted key
not sealed to a PCR.

Mimi 

RE: One question about trusted key of keyring in Linux kernel.

[Zhao, Shirley]

Hi, Mimi, 

Answer your two questions:

1. Yes, I have verified trusted key works well without PCR policy protection as below: 
$ keyctl add trusted kmk "new 32 keyhandle=0x81000001" @u
1055240928
$ keyctl list @u
1 keys in keyring:
1055240928: --alswrv     0     0 trusted: kmk
$ keyctl pipe 1055240928 > kmk.blob
$ cat kmk.blob
007f0020ff808bd8b7239194e89aac6a95b4d210114742c20afa33493f002dffd0685d510010c12d7ad51eb83d6d93895de066bf3d39718cc503adb4802cb087b88b2fff4b040fe3a2be6a3f87c6749d087c9fb6e8734cb23f438d64087581a13bc83d5dc3b026e77a894ece6620d0eb85df6449ff3c609fd77d5f0caf79b4535b002e0008000b000000400000001000209a5b00b0d558fcf9e8c029522715e6b5906366eaec5f34367b8ab16c0fb9009a0073000000000020e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b85501000b0022000bdcdb694e102e13a0fba5111081cb6cf616c118d404936cac3e84db24c71e47d50022000b04b5db1aa52635dfb242e76f6bde8e2176ae48fc682946c6c76d96f608079d1f0000002036b6fcca8206c7f722de85821d7ecb4785976fdd642bc7538505a2a818c8a23880214000000100202aedde4508f548d108193ec8fe166a7befde19113fe727ae2b29901bdece96e5
$ keyctl clear @u
$ keyctl list @u
keyring is empty
$ keyctl add trusted kmk "load `cat kmk.blob` keyhandle=0x81000001" @u
1022963731
$ keyctl print 1022963731
007f0020ff808bd8b7239194e89aac6a95b4d210114742c20afa33493f002dffd0685d510010c12d7ad51eb83d6d93895de066bf3d39718cc503adb4802cb087b88b2fff4b040fe3a2be6a3f87c6749d087c9fb6e8734cb23f438d64087581a13bc83d5dc3b026e77a894ece6620d0eb85df6449ff3c609fd77d5f0caf79b4535b002e0008000b000000400000001000209a5b00b0d558fcf9e8c029522715e6b5906366eaec5f34367b8ab16c0fb9009a0073000000000020e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b85501000b0022000bdcdb694e102e13a0fba5111081cb6cf616c118d404936cac3e84db24c71e47d50022000b04b5db1aa52635dfb242e76f6bde8e2176ae48fc682946c6c76d96f608079d1f0000002036b6fcca8206c7f722de85821d7ecb4785976fdd642bc7538505a2a818c8a23880214000000100202aedde4508f548d108193ec8fe166a7befde19113fe727ae2b29901bdece96e5

2. The following kernel file is related with this problem. 
/security/keys/keyctl.c
/security/keys/key.c
/security/keys/trusted-keys/trusted_tpm1.c
/security/keys/trusted-keys/trusted_tpm2.c

To load the PCR policy protection trusted key, the call stack is: 
SYSCALL_DEFINE5(add_key,...) --> key_create_or_update() --> __key_instantiate_and_link() -->  trusted_instantiate() --> tpm2_unseal_trusted() --> tpm2_unseal_cmd(). 

Check dmesg, there will be error: 
[73336.351596] trusted_key: key_unseal failed (-1)

- Shirley 

-----Original Message-----
From: Mimi Zohar <zohar@linux.ibm.com> 
Sent: Wednesday, November 27, 2019 3:28 AM
To: Zhao, Shirley <shirley.zhao@intel.com>; James Bottomley <jejb@linux.ibm.com>; Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>; Jonathan Corbet <corbet@lwn.net>
Cc: linux-integrity@vger.kernel.org; keyrings@vger.kernel.org; linux-doc@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>
Subject: Re: One question about trusted key of keyring in Linux kernel.

On Tue, 2019-11-26 at 07:32 +0000, Zhao, Shirley wrote:
> Thanks for your feedback, Mimi. 
> But the document of dracut can't solve my problem. 
> 
> I did more test these days and try to descript my question in more detail. 
> 
> In my scenario, the trusted key will be sealed into TPM with PCR policy. 
> And there are some related options in manual like 
>        hash=         hash algorithm name as a string. For TPM 1.x the only
>                      allowed value is sha1. For TPM 2.x the allowed values
>                      are sha1, sha256, sha384, sha512 and sm3-256.
>        policydigest= digest for the authorization policy. must be calculated
>                      with the same hash algorithm as specified by the 'hash='
>                      option.
>        policyhandle= handle to an authorization policy session that defines the
>                      same policy and with the same hash algorithm as was used to
>                      seal the key. 
> 
> Here is my test step. 
> Firstly, the pcr policy is generated as below: 
> $ tpm2_createpolicy --policy-pcr --pcr-list sha256:7 --policy 
> pcr7_bin.policy > pcr7.policy
> 
> Pcr7.policy is the ascii hex of policy:
> $ cat pcr7.policy
> 321fbd28b60fcc23017d501b133bd5dbf2889814588e8a23510fe10105cb2cc9
> 
> Then generate the trusted key and configure policydigest and get the key ID: 
> $ keyctl add trusted kmk "new 32 keyhandle=0x81000001 hash=sha256 
> policydigest=`cat pcr7.policy`" @u
> 874117045
> 
> Save the trusted key. 
> $ keyctl pipe 874117045 > kmk.blob
> 
> Reboot and load the key. 
> Start a auth session to generate the policy:
> $ tpm2_startauthsession -S session.ctx
> session-handle: 0x3000000
> $ tpm2_pcrlist -L sha256:7 -o pcr7.sha256 $ tpm2_policypcr -S 
> session.ctx -L sha256:7 -F pcr7.sha256 -f pcr7.policy
> policy-digest: 
> 0x321FBD28B60FCC23017D501B133BD5DBF2889814588E8A23510FE10105CB2CC9
> 
> Input the policy handle to load trusted key:
> $ keyctl add trusted kmk "load `cat kmk.blob` keyhandle=0x81000001 
> policyhandle=0x3000000" @u
> add_key: Operation not permitted
> 
> The error should be policy check failed, because I use TPM command to unseal directly with error of policy check failed. 
> $ tpm2_unseal -c 0x81000001 -L sha256:7 ERROR on line: "81" in file: 
> "./lib/log.h": Tss2_Sys_Unseal(0x99D) - tpm:session(1):a policy check 
> failed ERROR on line: "213" in file: "tools/tpm2_unseal.c": Unseal failed!
> ERROR on line: "166" in file: "tools/tpm2_tool.c": Unable to run 
> tpm2_unseal
> 
> So my question is:
> 1. How to use the option, policydigest, policyhandle?? Is there any example? 
> 2. What's wrong with my test step? 

When reporting a problem please state which kernel is experiencing this problem.  Recently there was a trusted key regression.  Refer to commit e13cd21ffd50 "tpm: Wrap the buffer from the caller to tpm_buf in tpm_send()" for the details.

Before delving into this particular problem, first please make sure you are able to create, save, remove, and then reload a trusted key not sealed to a PCR.

Mimi 

Re: One question about trusted key of keyring in Linux kernel.

[Mimi Zohar]

Hi Shirley,

On Wed, 2019-11-27 at 02:46 +0000, Zhao, Shirley wrote:
> Hi, Mimi, 
> 
> Answer your two questions:
> 
> 1. Yes, I have verified trusted key works well without PCR policy
> protection as below: 
> $ keyctl add trusted kmk "new 32 keyhandle=0x81000001" @u
> 1055240928
> $ keyctl list @u
> 1 keys in keyring:
> 1055240928: --alswrv     0     0 trusted: kmk
> $ keyctl pipe 1055240928 > kmk.blob
> $ cat kmk.blob
> 007f0020ff808bd8b7239194e89aac6a95b4d210114742c20afa33493f002dffd068
> 5d510010c12d7ad51eb83d6d93895de066bf3d39718cc503adb4802cb087b88b2fff
> 4b040fe3a2be6a3f87c6749d087c9fb6e8734cb23f438d64087581a13bc83d5dc3b0
> 26e77a894ece6620d0eb85df6449ff3c609fd77d5f0caf79b4535b002e0008000b00
> 0000400000001000209a5b00b0d558fcf9e8c029522715e6b5906366eaec5f34367b
> 8ab16c0fb9009a0073000000000020e3b0c44298fc1c149afbf4c8996fb92427ae41
> e4649b934ca495991b7852b85501000b0022000bdcdb694e102e13a0fba5111081cb
> 6cf616c118d404936cac3e84db24c71e47d50022000b04b5db1aa52635dfb242e76f
> 6bde8e2176ae48fc682946c6c76d96f608079d1f0000002036b6fcca8206c7f722de
> 85821d7ecb4785976fdd642bc7538505a2a818c8a23880214000000100202aedde45
> 08f548d108193ec8fe166a7befde19113fe727ae2b29901bdece96e5
> $ keyctl clear @u
> $ keyctl list @u
> keyring is empty
> $ keyctl add trusted kmk "load `cat kmk.blob` keyhandle=0x81000001"
> @u
> 1022963731
> $ keyctl print 1022963731
> 007f0020ff808bd8b7239194e89aac6a95b4d210114742c20afa33493f002dffd068
> 5d510010c12d7ad51eb83d6d93895de066bf3d39718cc503adb4802cb087b88b2fff
> 4b040fe3a2be6a3f87c6749d087c9fb6e8734cb23f438d64087581a13bc83d5dc3b0
> 26e77a894ece6620d0eb85df6449ff3c609fd77d5f0caf79b4535b002e0008000b00
> 0000400000001000209a5b00b0d558fcf9e8c029522715e6b5906366eaec5f34367b
> 8ab16c0fb9009a0073000000000020e3b0c44298fc1c149afbf4c8996fb92427ae41
> e4649b934ca495991b7852b85501000b0022000bdcdb694e102e13a0fba5111081cb
> 6cf616c118d404936cac3e84db24c71e47d50022000b04b5db1aa52635dfb242e76f
> 6bde8e2176ae48fc682946c6c76d96f608079d1f0000002036b6fcca8206c7f722de
> 85821d7ecb4785976fdd642bc7538505a2a818c8a23880214000000100202aedde45
> 08f548d108193ec8fe166a7befde19113fe727ae2b29901bdece96e5
> 
> 2. The following kernel file is related with this problem. 
> /security/keys/keyctl.c
> /security/keys/key.c
> /security/keys/trusted-keys/trusted_tpm1.c
> /security/keys/trusted-keys/trusted_tpm2.c
> 
> To load the PCR policy protection trusted key, the call stack is: 
> SYSCALL_DEFINE5(add_key,...) --> key_create_or_update() -->
> __key_instantiate_and_link() -->  trusted_instantiate() -->
> tpm2_unseal_trusted() --> tpm2_unseal_cmd(). 
> 
> Check dmesg, there will be error: 
> [73336.351596] trusted_key: key_unseal failed (-1)

Like the other kernel mailing lists, please bottom post.  When
reporting a problem, please include the kernel version and other
relevant details.  For example, the TPM version and type (eg. hardware
vendor, software TPM, etc).  Please indicate if this is a new problem
and which kernel release it first start happening?

I have no experience with the tpm2_ commands,  I suggest trying to
extend a single measurement to a PCR and sealing to that value.

Mimi

Re: One question about trusted key of keyring in Linux kernel.

[James Bottomley]

On Tue, 2019-11-26 at 07:32 +0000, Zhao, Shirley wrote:
> Thanks for your feedback, Mimi. 
> But the document of dracut can't solve my problem. 
> 
> I did more test these days and try to descript my question in more
> detail. 
> 
> In my scenario, the trusted key will be sealed into TPM with PCR
> policy. 
> And there are some related options in manual like 
>        hash=         hash algorithm name as a string. For TPM 1.x the
> only
>                      allowed value is sha1. For TPM 2.x the allowed
> values
>                      are sha1, sha256, sha384, sha512 and sm3-256.
>        policydigest= digest for the authorization policy. must be
> calculated
>                      with the same hash algorithm as specified by the
> 'hash='
>                      option.
>        policyhandle= handle to an authorization policy session that
> defines the
>                      same policy and with the same hash algorithm as
> was used to
>                      seal the key. 
> 
> Here is my test step. 
> Firstly, the pcr policy is generated as below: 
> $ tpm2_createpolicy --policy-pcr --pcr-list sha256:7 --policy
> pcr7_bin.policy > pcr7.policy
> 
> Pcr7.policy is the ascii hex of policy:
> $ cat pcr7.policy
> 321fbd28b60fcc23017d501b133bd5dbf2889814588e8a23510fe10105cb2cc9
> 
> Then generate the trusted key and configure policydigest and get the
> key ID: 
> $ keyctl add trusted kmk "new 32 keyhandle=0x81000001 hash=sha256
> policydigest=`cat pcr7.policy`" @u
> 874117045
> 
> Save the trusted key. 
> $ keyctl pipe 874117045 > kmk.blob
> 
> Reboot and load the key. 
> Start a auth session to generate the policy:
> $ tpm2_startauthsession -S session.ctx
> session-handle: 0x3000000
> $ tpm2_pcrlist -L sha256:7 -o pcr7.sha256
> $ tpm2_policypcr -S session.ctx -L sha256:7 -F pcr7.sha256 -f
> pcr7.policy
> policy-digest:
> 0x321FBD28B60FCC23017D501B133BD5DBF2889814588E8A23510FE10105CB2CC9
> 
> Input the policy handle to load trusted key:
> $ keyctl add trusted kmk "load `cat kmk.blob` keyhandle=0x81000001
> policyhandle=0x3000000" @u
> add_key: Operation not permitted
> 
> The error should be policy check failed, because I use TPM command to
> unseal directly with error of policy check failed. 
> $ tpm2_unseal -c 0x81000001 -L sha256:7
> ERROR on line: "81" in file: "./lib/log.h": Tss2_Sys_Unseal(0x99D) -
> tpm:session(1):a policy check failed
> ERROR on line: "213" in file: "tools/tpm2_unseal.c": Unseal failed!
> ERROR on line: "166" in file: "tools/tpm2_tool.c": Unable to run
> tpm2_unseal

I think there's a miscommunication here: you're complaining about the
error returned from a trusted key unseal operation that *should* fail,
correct?  You think it should return a TPM error but instead it returns
-EPERM.  That's completely correct: we translate all TPM errors into
linux ones as we pass them up to userspace, so the best we can do is
operation not permitted.

James

RE: One question about trusted key of keyring in Linux kernel.

[Zhao, Shirley]

Hi, James, 

Maybe the TPM command confused you. 

The question is I use keyctl command sealed a trusted key with PCR policy, but load it failed after reboot. 
I don't know why it was loaded failed. I use TPM command to help find it, it report policy check failed. 

So my question is how to load the PCR policy sealed trusted key correctly? 
How to use policydigest and policyhandle correctly. 

Thanks. 

- Shirley 

-----Original Message-----
From: James Bottomley <jejb@linux.ibm.com> 
Sent: Thursday, November 28, 2019 2:06 AM
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; keyrings@vger.kernel.org; linux-doc@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>
Subject: Re: One question about trusted key of keyring in Linux kernel.

On Tue, 2019-11-26 at 07:32 +0000, Zhao, Shirley wrote:
> Thanks for your feedback, Mimi. 
> But the document of dracut can't solve my problem. 
> 
> I did more test these days and try to descript my question in more 
> detail.
> 
> In my scenario, the trusted key will be sealed into TPM with PCR 
> policy.
> And there are some related options in manual like 
>        hash=         hash algorithm name as a string. For TPM 1.x the
> only
>                      allowed value is sha1. For TPM 2.x the allowed 
> values
>                      are sha1, sha256, sha384, sha512 and sm3-256.
>        policydigest= digest for the authorization policy. must be 
> calculated
>                      with the same hash algorithm as specified by the 
> 'hash='
>                      option.
>        policyhandle= handle to an authorization policy session that 
> defines the
>                      same policy and with the same hash algorithm as 
> was used to
>                      seal the key. 
> 
> Here is my test step. 
> Firstly, the pcr policy is generated as below: 
> $ tpm2_createpolicy --policy-pcr --pcr-list sha256:7 --policy 
> pcr7_bin.policy > pcr7.policy
> 
> Pcr7.policy is the ascii hex of policy:
> $ cat pcr7.policy
> 321fbd28b60fcc23017d501b133bd5dbf2889814588e8a23510fe10105cb2cc9
> 
> Then generate the trusted key and configure policydigest and get the 
> key ID:
> $ keyctl add trusted kmk "new 32 keyhandle=0x81000001 hash=sha256 
> policydigest=`cat pcr7.policy`" @u
> 874117045
> 
> Save the trusted key. 
> $ keyctl pipe 874117045 > kmk.blob
> 
> Reboot and load the key. 
> Start a auth session to generate the policy:
> $ tpm2_startauthsession -S session.ctx
> session-handle: 0x3000000
> $ tpm2_pcrlist -L sha256:7 -o pcr7.sha256 $ tpm2_policypcr -S 
> session.ctx -L sha256:7 -F pcr7.sha256 -f pcr7.policy
> policy-digest:
> 0x321FBD28B60FCC23017D501B133BD5DBF2889814588E8A23510FE10105CB2CC9
> 
> Input the policy handle to load trusted key:
> $ keyctl add trusted kmk "load `cat kmk.blob` keyhandle=0x81000001 
> policyhandle=0x3000000" @u
> add_key: Operation not permitted
> 
> The error should be policy check failed, because I use TPM command to 
> unseal directly with error of policy check failed.
> $ tpm2_unseal -c 0x81000001 -L sha256:7 ERROR on line: "81" in file: 
> "./lib/log.h": Tss2_Sys_Unseal(0x99D) - tpm:session(1):a policy check 
> failed ERROR on line: "213" in file: "tools/tpm2_unseal.c": Unseal 
> failed!
> ERROR on line: "166" in file: "tools/tpm2_tool.c": Unable to run 
> tpm2_unseal

I think there's a miscommunication here: you're complaining about the error returned from a trusted key unseal operation that *should* fail, correct?  You think it should return a TPM error but instead it returns -EPERM.  That's completely correct: we translate all TPM errors into linux ones as we pass them up to userspace, so the best we can do is operation not permitted.

James

RE: One question about trusted key of keyring in Linux kernel.

[Zhao, Shirley]

Hi, Mimi, 

My test environment is Ubuntu 18.04.3, kernel version is 5.0.0-36-generic. 
$ cat /proc/version
Linux version 5.0.0-36-generic (buildd@lgw01-amd64-060) (gcc version 7.4.0 (Ubuntu 7.4.0-1ubuntu1~18.04.1)) #39~18.04.1-Ubuntu SMP Tue Nov 12 11:09:50 UTC 2019
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 18.04.3 LTS
Release:        18.04
Codename:       bionic

It is TPM2.0, dTPM. 

And I didn’t run it on other version. 

It has no relationship with TPM command, it is just used to help find the fail reason. 
My question is how to load a trusted key which is sealed with PCR policy correctly after reboot.
That is better if there is some example about how to use "policydigest", "policyhandle" to seal/unseal a trusted key. 

Thanks. 

- Shirley 



-----Original Message-----
From: Mimi Zohar <zohar@linux.ibm.com> 
Sent: Wednesday, November 27, 2019 11:39 PM
To: Zhao, Shirley <shirley.zhao@intel.com>; James Bottomley <jejb@linux.ibm.com>; Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>; Jonathan Corbet <corbet@lwn.net>
Cc: linux-integrity@vger.kernel.org; keyrings@vger.kernel.org; linux-doc@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>
Subject: Re: One question about trusted key of keyring in Linux kernel.

Hi Shirley,

On Wed, 2019-11-27 at 02:46 +0000, Zhao, Shirley wrote:
> Hi, Mimi,
> 
> Answer your two questions:
> 
> 1. Yes, I have verified trusted key works well without PCR policy 
> protection as below:
> $ keyctl add trusted kmk "new 32 keyhandle=0x81000001" @u
> 1055240928
> $ keyctl list @u
> 1 keys in keyring:
> 1055240928: --alswrv     0     0 trusted: kmk
> $ keyctl pipe 1055240928 > kmk.blob
> $ cat kmk.blob
> 007f0020ff808bd8b7239194e89aac6a95b4d210114742c20afa33493f002dffd068
> 5d510010c12d7ad51eb83d6d93895de066bf3d39718cc503adb4802cb087b88b2fff
> 4b040fe3a2be6a3f87c6749d087c9fb6e8734cb23f438d64087581a13bc83d5dc3b0
> 26e77a894ece6620d0eb85df6449ff3c609fd77d5f0caf79b4535b002e0008000b00
> 0000400000001000209a5b00b0d558fcf9e8c029522715e6b5906366eaec5f34367b
> 8ab16c0fb9009a0073000000000020e3b0c44298fc1c149afbf4c8996fb92427ae41
> e4649b934ca495991b7852b85501000b0022000bdcdb694e102e13a0fba5111081cb
> 6cf616c118d404936cac3e84db24c71e47d50022000b04b5db1aa52635dfb242e76f
> 6bde8e2176ae48fc682946c6c76d96f608079d1f0000002036b6fcca8206c7f722de
> 85821d7ecb4785976fdd642bc7538505a2a818c8a23880214000000100202aedde45
> 08f548d108193ec8fe166a7befde19113fe727ae2b29901bdece96e5
> $ keyctl clear @u
> $ keyctl list @u
> keyring is empty
> $ keyctl add trusted kmk "load `cat kmk.blob` keyhandle=0x81000001"
> @u
> 1022963731
> $ keyctl print 1022963731
> 007f0020ff808bd8b7239194e89aac6a95b4d210114742c20afa33493f002dffd068
> 5d510010c12d7ad51eb83d6d93895de066bf3d39718cc503adb4802cb087b88b2fff
> 4b040fe3a2be6a3f87c6749d087c9fb6e8734cb23f438d64087581a13bc83d5dc3b0
> 26e77a894ece6620d0eb85df6449ff3c609fd77d5f0caf79b4535b002e0008000b00
> 0000400000001000209a5b00b0d558fcf9e8c029522715e6b5906366eaec5f34367b
> 8ab16c0fb9009a0073000000000020e3b0c44298fc1c149afbf4c8996fb92427ae41
> e4649b934ca495991b7852b85501000b0022000bdcdb694e102e13a0fba5111081cb
> 6cf616c118d404936cac3e84db24c71e47d50022000b04b5db1aa52635dfb242e76f
> 6bde8e2176ae48fc682946c6c76d96f608079d1f0000002036b6fcca8206c7f722de
> 85821d7ecb4785976fdd642bc7538505a2a818c8a23880214000000100202aedde45
> 08f548d108193ec8fe166a7befde19113fe727ae2b29901bdece96e5
> 
> 2. The following kernel file is related with this problem. 
> /security/keys/keyctl.c /security/keys/key.c 
> /security/keys/trusted-keys/trusted_tpm1.c
> /security/keys/trusted-keys/trusted_tpm2.c
> 
> To load the PCR policy protection trusted key, the call stack is:
> SYSCALL_DEFINE5(add_key,...) --> key_create_or_update() -->
> __key_instantiate_and_link() -->  trusted_instantiate() -->
> tpm2_unseal_trusted() --> tpm2_unseal_cmd().
> 
> Check dmesg, there will be error:
> [73336.351596] trusted_key: key_unseal failed (-1)

Like the other kernel mailing lists, please bottom post.  When reporting a problem, please include the kernel version and other relevant details.  For example, the TPM version and type (eg. hardware vendor, software TPM, etc).  Please indicate if this is a new problem and which kernel release it first start happening?

I have no experience with the tpm2_ commands,  I suggest trying to extend a single measurement to a PCR and sealing to that value.

Mimi

Re: One question about trusted key of keyring in Linux kernel.

[James Bottomley]

On Fri, 2019-11-29 at 01:40 +0000, Zhao, Shirley wrote:
> Hi, James, 
> 
> Maybe the TPM command confused you. 

Well you did seem to be saying we had a problem in the TPM sealed key
subsystem.

> The question is I use keyctl command sealed a trusted key with PCR
> policy, but load it failed after reboot. 
> I don't know why it was loaded failed. I use TPM command to help find
> it, it report policy check failed. 

Right, so your question seems to be why after a reboot, the TPM policy
no longer works to authorize the key even from user space?  My best
guess would be the PCR value you've sealed it to changed over the
reboot for some reason.

> So my question is how to load the PCR policy sealed trusted key
> correctly?

You have to set the sealing release policy to something you know will
be invariant across reboots for an unseal to happen reliably.  However,
usually you also want the unseal to fail if something you don't like
changes, so you set the policy to be something that's invariant unless
that happens.  Not really knowing what your conditions are we can't
really tell you what your policy should look like.

> How to use policydigest and policyhandle correctly. 

I've no real idea how the tpm2_ commands work, but the tsspolicy
commands all have man pages which do a pretty good explanation.  If I
infer how your tpm2_ commands seem to be working, I think
you're sealing to a pcr7 hash?  pcr7 is the one that's supposed to
measure the secure boot path and properties and as such shouldn't
change across reboots, so I think your problem becomes finding out why
it changed.

James

Re: One question about trusted key of keyring in Linux kernel.

[Jarkko Sakkinen]

On Tue, Nov 26, 2019 at 02:27:36PM -0500, Mimi Zohar wrote:
> On Tue, 2019-11-26 at 07:32 +0000, Zhao, Shirley wrote:
> > Thanks for your feedback, Mimi. 
> > But the document of dracut can't solve my problem. 
> > 
> > I did more test these days and try to descript my question in more detail. 
> > 
> > In my scenario, the trusted key will be sealed into TPM with PCR policy. 
> > And there are some related options in manual like 
> >        hash=         hash algorithm name as a string. For TPM 1.x the only
> >                      allowed value is sha1. For TPM 2.x the allowed values
> >                      are sha1, sha256, sha384, sha512 and sm3-256.
> >        policydigest= digest for the authorization policy. must be calculated
> >                      with the same hash algorithm as specified by the 'hash='
> >                      option.
> >        policyhandle= handle to an authorization policy session that defines the
> >                      same policy and with the same hash algorithm as was used to
> >                      seal the key. 
> > 
> > Here is my test step. 
> > Firstly, the pcr policy is generated as below: 
> > $ tpm2_createpolicy --policy-pcr --pcr-list sha256:7 --policy pcr7_bin.policy > pcr7.policy
> > 
> > Pcr7.policy is the ascii hex of policy:
> > $ cat pcr7.policy
> > 321fbd28b60fcc23017d501b133bd5dbf2889814588e8a23510fe10105cb2cc9
> > 
> > Then generate the trusted key and configure policydigest and get the key ID: 
> > $ keyctl add trusted kmk "new 32 keyhandle=0x81000001 hash=sha256 policydigest=`cat pcr7.policy`" @u
> > 874117045
> > 
> > Save the trusted key. 
> > $ keyctl pipe 874117045 > kmk.blob
> > 
> > Reboot and load the key. 
> > Start a auth session to generate the policy:
> > $ tpm2_startauthsession -S session.ctx
> > session-handle: 0x3000000
> > $ tpm2_pcrlist -L sha256:7 -o pcr7.sha256
> > $ tpm2_policypcr -S session.ctx -L sha256:7 -F pcr7.sha256 -f pcr7.policy
> > policy-digest: 0x321FBD28B60FCC23017D501B133BD5DBF2889814588E8A23510FE10105CB2CC9
> > 
> > Input the policy handle to load trusted key:
> > $ keyctl add trusted kmk "load `cat kmk.blob` keyhandle=0x81000001 policyhandle=0x3000000" @u
> > add_key: Operation not permitted
> > 
> > The error should be policy check failed, because I use TPM command to unseal directly with error of policy check failed. 
> > $ tpm2_unseal -c 0x81000001 -L sha256:7
> > ERROR on line: "81" in file: "./lib/log.h": Tss2_Sys_Unseal(0x99D) - tpm:session(1):a policy check failed
> > ERROR on line: "213" in file: "tools/tpm2_unseal.c": Unseal failed!
> > ERROR on line: "166" in file: "tools/tpm2_tool.c": Unable to run tpm2_unseal
> > 
> > So my question is:
> > 1. How to use the option, policydigest, policyhandle?? Is there any example? 
> > 2. What's wrong with my test step? 
> 
> When reporting a problem please state which kernel is experiencing
> this problem.  Recently there was a trusted key regression.  Refer to
> commit e13cd21ffd50 "tpm: Wrap the buffer from the caller to tpm_buf
> in tpm_send()" for the details.
> 
> Before delving into this particular problem, first please make sure
> you are able to create, save, remove, and then reload a trusted key
> not sealed to a PCR.

Please re-test with rc1 when available.

/Jarkko

RE: One question about trusted key of keyring in Linux kernel.

[Zhao, Shirley]

Hi, James, 

The value of PCR7 is not changed. I have checked it with TPM command tpm_pcrlist. 

So I think the problem is how to use the option policydigest and policyhandle? Is there any example?
Maybe the format in my command is not correct. 

Thanks. 

- Shirley 

-----Original Message-----
From: James Bottomley <jejb@linux.ibm.com> 
Sent: Saturday, November 30, 2019 4:05 AM
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; keyrings@vger.kernel.org; linux-doc@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>
Subject: Re: One question about trusted key of keyring in Linux kernel.

On Fri, 2019-11-29 at 01:40 +0000, Zhao, Shirley wrote:
> Hi, James,
> 
> Maybe the TPM command confused you. 

Well you did seem to be saying we had a problem in the TPM sealed key subsystem.

> The question is I use keyctl command sealed a trusted key with PCR 
> policy, but load it failed after reboot.
> I don't know why it was loaded failed. I use TPM command to help find 
> it, it report policy check failed.

Right, so your question seems to be why after a reboot, the TPM policy no longer works to authorize the key even from user space?  My best guess would be the PCR value you've sealed it to changed over the reboot for some reason.

> So my question is how to load the PCR policy sealed trusted key 
> correctly?

You have to set the sealing release policy to something you know will be invariant across reboots for an unseal to happen reliably.  However, usually you also want the unseal to fail if something you don't like changes, so you set the policy to be something that's invariant unless that happens.  Not really knowing what your conditions are we can't really tell you what your policy should look like.

> How to use policydigest and policyhandle correctly. 

I've no real idea how the tpm2_ commands work, but the tsspolicy commands all have man pages which do a pretty good explanation.  If I infer how your tpm2_ commands seem to be working, I think you're sealing to a pcr7 hash?  pcr7 is the one that's supposed to measure the secure boot path and properties and as such shouldn't change across reboots, so I think your problem becomes finding out why it changed.

James

RE: One question about trusted key of keyring in Linux kernel.

[Zhao, Shirley]

Hi, Jarkko, 

The rc1 you mentioned is the version for what? 
How to download it and update it? 

Thanks. 

- Shirley 

-----Original Message-----
From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> 
Sent: Saturday, November 30, 2019 7:02 AM
To: Mimi Zohar <zohar@linux.ibm.com>
Cc: Zhao, Shirley <shirley.zhao@intel.com>; James Bottomley <jejb@linux.ibm.com>; Jonathan Corbet <corbet@lwn.net>; linux-integrity@vger.kernel.org; keyrings@vger.kernel.org; linux-doc@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>
Subject: Re: One question about trusted key of keyring in Linux kernel.

On Tue, Nov 26, 2019 at 02:27:36PM -0500, Mimi Zohar wrote:
> On Tue, 2019-11-26 at 07:32 +0000, Zhao, Shirley wrote:
> > Thanks for your feedback, Mimi. 
> > But the document of dracut can't solve my problem. 
> > 
> > I did more test these days and try to descript my question in more detail. 
> > 
> > In my scenario, the trusted key will be sealed into TPM with PCR policy. 
> > And there are some related options in manual like 
> >        hash=         hash algorithm name as a string. For TPM 1.x the only
> >                      allowed value is sha1. For TPM 2.x the allowed values
> >                      are sha1, sha256, sha384, sha512 and sm3-256.
> >        policydigest= digest for the authorization policy. must be calculated
> >                      with the same hash algorithm as specified by the 'hash='
> >                      option.
> >        policyhandle= handle to an authorization policy session that defines the
> >                      same policy and with the same hash algorithm as was used to
> >                      seal the key. 
> > 
> > Here is my test step. 
> > Firstly, the pcr policy is generated as below: 
> > $ tpm2_createpolicy --policy-pcr --pcr-list sha256:7 --policy 
> > pcr7_bin.policy > pcr7.policy
> > 
> > Pcr7.policy is the ascii hex of policy:
> > $ cat pcr7.policy
> > 321fbd28b60fcc23017d501b133bd5dbf2889814588e8a23510fe10105cb2cc9
> > 
> > Then generate the trusted key and configure policydigest and get the key ID: 
> > $ keyctl add trusted kmk "new 32 keyhandle=0x81000001 hash=sha256 
> > policydigest=`cat pcr7.policy`" @u
> > 874117045
> > 
> > Save the trusted key. 
> > $ keyctl pipe 874117045 > kmk.blob
> > 
> > Reboot and load the key. 
> > Start a auth session to generate the policy:
> > $ tpm2_startauthsession -S session.ctx
> > session-handle: 0x3000000
> > $ tpm2_pcrlist -L sha256:7 -o pcr7.sha256 $ tpm2_policypcr -S 
> > session.ctx -L sha256:7 -F pcr7.sha256 -f pcr7.policy
> > policy-digest: 
> > 0x321FBD28B60FCC23017D501B133BD5DBF2889814588E8A23510FE10105CB2CC9
> > 
> > Input the policy handle to load trusted key:
> > $ keyctl add trusted kmk "load `cat kmk.blob` keyhandle=0x81000001 
> > policyhandle=0x3000000" @u
> > add_key: Operation not permitted
> > 
> > The error should be policy check failed, because I use TPM command to unseal directly with error of policy check failed. 
> > $ tpm2_unseal -c 0x81000001 -L sha256:7 ERROR on line: "81" in file: 
> > "./lib/log.h": Tss2_Sys_Unseal(0x99D) - tpm:session(1):a policy 
> > check failed ERROR on line: "213" in file: "tools/tpm2_unseal.c": Unseal failed!
> > ERROR on line: "166" in file: "tools/tpm2_tool.c": Unable to run 
> > tpm2_unseal
> > 
> > So my question is:
> > 1. How to use the option, policydigest, policyhandle?? Is there any example? 
> > 2. What's wrong with my test step? 
> 
> When reporting a problem please state which kernel is experiencing 
> this problem.  Recently there was a trusted key regression.  Refer to 
> commit e13cd21ffd50 "tpm: Wrap the buffer from the caller to tpm_buf 
> in tpm_send()" for the details.
> 
> Before delving into this particular problem, first please make sure 
> you are able to create, save, remove, and then reload a trusted key 
> not sealed to a PCR.

Please re-test with rc1 when available.

/Jarkko

Re: One question about trusted key of keyring in Linux kernel.

[James Bottomley]

On Mon, 2019-12-02 at 01:44 +0000, Zhao, Shirley wrote:
> Hi, James, 
> 
> The value of PCR7 is not changed. I have checked it with TPM command
> tpm_pcrlist. 
> 
> So I think the problem is how to use the option policydigest and
> policyhandle? Is there any example?
> Maybe the format in my command is not correct. 

OK, so previously you said that using the Intel TSS the policy also
failed after a reboot:

> The error should be policy check failed, because I use TPM command to
> unseal directly with error of policy check failed. 
> $ tpm2_unseal -c 0x81000001 -L sha256:7
> ERROR on line: "81" in file: "./lib/log.h": Tss2_Sys_Unseal(0x99D) -
> tpm:session(1):a policy check failed
> ERROR on line: "213" in file: "tools/tpm2_unseal.c": Unseal failed!
> ERROR on line: "166" in file: "tools/tpm2_tool.c": Unable to run
> tpm2_unseal

So this must mean the actual policy hash you constructed was wrong in
some way: it didn't correspond simply to a value of pcr7 ... well
assuming the -L sha256:7 means construct a policy of the sha256 value
of pcr7 and use it in the unseal.

I can tell you how to construct policies using TPM2 commands, but I
think you want to know how to do it using the Intel TSS?  In which case
you really need to consult the experts in that TSS, like Phil Tricca.

For the plain TPM2 case, the policy looks like

TPM_CC_PolicyPCR || pcrs || pcrDigest

Where TPM_CC_PolicyPCR = 0000017f and for selecting pcr7 only.  pcrs is
a complicated entity: it's a counted array of pcr selections.  For your
policy you only need one entry, so it would be 00000001 followed by a
single pcrSelection entry.  pcrSelection is the hash algorithm, the
size of the selection bitmap (always 3 since every current TPM only has
24 PCRs) and a bitmap selecting the PCRs in big endian format, so for
PCR7 using sha256 (algorithm 000b), pcrSelection = 000b 03 80 00 00. 
And then you follow this by the hash of the PCR value you're looking
for.  The policyhash becomes the initial policy (all zeros for the
start of the policy chain) hashed with this.

Regards,

James

RE: One question about trusted key of keyring in Linux kernel.

[Zhao, Shirley]

Thanks for your feedback, James.

The policy is generated by TPM command, tpm2_createpolicy, it just use the algorithm you mentioned, which is defined in TPM spec. 
I re-attach my test steps as below. 
Please help check it, is there anything wrong, especially the format of keyctl command. 

Firstly, the pcr policy is generated as below: 
$ tpm2_createpolicy --policy-pcr --pcr-list sha256:7 --policy pcr7_bin.policy > pcr7.policy

Pcr7.policy is the ascii hex of policy:
$ cat pcr7.policy
321fbd28b60fcc23017d501b133bd5dbf2889814588e8a23510fe10105cb2cc9

Then generate the trusted key and configure policydigest and get the key ID: 
$ keyctl add trusted kmk "new 32 keyhandle=0x81000001 hash=sha256 policydigest=`cat pcr7.policy`" @u
874117045

Save the trusted key. 
$ keyctl pipe 874117045 > kmk.blob

Reboot and load the key. 
Start a auth session to generate the policy:
$ tpm2_startauthsession -S session.ctx
session-handle: 0x3000000
$ tpm2_pcrlist -L sha256:7 -o pcr7.sha256 $ tpm2_policypcr -S session.ctx -L sha256:7 -F pcr7.sha256 -f pcr7.policy
policy-digest: 0x321FBD28B60FCC23017D501B133BD5DBF2889814588E8A23510FE10105CB2CC9

Input the policy handle to load trusted key:
$ keyctl add trusted kmk "load `cat kmk.blob` keyhandle=0x81000001 policyhandle=0x3000000" @u
add_key: Operation not permitted

The error should be policy check failed, because I use TPM command to unseal directly with error of policy check failed. 
$ tpm2_unseal -c 0x81000001 -L sha256:7
ERROR on line: "81" in file: "./lib/log.h": Tss2_Sys_Unseal(0x99D) - tpm:session(1):a policy check failed ERROR on line: "213" in file: "tools/tpm2_unseal.c": Unseal failed!
ERROR on line: "166" in file: "tools/tpm2_tool.c": Unable to run tpm2_unseal

- Shirley 

-----Original Message-----
From: James Bottomley <jejb@linux.ibm.com> 
Sent: Monday, December 2, 2019 12:17 PM
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; keyrings@vger.kernel.org; linux-doc@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>
Subject: Re: One question about trusted key of keyring in Linux kernel.

On Mon, 2019-12-02 at 01:44 +0000, Zhao, Shirley wrote:
> Hi, James,
> 
> The value of PCR7 is not changed. I have checked it with TPM command 
> tpm_pcrlist.
> 
> So I think the problem is how to use the option policydigest and 
> policyhandle? Is there any example?
> Maybe the format in my command is not correct. 

OK, so previously you said that using the Intel TSS the policy also failed after a reboot:

> The error should be policy check failed, because I use TPM command to 
> unseal directly with error of policy check failed.
> $ tpm2_unseal -c 0x81000001 -L sha256:7 ERROR on line: "81" in file: 
> "./lib/log.h": Tss2_Sys_Unseal(0x99D) - tpm:session(1):a policy check 
> failed ERROR on line: "213" in file: "tools/tpm2_unseal.c": Unseal 
> failed!
> ERROR on line: "166" in file: "tools/tpm2_tool.c": Unable to run 
> tpm2_unseal

So this must mean the actual policy hash you constructed was wrong in some way: it didn't correspond simply to a value of pcr7 ... well assuming the -L sha256:7 means construct a policy of the sha256 value of pcr7 and use it in the unseal.

I can tell you how to construct policies using TPM2 commands, but I think you want to know how to do it using the Intel TSS?  In which case you really need to consult the experts in that TSS, like Phil Tricca.

For the plain TPM2 case, the policy looks like

TPM_CC_PolicyPCR || pcrs || pcrDigest

Where TPM_CC_PolicyPCR = 0000017f and for selecting pcr7 only.  pcrs is a complicated entity: it's a counted array of pcr selections.  For your policy you only need one entry, so it would be 00000001 followed by a single pcrSelection entry.  pcrSelection is the hash algorithm, the size of the selection bitmap (always 3 since every current TPM only has
24 PCRs) and a bitmap selecting the PCRs in big endian format, so for
PCR7 using sha256 (algorithm 000b), pcrSelection = 000b 03 80 00 00. 
And then you follow this by the hash of the PCR value you're looking for.  The policyhash becomes the initial policy (all zeros for the start of the policy chain) hashed with this.

Regards,

James

Re: One question about trusted key of keyring in Linux kernel.

[James Bottomley]

On Mon, 2019-12-02 at 05:55 +0000, Zhao, Shirley wrote:
> Thanks for your feedback, James.
> 
> The policy is generated by TPM command, tpm2_createpolicy, it just
> use the algorithm you mentioned, which is defined in TPM spec. 
> I re-attach my test steps as below. 
> Please help check it, is there anything wrong, especially the format
> of keyctl command. 
> 
> Firstly, the pcr policy is generated as below: 
> $ tpm2_createpolicy --policy-pcr --pcr-list sha256:7 --policy
> pcr7_bin.policy > pcr7.policy

I don't use the Intel TSS, so I can't help you with this command: you
need to ask someone who does use it it, like Phil.

> Pcr7.policy is the ascii hex of policy:
> $ cat pcr7.policy
> 321fbd28b60fcc23017d501b133bd5dbf2889814588e8a23510fe10105cb2cc9

You haven't provided enough information.  If you tell me what the pcr7
value you tied the policy to is, I can run it through the IBM TSS
policy maker and tell you if this is the correct hash.  But obviously,
since it's a hash, I can't reverse it to tell you what the policy it
mandates is.

James

> Then generate the trusted key and configure policydigest and get the
> key ID: 
> $ keyctl add trusted kmk "new 32 keyhandle=0x81000001 hash=sha256
> policydigest=`cat pcr7.policy`" @u
> 874117045
> 
> Save the trusted key. 
> $ keyctl pipe 874117045 > kmk.blob
> 
> Reboot and load the key. 
> Start a auth session to generate the policy:
> $ tpm2_startauthsession -S session.ctx
> session-handle: 0x3000000
> $ tpm2_pcrlist -L sha256:7 -o pcr7.sha256 $ tpm2_policypcr -S
> session.ctx -L sha256:7 -F pcr7.sha256 -f pcr7.policy
> policy-digest:
> 0x321FBD28B60FCC23017D501B133BD5DBF2889814588E8A23510FE10105CB2CC9
> 
> Input the policy handle to load trusted key:
> $ keyctl add trusted kmk "load `cat kmk.blob` keyhandle=0x81000001
> policyhandle=0x3000000" @u
> add_key: Operation not permitted
> 
> The error should be policy check failed, because I use TPM command to
> unseal directly with error of policy check failed. 
> $ tpm2_unseal -c 0x81000001 -L sha256:7
> ERROR on line: "81" in file: "./lib/log.h": Tss2_Sys_Unseal(0x99D) -
> tpm:session(1):a policy check failed ERROR on line: "213" in file:
> "tools/tpm2_unseal.c": Unseal failed!
> ERROR on line: "166" in file: "tools/tpm2_tool.c": Unable to run
> tpm2_unseal
> 
> - Shirley 
> 
> -----Original Message-----
> From: James Bottomley <jejb@linux.ibm.com> 
> Sent: Monday, December 2, 2019 12:17 PM
> To: Zhao, Shirley <shirley.zhao@intel.com>; Mimi Zohar <zohar@linux.i
> bm.com>; Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>; Jonathan
> Corbet <corbet@lwn.net>
> Cc: linux-integrity@vger.kernel.org; keyrings@vger.kernel.org; linux-
> doc@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>
> Subject: Re: One question about trusted key of keyring in Linux
> kernel.
> 
> On Mon, 2019-12-02 at 01:44 +0000, Zhao, Shirley wrote:
> > Hi, James,
> > 
> > The value of PCR7 is not changed. I have checked it with TPM
> > command 
> > tpm_pcrlist.
> > 
> > So I think the problem is how to use the option policydigest and 
> > policyhandle? Is there any example?
> > Maybe the format in my command is not correct. 
> 
> OK, so previously you said that using the Intel TSS the policy also
> failed after a reboot:
> 
> > The error should be policy check failed, because I use TPM command
> > to 
> > unseal directly with error of policy check failed.
> > $ tpm2_unseal -c 0x81000001 -L sha256:7 ERROR on line: "81" in
> > file: 
> > "./lib/log.h": Tss2_Sys_Unseal(0x99D) - tpm:session(1):a policy
> > check 
> > failed ERROR on line: "213" in file: "tools/tpm2_unseal.c": Unseal 
> > failed!
> > ERROR on line: "166" in file: "tools/tpm2_tool.c": Unable to run 
> > tpm2_unseal
> 
> So this must mean the actual policy hash you constructed was wrong in
> some way: it didn't correspond simply to a value of pcr7 ... well
> assuming the -L sha256:7 means construct a policy of the sha256 value
> of pcr7 and use it in the unseal.
> 
> I can tell you how to construct policies using TPM2 commands, but I
> think you want to know how to do it using the Intel TSS?  In which
> case you really need to consult the experts in that TSS, like Phil
> Tricca.
> 
> For the plain TPM2 case, the policy looks like
> 
> TPM_CC_PolicyPCR || pcrs || pcrDigest
> 
> Where TPM_CC_PolicyPCR = 0000017f and for selecting pcr7 only.  pcrs
> is a complicated entity: it's a counted array of pcr selections.  For
> your policy you only need one entry, so it would be 00000001 followed
> by a single pcrSelection entry.  pcrSelection is the hash algorithm,
> the size of the selection bitmap (always 3 since every current TPM
> only has
> 24 PCRs) and a bitmap selecting the PCRs in big endian format, so for
> PCR7 using sha256 (algorithm 000b), pcrSelection = 000b 03 80 00 00. 
> And then you follow this by the hash of the PCR value you're looking
> for.  The policyhash becomes the initial policy (all zeros for the
> start of the policy chain) hashed with this.
> 
> Regards,
> 
> James
> 

RE: One question about trusted key of keyring in Linux kernel.

[Zhao, Shirley]

Hi, James, 

The PCR7 value and PCR7 policy is as below, please review, thanks. 

# tpm2_pcrlist -L sha256:7 -o pcr7_2.sha256
sha256:
  7 : 0x061AAD0705A62361AD18E58B65D3D7383F4D10F7F5A7E78924BE057AC6797408

# tpm2_createpolicy --policy-pcr --pcr-list sha256:7 --policy pcr7_bin.policy > pcr7.policy
321fbd28b60fcc23017d501b133bd5dbf2889814588e8a23510fe10105cb2cc9

# cat pcr7.policy
321fbd28b60fcc23017d501b133bd5dbf2889814588e8a23510fe10105cb2cc9

- Shirley 

-----Original Message-----
From: James Bottomley <jejb@linux.ibm.com> 
Sent: Monday, December 2, 2019 2:18 PM
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; keyrings@vger.kernel.org; linux-doc@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>
Subject: Re: One question about trusted key of keyring in Linux kernel.

On Mon, 2019-12-02 at 05:55 +0000, Zhao, Shirley wrote:
> Thanks for your feedback, James.
> 
> The policy is generated by TPM command, tpm2_createpolicy, it just use 
> the algorithm you mentioned, which is defined in TPM spec.
> I re-attach my test steps as below. 
> Please help check it, is there anything wrong, especially the format 
> of keyctl command.
> 
> Firstly, the pcr policy is generated as below: 
> $ tpm2_createpolicy --policy-pcr --pcr-list sha256:7 --policy 
> pcr7_bin.policy > pcr7.policy

I don't use the Intel TSS, so I can't help you with this command: you need to ask someone who does use it it, like Phil.

> Pcr7.policy is the ascii hex of policy:
> $ cat pcr7.policy
> 321fbd28b60fcc23017d501b133bd5dbf2889814588e8a23510fe10105cb2cc9

You haven't provided enough information.  If you tell me what the pcr7 value you tied the policy to is, I can run it through the IBM TSS policy maker and tell you if this is the correct hash.  But obviously, since it's a hash, I can't reverse it to tell you what the policy it mandates is.

James

> Then generate the trusted key and configure policydigest and get the 
> key ID:
> $ keyctl add trusted kmk "new 32 keyhandle=0x81000001 hash=sha256 
> policydigest=`cat pcr7.policy`" @u
> 874117045
> 
> Save the trusted key. 
> $ keyctl pipe 874117045 > kmk.blob
> 
> Reboot and load the key. 
> Start a auth session to generate the policy:
> $ tpm2_startauthsession -S session.ctx
> session-handle: 0x3000000
> $ tpm2_pcrlist -L sha256:7 -o pcr7.sha256 $ tpm2_policypcr -S 
> session.ctx -L sha256:7 -F pcr7.sha256 -f pcr7.policy
> policy-digest:
> 0x321FBD28B60FCC23017D501B133BD5DBF2889814588E8A23510FE10105CB2CC9
> 
> Input the policy handle to load trusted key:
> $ keyctl add trusted kmk "load `cat kmk.blob` keyhandle=0x81000001 
> policyhandle=0x3000000" @u
> add_key: Operation not permitted
> 
> The error should be policy check failed, because I use TPM command to 
> unseal directly with error of policy check failed.
> $ tpm2_unseal -c 0x81000001 -L sha256:7 ERROR on line: "81" in file: 
> "./lib/log.h": Tss2_Sys_Unseal(0x99D) - tpm:session(1):a policy check 
> failed ERROR on line: "213" in file:
> "tools/tpm2_unseal.c": Unseal failed!
> ERROR on line: "166" in file: "tools/tpm2_tool.c": Unable to run 
> tpm2_unseal
> 
> - Shirley
> 
> -----Original Message-----
> From: James Bottomley <jejb@linux.ibm.com>
> Sent: Monday, December 2, 2019 12:17 PM
> To: Zhao, Shirley <shirley.zhao@intel.com>; Mimi Zohar <zohar@linux.i 
> bm.com>; Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>; Jonathan 
> Corbet <corbet@lwn.net>
> Cc: linux-integrity@vger.kernel.org; keyrings@vger.kernel.org; linux- 
> doc@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>
> Subject: Re: One question about trusted key of keyring in Linux 
> kernel.
> 
> On Mon, 2019-12-02 at 01:44 +0000, Zhao, Shirley wrote:
> > Hi, James,
> > 
> > The value of PCR7 is not changed. I have checked it with TPM command 
> > tpm_pcrlist.
> > 
> > So I think the problem is how to use the option policydigest and 
> > policyhandle? Is there any example?
> > Maybe the format in my command is not correct. 
> 
> OK, so previously you said that using the Intel TSS the policy also 
> failed after a reboot:
> 
> > The error should be policy check failed, because I use TPM command 
> > to unseal directly with error of policy check failed.
> > $ tpm2_unseal -c 0x81000001 -L sha256:7 ERROR on line: "81" in
> > file: 
> > "./lib/log.h": Tss2_Sys_Unseal(0x99D) - tpm:session(1):a policy 
> > check failed ERROR on line: "213" in file: "tools/tpm2_unseal.c": 
> > Unseal failed!
> > ERROR on line: "166" in file: "tools/tpm2_tool.c": Unable to run 
> > tpm2_unseal
> 
> So this must mean the actual policy hash you constructed was wrong in 
> some way: it didn't correspond simply to a value of pcr7 ... well 
> assuming the -L sha256:7 means construct a policy of the sha256 value 
> of pcr7 and use it in the unseal.
> 
> I can tell you how to construct policies using TPM2 commands, but I 
> think you want to know how to do it using the Intel TSS?  In which 
> case you really need to consult the experts in that TSS, like Phil 
> Tricca.
> 
> For the plain TPM2 case, the policy looks like
> 
> TPM_CC_PolicyPCR || pcrs || pcrDigest
> 
> Where TPM_CC_PolicyPCR = 0000017f and for selecting pcr7 only.  pcrs 
> is a complicated entity: it's a counted array of pcr selections.  For 
> your policy you only need one entry, so it would be 00000001 followed 
> by a single pcrSelection entry.  pcrSelection is the hash algorithm, 
> the size of the selection bitmap (always 3 since every current TPM 
> only has
> 24 PCRs) and a bitmap selecting the PCRs in big endian format, so for
> PCR7 using sha256 (algorithm 000b), pcrSelection = 000b 03 80 00 00. 
> And then you follow this by the hash of the PCR value you're looking 
> for.  The policyhash becomes the initial policy (all zeros for the 
> start of the policy chain) hashed with this.
> 
> Regards,
> 
> James
> 

Re: One question about trusted key of keyring in Linux kernel.

[James Bottomley]

On Mon, 2019-12-02 at 06:23 +0000, Zhao, Shirley wrote:
> Hi, James, 
> 
> The PCR7 value and PCR7 policy is as below, please review, thanks. 
> 
> # tpm2_pcrlist -L sha256:7 -o pcr7_2.sha256
> sha256:
>   7 :
> 0x061AAD0705A62361AD18E58B65D3D7383F4D10F7F5A7E78924BE057AC6797408
> 
> # tpm2_createpolicy --policy-pcr --pcr-list sha256:7 --policy
> pcr7_bin.policy > pcr7.policy
> 321fbd28b60fcc23017d501b133bd5dbf2889814588e8a23510fe10105cb2cc9
> 
> # cat pcr7.policy
> 321fbd28b60fcc23017d501b133bd5dbf2889814588e8a23510fe10105cb2cc9

Well, the IBM TSS says that's the correct policy.  Your policy command
is

jejb@jarvis:~> tsspolicymakerpcr -bm 000080 -if ~/pcr7.txt -pr | tee tmp.policy
0000017f00000001000b038000009a47350fdbcc77ebeadcb4b4818d8e82a21717ea24434333c791c0cd0d1dc14e

And that hashes to
jejb@jarvis:~> tsspolicymaker -if ~/tmp.policy  -pr
 policy digest length 32
 32 1f bd 28 b6 0f cc 23 01 7d 50 1b 13 3b d5 db 
 f2 88 98 14 58 8e 8a 23 51 0f e1 01 05 cb 2c c9 

So I don't understand why the userspace Intel TSS command is failing to
do the unseal.

James

RE: One question about trusted key of keyring in Linux kernel.

[Zhao, Shirley]

So I guess mostly like, it is the format of policydigest, policyhandle is not correctly in my keyctl command. 
But what is the correct using?

My keyctl commands are attached as below: 
$ keyctl add trusted kmk "new 32 keyhandle=0x81000001 hash=sha256 policydigest=`cat pcr7.policy`" @u
874117045

Save the trusted key. 
$ keyctl pipe 874117045 > kmk.blob

Reboot and load the key. 
Start a auth session to generate the policy:
$ tpm2_startauthsession -S session.ctx
session-handle: 0x3000000
$ tpm2_pcrlist -L sha256:7 -o pcr7.sha256 $ tpm2_policypcr -S session.ctx -L sha256:7 -F pcr7.sha256 -f pcr7.policy
policy-digest: 0x321FBD28B60FCC23017D501B133BD5DBF2889814588E8A23510FE10105CB2CC9

Input the policy handle to load trusted key:
$ keyctl add trusted kmk "load `cat kmk.blob` keyhandle=0x81000001 policyhandle=0x3000000" @u
add_key: Operation not permitted


Thanks. 

- Shirley 


-----Original Message-----
From: James Bottomley <jejb@linux.ibm.com> 
Sent: Monday, December 2, 2019 2:45 PM
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; keyrings@vger.kernel.org; linux-doc@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>
Subject: Re: One question about trusted key of keyring in Linux kernel.

On Mon, 2019-12-02 at 06:23 +0000, Zhao, Shirley wrote:
> Hi, James,
> 
> The PCR7 value and PCR7 policy is as below, please review, thanks. 
> 
> # tpm2_pcrlist -L sha256:7 -o pcr7_2.sha256
> sha256:
>   7 :
> 0x061AAD0705A62361AD18E58B65D3D7383F4D10F7F5A7E78924BE057AC6797408
> 
> # tpm2_createpolicy --policy-pcr --pcr-list sha256:7 --policy 
> pcr7_bin.policy > pcr7.policy
> 321fbd28b60fcc23017d501b133bd5dbf2889814588e8a23510fe10105cb2cc9
> 
> # cat pcr7.policy
> 321fbd28b60fcc23017d501b133bd5dbf2889814588e8a23510fe10105cb2cc9

Well, the IBM TSS says that's the correct policy.  Your policy command is

jejb@jarvis:~> tsspolicymakerpcr -bm 000080 -if ~/pcr7.txt -pr | tee tmp.policy 0000017f00000001000b038000009a47350fdbcc77ebeadcb4b4818d8e82a21717ea24434333c791c0cd0d1dc14e

And that hashes to
jejb@jarvis:~> tsspolicymaker -if ~/tmp.policy  -pr  policy digest length 32
 32 1f bd 28 b6 0f cc 23 01 7d 50 1b 13 3b d5 db
 f2 88 98 14 58 8e 8a 23 51 0f e1 01 05 cb 2c c9 

So I don't understand why the userspace Intel TSS command is failing to do the unseal.

James

Re: One question about trusted key of keyring in Linux kernel.

[James Bottomley]

On Mon, 2019-12-02 at 06:50 +0000, Zhao, Shirley wrote:
> So I guess mostly like, it is the format of policydigest,
> policyhandle is not correctly in my keyctl command. 
> But what is the correct using?
> 
> My keyctl commands are attached as below: 
> $ keyctl add trusted kmk "new 32 keyhandle=0x81000001 hash=sha256
> policydigest=`cat pcr7.policy`" @u
> 874117045
> 
> Save the trusted key. 
> $ keyctl pipe 874117045 > kmk.blob

OK, looking at the actual code, it seems that whoever wrote it didn't
account for the differences between TPM1.2 and TPM2.0.  With TPM2.0
TPM2_Create returns the public and private parts plus three other tpm2b
entites used to certify and check the key.  When you load the blob back
using TPM2_Load, it only accepts the public and private parts. 
However, your blob contains the other extraneous elements, that's why
it can't be loaded.  You could make it loadable by stripping off the
extraneous pieces ... just take the first two tpm2b elements of the
blob but it looks like we need to fix the API.  I suppose the good news
is given this failure that we have the opportunity to rewrite the API
since no-one else can have used it for anything because of this.  The
fundamental problem with the current API is that most TPM2's only have
three available session registers.  It's simply not scalable to set
them up in userspace and have the kernel use them, so what we should be
doing is passing down the actual policy and having the kernel construct
the session at the point of use and then flush it, thus solving the
potential session exhaustion issue.

I'd actually propose we make a TSSLOADABLE the fundamental element of
operation for trusted keys.  The IBM and Intel TSS people have agreed
to do this as the format for TPM loadable keys, but it should also
apply to sealed data.  The beauty of TSSLOADABLE is that the ASN.1
format includes a policy specification:

/*
 * TSSLOADABLE ::= SEQUENCE {
 *	type		OBJECT IDENTIFIER
 *	emptyAuth	[0] EXPLICIT BOOLEAN OPTIONAL
 *	policy		[1] EXPLICIT SEQUENCE OF TPMPolicy OPTIONAL
 *	secret		[2] EXPLICIT OCTET STRING OPTIONAL
 *	parent		INTEGER
 *	pubkey		OCTET STRING
 *	privkey		OCTET STRING
 * }
 * TPMPolicy ::= SEQUENCE {
 *	CommandCode		[0] EXPLICIT INTEGER
 *	CommandPolicy		[1] EXPLICIT OCTET STRING
 * }
 */

James

RE: One question about trusted key of keyring in Linux kernel.

[Zhao, Shirley]

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/Documentation/security/keys/trusted-encrypted.rst and 
https://github.com/zfsonlinux/dracut/tree/master/modules.d/97masterkey, the trusted key is a random number and generated by TPM2.0 and sealed with TPM2.0 2048 RSA 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

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().

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

I am not sure whether it is correct. 

Thanks. 

- Shirley 


-----Original Message-----
From: James Bottomley <jejb@linux.ibm.com> 
Sent: Tuesday, December 3, 2019 2:56 AM
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; keyrings@vger.kernel.org; linux-doc@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>
Subject: Re: One question about trusted key of keyring in Linux kernel.

On Mon, 2019-12-02 at 06:50 +0000, Zhao, Shirley wrote:
> So I guess mostly like, it is the format of policydigest, policyhandle 
> is not correctly in my keyctl command.
> But what is the correct using?
> 
> My keyctl commands are attached as below: 
> $ keyctl add trusted kmk "new 32 keyhandle=0x81000001 hash=sha256 
> policydigest=`cat pcr7.policy`" @u
> 874117045
> 
> Save the trusted key. 
> $ keyctl pipe 874117045 > kmk.blob

OK, looking at the actual code, it seems that whoever wrote it didn't account for the differences between TPM1.2 and TPM2.0.  With TPM2.0 TPM2_Create returns the public and private parts plus three other tpm2b entites used to certify and check the key.  When you load the blob back using TPM2_Load, it only accepts the public and private parts. 
However, your blob contains the other extraneous elements, that's why it can't be loaded.  You could make it loadable by stripping off the extraneous pieces ... just take the first two tpm2b elements of the blob but it looks like we need to fix the API.  I suppose the good news is given this failure that we have the opportunity to rewrite the API since no-one else can have used it for anything because of this.  The fundamental problem with the current API is that most TPM2's only have three available session registers.  It's simply not scalable to set them up in userspace and have the kernel use them, so what we should be doing is passing down the actual policy and having the kernel construct the session at the point of use and then flush it, thus solving the potential session exhaustion issue.

I'd actually propose we make a TSSLOADABLE the fundamental element of operation for trusted keys.  The IBM and Intel TSS people have agreed to do this as the format for TPM loadable keys, but it should also apply to sealed data.  The beauty of TSSLOADABLE is that the ASN.1 format includes a policy specification:

/*
 * TSSLOADABLE ::= SEQUENCE {
 *	type		OBJECT IDENTIFIER
 *	emptyAuth	[0] EXPLICIT BOOLEAN OPTIONAL
 *	policy		[1] EXPLICIT SEQUENCE OF TPMPolicy OPTIONAL
 *	secret		[2] EXPLICIT OCTET STRING OPTIONAL
 *	parent		INTEGER
 *	pubkey		OCTET STRING
 *	privkey		OCTET STRING
 * }
 * TPMPolicy ::= SEQUENCE {
 *	CommandCode		[0] EXPLICIT INTEGER
 *	CommandPolicy		[1] EXPLICIT OCTET STRING
 * }
 */

James

Re: One question about trusted key of keyring in Linux kernel.

[James Bottomley]

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

RE: One question about trusted key of keyring in Linux kernel.

[Zhao, Shirley]

Hi, James, 

Using policy digest to reload trusted key, doesn't work, either. 
Please check the steps below. 
I think policy digest should be calculated by TPM when verifying the policy to reload key. 

/////// build policy
# tpm2_pcrlist -L sha256:7 -o pcr7.sha256
sha256:
  7 : 0x061AAD0705A62361AD18E58B65D3D7383F4D10F7F5A7E78924BE057AC6797408
# tpm2_createpolicy --policy-pcr --pcr-list sha256:7 --policy pcr7_bin.policy > pcr7.policy
# cat pcr7.policy
321fbd28b60fcc23017d501b133bd5dbf2889814588e8a23510fe10105cb2cc9

/////// new trusted key and use policy to protect
# keyctl add trusted kmk "new 32 keyhandle=0x81000001 hash=sha256 policydigest=`cat pcr7.policy`" @u
466107578
# keyctl pipe 466107578 > kmk.blob
# keyctl print 466107578
007f0020a922ca764d3ae9feae4c3a1b140c610ad1df836df6d7054957f3f5da14042f290010d3ca83aca08ed10a433ba585a5147126d207f0c52e53a1edbfc31b89b30988053870553ef692c77c28b2c7adb63e1fc69869d7f2e8ab2b9d8906e02bd953dc58c3a5b1de0858ec38a6dcb551384f38d6834842fd22b4a9c61c0320004e0008000b000000000020321fbd28b60fcc23017d501b133bd5dbf2889814588e8a23510fe10105cb2cc9001000200280321810a66df63905d4846e39e6ad3ec69b77deac339f4209f291078483c10073000000000020e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b85501000b0022000bdcdb694e102e13a0fba5111081cb6cf616c118d404936cac3e84db24c71e47d50022000b04b5db1aa52635dfb242e76f6bde8e2176ae48fc682946c6c76d96f608079d1f0000002036b6fcca8206c7f722de85821d7ecb4785976fdd642bc7538505a2a818c8a238802140000001002014b439da9b9490d9bb6e5a93e7e6ed408b1d51ae45abccd5d5dcc625d968282d
# cat kmk.blob
007f0020a922ca764d3ae9feae4c3a1b140c610ad1df836df6d7054957f3f5da14042f290010d3ca83aca08ed10a433ba585a5147126d207f0c52e53a1edbfc31b89b30988053870553ef692c77c28b2c7adb63e1fc69869d7f2e8ab2b9d8906e02bd953dc58c3a5b1de0858ec38a6dcb551384f38d6834842fd22b4a9c61c0320004e0008000b000000000020321fbd28b60fcc23017d501b133bd5dbf2889814588e8a23510fe10105cb2cc9001000200280321810a66df63905d4846e39e6ad3ec69b77deac339f4209f291078483c10073000000000020e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b85501000b0022000bdcdb694e102e13a0fba5111081cb6cf616c118d404936cac3e84db24c71e47d50022000b04b5db1aa52635dfb242e76f6bde8e2176ae48fc682946c6c76d96f608079d1f0000002036b6fcca8206c7f722de85821d7ecb4785976fdd642bc7538505a2a818c8a238802140000001002014b439da9b9490d9bb6e5a93e7e6ed408b1d51ae45abccd5d5dcc625d968282d

//////////clear trusted key and reload
# keyctl clear @u
keyctl list @u
keyring is empty
# keyctl add trusted kmk "load `cat kmk.blob` keyhandle=0x81000001 hash=sha256 policydigest=`cat pcr7.policy`" @u
add_key: Operation not permitted


Thanks. 

- Shirley 

-----Original Message-----
From: James Bottomley <jejb@linux.ibm.com> 
Sent: Tuesday, December 3, 2019 11:12 AM
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; keyrings@vger.kernel.org; linux-doc@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>
Subject: Re: One question about trusted key of keyring in Linux kernel.

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

Re: One question about trusted key of keyring in Linux kernel.

[James Bottomley]

On Wed, 2019-12-04 at 03:01 +0000, Zhao, Shirley wrote:
> Hi, James, 
> 
> Using policy digest to reload trusted key, doesn't work, either. 
> Please check the steps below. 
> I think policy digest should be calculated by TPM when verifying the
> policy to reload key. 

You misunderstand my meaning: the API we have now doesn't work; the key
blob the kernel returns currently after key create won't reload because
it contains extraneous data.  I was proposing a working API I thought
might replace it, but obviously it has to be coded up and accepted into
a kernel version before you can use it.

If you want to get trusted keys working today, I think the TPM 1.2 API
still works if you have a TPM 1.2 system.

James

RE: One question about trusted key of keyring in Linux kernel.

[Zhao, Shirley]

Oh, get you, James. 
Understand, thanks for your feedback. 
Looking forward for your proposed API. 

- Shirley 

-----Original Message-----
From: James Bottomley <jejb@linux.ibm.com> 
Sent: Wednesday, December 4, 2019 11:33 AM
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; keyrings@vger.kernel.org; linux-doc@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>
Subject: Re: One question about trusted key of keyring in Linux kernel.

On Wed, 2019-12-04 at 03:01 +0000, Zhao, Shirley wrote:
> Hi, James,
> 
> Using policy digest to reload trusted key, doesn't work, either. 
> Please check the steps below. 
> I think policy digest should be calculated by TPM when verifying the 
> policy to reload key.

You misunderstand my meaning: the API we have now doesn't work; the key blob the kernel returns currently after key create won't reload because it contains extraneous data.  I was proposing a working API I thought might replace it, but obviously it has to be coded up and accepted into a kernel version before you can use it.

If you want to get trusted keys working today, I think the TPM 1.2 API still works if you have a TPM 1.2 system.

James

Re: One question about trusted key of keyring in Linux kernel.

[Jarkko Sakkinen]

On Mon, Dec 02, 2019 at 01:45:30AM +0000, Zhao, Shirley wrote:
> Hi, Jarkko, 
> 
> The rc1 you mentioned is the version for what? 
> How to download it and update it? 
> 
> Thanks. 

It will be available from kernel.org eventually.

/Jarkko

Re: One question about trusted key of keyring in Linux kernel.

[Jarkko Sakkinen]

On Mon, Dec 02, 2019 at 10:55:32AM -0800, James Bottomley wrote:
> blob but it looks like we need to fix the API.  I suppose the good news
> is given this failure that we have the opportunity to rewrite the API
> since no-one else can have used it for anything because of this.  The

I did successfully run this test when I wrote it 5 years ago:

https://github.com/jsakkine-intel/tpm2-scripts/blob/master/keyctl-smoke.sh

Given that there is API a way must be found that backwards compatibility
is not broken. New format is fine but it must co-exist.

/Jarkko

Re: One question about trusted key of keyring in Linux kernel.

[James Bottomley]

On Mon, 2019-12-09 at 21:47 +0200, Jarkko Sakkinen wrote:
> On Mon, Dec 02, 2019 at 10:55:32AM -0800, James Bottomley wrote:
> > blob but it looks like we need to fix the API.  I suppose the good
> > news is given this failure that we have the opportunity to rewrite
> > the API since no-one else can have used it for anything because of
> > this.  The
> 
> I did successfully run this test when I wrote it 5 years ago:
> 
> https://github.com/jsakkine-intel/tpm2-scripts/blob/master/keyctl-smo
> ke.sh
> 
> Given that there is API a way must be found that backwards
> compatibility
> is not broken. New format is fine but it must co-exist.

The old API is unsupportable in the combination of policy + auth as I
already explained.  The kernel doesn't have access to the nonces to
generate the HMAC because the session was created by the user and the
API has no way to pass them in (plus passing them in would be a huge
security failure if we tried).  Given that Shirley appears to be the
first person ever to try this, I don't think the old API has grown any
policy users so its safe to remove it.  If we get a complaint, we can
discuss adding it back.

James

Re: One question about trusted key of keyring in Linux kernel.

[Mimi Zohar]

On Mon, 2019-12-09 at 21:47 +0200, Jarkko Sakkinen wrote:
> On Mon, Dec 02, 2019 at 10:55:32AM -0800, James Bottomley wrote:
> > blob but it looks like we need to fix the API.  I suppose the good news
> > is given this failure that we have the opportunity to rewrite the API
> > since no-one else can have used it for anything because of this.  The
> 
> I did successfully run this test when I wrote it 5 years ago:
> 
> https://github.com/jsakkine-intel/tpm2-scripts/blob/master/keyctl-smoke.sh

Thanks, Jarkko.  Is this test still working or is there a regression?

Mimi

Re: One question about trusted key of keyring in Linux kernel.

[Jarkko Sakkinen]

On Mon, Dec 09, 2019 at 04:18:54PM -0500, Mimi Zohar wrote:
> On Mon, 2019-12-09 at 21:47 +0200, Jarkko Sakkinen wrote:
> > On Mon, Dec 02, 2019 at 10:55:32AM -0800, James Bottomley wrote:
> > > blob but it looks like we need to fix the API.  I suppose the good news
> > > is given this failure that we have the opportunity to rewrite the API
> > > since no-one else can have used it for anything because of this.  The
> > 
> > I did successfully run this test when I wrote it 5 years ago:
> > 
> > https://github.com/jsakkine-intel/tpm2-scripts/blob/master/keyctl-smoke.sh
> 
> Thanks, Jarkko.  Is this test still working or is there a regression?

I will run it and in addition to that I will make a patch out of it.

Any suggestions for the script name (should probably have 'tpm2' in
it at least)?

/Jarkko

Re: One question about trusted key of keyring in Linux kernel.

[Jarkko Sakkinen]

On Mon, Dec 09, 2019 at 12:31:53PM -0800, James Bottomley wrote:
> On Mon, 2019-12-09 at 21:47 +0200, Jarkko Sakkinen wrote:
> > On Mon, Dec 02, 2019 at 10:55:32AM -0800, James Bottomley wrote:
> > > blob but it looks like we need to fix the API.  I suppose the good
> > > news is given this failure that we have the opportunity to rewrite
> > > the API since no-one else can have used it for anything because of
> > > this.  The
> > 
> > I did successfully run this test when I wrote it 5 years ago:
> > 
> > https://github.com/jsakkine-intel/tpm2-scripts/blob/master/keyctl-smo
> > ke.sh
> > 
> > Given that there is API a way must be found that backwards
> > compatibility
> > is not broken. New format is fine but it must co-exist.
> 
> The old API is unsupportable in the combination of policy + auth as I
> already explained.  The kernel doesn't have access to the nonces to
> generate the HMAC because the session was created by the user and the
> API has no way to pass them in (plus passing them in would be a huge
> security failure if we tried).  Given that Shirley appears to be the
> first person ever to try this, I don't think the old API has grown any
> policy users so its safe to remove it.  If we get a complaint, we can
> discuss adding it back.

It works within limits so it can be definitely be maintained for
backwards compatibility.

Also, you are making a claim of the users that we cannot verify.

Finally, the new feature neither handles sessions. You claim that
it could be added later. I have to deny that because until session
handling is there we have no ways to be sure about that.

I see your point but this needs more consideration. It does not
make sense to rush.

/Jarkko

Re: One question about trusted key of keyring in Linux kernel.

[Jarkko Sakkinen]

On Wed, Dec 11, 2019 at 07:23:59PM +0200, Jarkko Sakkinen wrote:
> On Mon, Dec 09, 2019 at 12:31:53PM -0800, James Bottomley wrote:
> > On Mon, 2019-12-09 at 21:47 +0200, Jarkko Sakkinen wrote:
> > > On Mon, Dec 02, 2019 at 10:55:32AM -0800, James Bottomley wrote:
> > > > blob but it looks like we need to fix the API.  I suppose the good
> > > > news is given this failure that we have the opportunity to rewrite
> > > > the API since no-one else can have used it for anything because of
> > > > this.  The
> > > 
> > > I did successfully run this test when I wrote it 5 years ago:
> > > 
> > > https://github.com/jsakkine-intel/tpm2-scripts/blob/master/keyctl-smo
> > > ke.sh
> > > 
> > > Given that there is API a way must be found that backwards
> > > compatibility
> > > is not broken. New format is fine but it must co-exist.
> > 
> > The old API is unsupportable in the combination of policy + auth as I
> > already explained.  The kernel doesn't have access to the nonces to
> > generate the HMAC because the session was created by the user and the
> > API has no way to pass them in (plus passing them in would be a huge
> > security failure if we tried).  Given that Shirley appears to be the
> > first person ever to try this, I don't think the old API has grown any
> > policy users so its safe to remove it.  If we get a complaint, we can
> > discuss adding it back.
> 
> It works within limits so it can be definitely be maintained for
> backwards compatibility.
> 
> Also, you are making a claim of the users that we cannot verify.
> 
> Finally, the new feature neither handles sessions. You claim that
> it could be added later. I have to deny that because until session
> handling is there we have no ways to be sure about that.
> 
> I see your point but this needs more consideration. It does not
> make sense to rush.

Also can test the current patch set as soon as I've done with
release critical tpm_tis bug even if I don't agree on every
point.

/Jarkko

Re: One question about trusted key of keyring in Linux kernel.

[Jarkko Sakkinen]

On Wed, Dec 11, 2019 at 07:33:22PM +0200, Jarkko Sakkinen wrote:
> On Wed, Dec 11, 2019 at 07:23:59PM +0200, Jarkko Sakkinen wrote:
> > On Mon, Dec 09, 2019 at 12:31:53PM -0800, James Bottomley wrote:
> > > On Mon, 2019-12-09 at 21:47 +0200, Jarkko Sakkinen wrote:
> > > > On Mon, Dec 02, 2019 at 10:55:32AM -0800, James Bottomley wrote:
> > > > > blob but it looks like we need to fix the API.  I suppose the good
> > > > > news is given this failure that we have the opportunity to rewrite
> > > > > the API since no-one else can have used it for anything because of
> > > > > this.  The
> > > > 
> > > > I did successfully run this test when I wrote it 5 years ago:
> > > > 
> > > > https://github.com/jsakkine-intel/tpm2-scripts/blob/master/keyctl-smo
> > > > ke.sh
> > > > 
> > > > Given that there is API a way must be found that backwards
> > > > compatibility
> > > > is not broken. New format is fine but it must co-exist.
> > > 
> > > The old API is unsupportable in the combination of policy + auth as I
> > > already explained.  The kernel doesn't have access to the nonces to
> > > generate the HMAC because the session was created by the user and the
> > > API has no way to pass them in (plus passing them in would be a huge
> > > security failure if we tried).  Given that Shirley appears to be the
> > > first person ever to try this, I don't think the old API has grown any
> > > policy users so its safe to remove it.  If we get a complaint, we can
> > > discuss adding it back.
> > 
> > It works within limits so it can be definitely be maintained for
> > backwards compatibility.
> > 
> > Also, you are making a claim of the users that we cannot verify.
> > 
> > Finally, the new feature neither handles sessions. You claim that
> > it could be added later. I have to deny that because until session
> > handling is there we have no ways to be sure about that.
> > 
> > I see your point but this needs more consideration. It does not
> > make sense to rush.
> 
> Also can test the current patch set as soon as I've done with
> release critical tpm_tis bug even if I don't agree on every
> point.

E.g. I cannot do any good judgement on the options before I get
the feel to the code so please hold for a while until I get to
the point that I can run it.

/Jarkko