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.

[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.

[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]

VGhhbmtzIGZvciB5b3VyIGZlZWRiYWNrLCBNaW1pLiANCkJ1dCB0aGUgZG9jdW1lbnQgb2YgZHJh
Y3V0IGNhbid0IHNvbHZlIG15IHByb2JsZW0uIA0KDQpJIGRpZCBtb3JlIHRlc3QgdGhlc2UgZGF5
cyBhbmQgdHJ5IHRvIGRlc2NyaXB0IG15IHF1ZXN0aW9uIGluIG1vcmUgZGV0YWlsLiANCg0KSW4g
bXkgc2NlbmFyaW8sIHRoZSB0cnVzdGVkIGtleSB3aWxsIGJlIHNlYWxlZCBpbnRvIFRQTSB3aXRo
IFBDUiBwb2xpY3kuIA0KQW5kIHRoZXJlIGFyZSBzb21lIHJlbGF0ZWQgb3B0aW9ucyBpbiBtYW51
YWwgbGlrZSANCiAgICAgICBoYXNoPSAgICAgICAgIGhhc2ggYWxnb3JpdGhtIG5hbWUgYXMgYSBz
dHJpbmcuIEZvciBUUE0gMS54IHRoZSBvbmx5DQogICAgICAgICAgICAgICAgICAgICBhbGxvd2Vk
IHZhbHVlIGlzIHNoYTEuIEZvciBUUE0gMi54IHRoZSBhbGxvd2VkIHZhbHVlcw0KICAgICAgICAg
ICAgICAgICAgICAgYXJlIHNoYTEsIHNoYTI1Niwgc2hhMzg0LCBzaGE1MTIgYW5kIHNtMy0yNTYu
DQogICAgICAgcG9saWN5ZGlnZXN0PSBkaWdlc3QgZm9yIHRoZSBhdXRob3JpemF0aW9uIHBvbGlj
eS4gbXVzdCBiZSBjYWxjdWxhdGVkDQogICAgICAgICAgICAgICAgICAgICB3aXRoIHRoZSBzYW1l
IGhhc2ggYWxnb3JpdGhtIGFzIHNwZWNpZmllZCBieSB0aGUgJ2hhc2g9Jw0KICAgICAgICAgICAg
ICAgICAgICAgb3B0aW9uLg0KICAgICAgIHBvbGljeWhhbmRsZT0gaGFuZGxlIHRvIGFuIGF1dGhv
cml6YXRpb24gcG9saWN5IHNlc3Npb24gdGhhdCBkZWZpbmVzIHRoZQ0KICAgICAgICAgICAgICAg
ICAgICAgc2FtZSBwb2xpY3kgYW5kIHdpdGggdGhlIHNhbWUgaGFzaCBhbGdvcml0aG0gYXMgd2Fz
IHVzZWQgdG8NCiAgICAgICAgICAgICAgICAgICAgIHNlYWwgdGhlIGtleS4gDQoNCkhlcmUgaXMg
bXkgdGVzdCBzdGVwLiANCkZpcnN0bHksIHRoZSBwY3IgcG9saWN5IGlzIGdlbmVyYXRlZCBhcyBi
ZWxvdzogDQokIHRwbTJfY3JlYXRlcG9saWN5IC0tcG9saWN5LXBjciAtLXBjci1saXN0IHNoYTI1
Njo3IC0tcG9saWN5IHBjcjdfYmluLnBvbGljeSA+IHBjcjcucG9saWN5DQoNClBjcjcucG9saWN5
IGlzIHRoZSBhc2NpaSBoZXggb2YgcG9saWN5Og0KJCBjYXQgcGNyNy5wb2xpY3kNCjMyMWZiZDI4
YjYwZmNjMjMwMTdkNTAxYjEzM2JkNWRiZjI4ODk4MTQ1ODhlOGEyMzUxMGZlMTAxMDVjYjJjYzkN
Cg0KVGhlbiBnZW5lcmF0ZSB0aGUgdHJ1c3RlZCBrZXkgYW5kIGNvbmZpZ3VyZSBwb2xpY3lkaWdl
c3QgYW5kIGdldCB0aGUga2V5IElEOiANCiQga2V5Y3RsIGFkZCB0cnVzdGVkIGttayAibmV3IDMy
IGtleWhhbmRsZT0weDgxMDAwMDAxIGhhc2g9c2hhMjU2IHBvbGljeWRpZ2VzdD1gY2F0IHBjcjcu
cG9saWN5YCIgQHUNCjg3NDExNzA0NQ0KDQpTYXZlIHRoZSB0cnVzdGVkIGtleS4gDQokIGtleWN0
bCBwaXBlIDg3NDExNzA0NSA+IGttay5ibG9iDQoNClJlYm9vdCBhbmQgbG9hZCB0aGUga2V5LiAN
ClN0YXJ0IGEgYXV0aCBzZXNzaW9uIHRvIGdlbmVyYXRlIHRoZSBwb2xpY3k6DQokIHRwbTJfc3Rh
cnRhdXRoc2Vzc2lvbiAtUyBzZXNzaW9uLmN0eA0Kc2Vzc2lvbi1oYW5kbGU6IDB4MzAwMDAwMA0K
JCB0cG0yX3Bjcmxpc3QgLUwgc2hhMjU2OjcgLW8gcGNyNy5zaGEyNTYNCiQgdHBtMl9wb2xpY3lw
Y3IgLVMgc2Vzc2lvbi5jdHggLUwgc2hhMjU2OjcgLUYgcGNyNy5zaGEyNTYgLWYgcGNyNy5wb2xp
Y3kNCnBvbGljeS1kaWdlc3Q6IDB4MzIxRkJEMjhCNjBGQ0MyMzAxN0Q1MDFCMTMzQkQ1REJGMjg4
OTgxNDU4OEU4QTIzNTEwRkUxMDEwNUNCMkNDOQ0KDQpJbnB1dCB0aGUgcG9saWN5IGhhbmRsZSB0
byBsb2FkIHRydXN0ZWQga2V5Og0KJCBrZXljdGwgYWRkIHRydXN0ZWQga21rICJsb2FkIGBjYXQg
a21rLmJsb2JgIGtleWhhbmRsZT0weDgxMDAwMDAxIHBvbGljeWhhbmRsZT0weDMwMDAwMDAiIEB1
DQphZGRfa2V5OiBPcGVyYXRpb24gbm90IHBlcm1pdHRlZA0KDQpUaGUgZXJyb3Igc2hvdWxkIGJl
IHBvbGljeSBjaGVjayBmYWlsZWQsIGJlY2F1c2UgSSB1c2UgVFBNIGNvbW1hbmQgdG8gdW5zZWFs
IGRpcmVjdGx5IHdpdGggZXJyb3Igb2YgcG9saWN5IGNoZWNrIGZhaWxlZC4gDQokIHRwbTJfdW5z
ZWFsIC1jIDB4ODEwMDAwMDEgLUwgc2hhMjU2OjcNCkVSUk9SIG9uIGxpbmU6ICI4MSIgaW4gZmls
ZTogIi4vbGliL2xvZy5oIjogVHNzMl9TeXNfVW5zZWFsKDB4OTlEKSAtIHRwbTpzZXNzaW9uKDEp
OmEgcG9saWN5IGNoZWNrIGZhaWxlZA0KRVJST1Igb24gbGluZTogIjIxMyIgaW4gZmlsZTogInRv
b2xzL3RwbTJfdW5zZWFsLmMiOiBVbnNlYWwgZmFpbGVkIQ0KRVJST1Igb24gbGluZTogIjE2NiIg
aW4gZmlsZTogInRvb2xzL3RwbTJfdG9vbC5jIjogVW5hYmxlIHRvIHJ1biB0cG0yX3Vuc2VhbA0K
DQpTbyBteSBxdWVzdGlvbiBpczoNCjEuIEhvdyB0byB1c2UgdGhlIG9wdGlvbiwgcG9saWN5ZGln
ZXN0LCBwb2xpY3loYW5kbGU/PyBJcyB0aGVyZSBhbnkgZXhhbXBsZT8gDQoyLiBXaGF0J3Mgd3Jv
bmcgd2l0aCBteSB0ZXN0IHN0ZXA/IA0KDQpUaGFua3MuIA0KDQotIFNoaXJsZXkgDQoNCg0KDQot
LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTWltaSBab2hhciA8em9oYXJAbGludXgu
aWJtLmNvbT4gDQpTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDEzLCAyMDE5IDExOjQ2IFBNDQpU
bzogWmhhbywgU2hpcmxleSA8c2hpcmxleS56aGFvQGludGVsLmNvbT47IEphbWVzIEJvdHRvbWxl
eSA8amVqYkBsaW51eC5pYm0uY29tPjsgSmFya2tvIFNha2tpbmVuIDxqYXJra28uc2Fra2luZW5A
bGludXguaW50ZWwuY29tPjsgSm9uYXRoYW4gQ29yYmV0IDxjb3JiZXRAbHduLm5ldD4NCkNjOiBs
aW51eC1pbnRlZ3JpdHlAdmdlci5rZXJuZWwub3JnOyBrZXlyaW5nc0B2Z2VyLmtlcm5lbC5vcmc7
IGxpbnV4LWRvY0B2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7
ICdNYXVybyBDYXJ2YWxobyBDaGVoYWInIDxtY2hlaGFiK3NhbXN1bmdAa2VybmVsLm9yZz4NClN1
YmplY3Q6IFJlOiBPbmUgcXVlc3Rpb24gYWJvdXQgdHJ1c3RlZCBrZXkgb2Yga2V5cmluZyBpbiBM
aW51eCBrZXJuZWwuDQoNCk9uIFdlZCwgMjAxOS0xMS0xMyBhdCAwMToyMiArMDAwMCwgWmhhbywg
U2hpcmxleSB3cm90ZToNCj4gSGksIGFsbCwNCj4gDQo+IFRoaXMgaXMgU2hpcmxleSBmcm9tIElu
dGVsLiBJIGhhdmUgb25lIHF1ZXN0aW9uIGFib3V0IHRydXN0ZWQga2V5IG9mIA0KPiBrZXlyaW5n
IGluIGtlcm5lbC4gUGxlYXNlIGhlbHAuDQo+IA0KPiBBY2NvcmRpbmcgdGhlIHRvIGRlc2NyaXB0
aW9uIGluIGh0dHBzOi8vZ2l0aHViLmNvbS90b3J2YWxkcy9saW51eC9ibA0KPiBvYi9tYXN0ZXIv
RG9jdW1lbnRhdGlvbi9zZWN1cml0eS9rZXlzL3RydXN0ZWQtZW5jcnlwdGVkLnJzdC4NCj4gVHJ1
c3RlZCBrZXkgd2lsbCBiZSBzYXZlZCBpbiBUUE0gd2l0aCBQQ1IgcG9saWN5IHByb3RlY3RlZC4N
Cg0KIlRydXN0ZWQgS2V5cyB1c2UgYSBUUE0gYm90aCB0byBnZW5lcmF0ZSBhbmQgdG8gc2VhbCB0
aGUga2V5cy4gS2V5cyBhcmUgc2VhbGVkIHVuZGVyIGEgMjA0OCBiaXQgUlNBIGtleSBpbiB0aGUg
VFBNLCAuLi4iDQoNClRydXN0ZWQga2V5cyBhcmUgbm90IFRQTSBrZXlzLiDCoFRoZXkgYXJlIG5v
dCBzdG9yZWQgaW4gdGhlIFRQTS4NCg0KPiANCj4gVGhlbiwgSSBydW5uaW5nIHRoZSBmb2xsb3dp
bmcgY29tbWFuZCB0byBjcmVhdGUgYSB0cnVzdGVkIGtleS4NCj4ga2V5Y3RsIGFkZCB0cnVzdGVk
IHRlc3RfdHJ1c3RlZCAibmV3IDMyIGtleWhhbmRsZT0weDgxMDAwMDAxIiBAdQ0KPiANCj4gSSBh
bHNvIHRyaWVkIHRoZSBmb2xsb3dpbmcgY29tbWFuZCwgaXQgY2FuIGFkZCBvbmUgdHJ1c3RlZCBr
ZXksIHRvby4NCj4ga2V5Y3RsIGFkZCB0cnVzdGVkIHRlc3RfdHJ1c3RlZCAibmV3IDMyIGtleWhh
bmRsZT0weDgxMDAwMDAxIA0KPiBwY3JpbmZvPWBjYXQgcGNyNy5ibG9iYCIgQHUNCj4gDQo+IEJ1
dCBhZnRlciByZWJvb3QsIHRoaXMga2V5IHdpbGwgYmUgcmVtb3ZlZC4NCj4gSSBuZWVkIHRvIHJl
LWFkZGVkIGR1cmluZyBib290Lg0KDQpSaWdodCwgdGhleSBuZWVkIHRvIGJlIHJlLWxvYWRlZCBv
biBib290LiDCoFJlZmVyIHRvIHRoZSBkcmFjdXQgbW9kdWxlIC9tb2R1bGVzLmQvOTdtYXN0ZXJr
ZXkgZm9yIGxvYWRpbmcgYSB0cnVzdGVkIGtleSBkdXJpbmcgYm9vdC4NCg0KPiANCj4gVGhlbiB0
aGUgcXVlc3Rpb24gaXMgc2luY2UgdGhpcyBrZXkgaXMgc2F2ZWQgaW4gVFBNLCBob3cgdG8gZ2V0
IGl0IA0KPiBiYWNrIGZyb20gVFBNPw0KDQpUcnVzdGVkIGtleXMgYXJlIG5vdCBzdG9yZWQgaW4g
dGhlIFRQTS4gwqBSZWZlciB0byB0aGUgaW1hLWV2bS11dGlscyBSRUFETUUgZm9yIGV4YW1wbGVz
IG9mIGNyZWF0aW5nIGEgdHJ1c3RlZCBrZXkgKGttaykgYW5kIGFuIGVuY3J5cHRlZCBrZXkgKGV2
bS1rZXkpLg0KDQo+IA0KPiBGcm9tIHRoZSBkb2N1bWVudCwgSSBuZWVkIHRvIHVzZSAia2V5Y3Rs
IHBpcGUiIHRvIHNhdmUgdGhlIGtleSBpbnRvIGEgDQo+IGJsb2IsIHRoZW4gbG9hZCBpdC4NCj4g
QnV0IHRoZSBibG9iIGNvbnRlbmQga2V5IHRleHQsIGFuZCB0aGlzIGlzIGEgZmlsZSBvbiBoYXJk
IGRpc2ssIGl0IGlzIA0KPiBub3Qgc2FmZSB0byBwcm90ZWN0IHRoZSBrZXkuDQo+IA0KPiBTbyB3
aGF0IGNhbiBUUE0gZG8gaGVyZT8NCg0KVGhlIGhleCBhc2NpaSBlbmNvZGVkIHRydXN0ZWQga2V5
IGlzIHNlYWxlZCB1bmRlciB0aGUgVFBNIFNSSy4NCg0KTWltaQ0KDQo

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.

[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]

SGksIE1pbWksIA0KDQpBbnN3ZXIgeW91ciB0d28gcXVlc3Rpb25zOg0KDQoxLiBZZXMsIEkgaGF2
ZSB2ZXJpZmllZCB0cnVzdGVkIGtleSB3b3JrcyB3ZWxsIHdpdGhvdXQgUENSIHBvbGljeSBwcm90
ZWN0aW9uIGFzIGJlbG93OiANCiQga2V5Y3RsIGFkZCB0cnVzdGVkIGttayAibmV3IDMyIGtleWhh
bmRsZT0weDgxMDAwMDAxIiBAdQ0KMTA1NTI0MDkyOA0KJCBrZXljdGwgbGlzdCBAdQ0KMSBrZXlz
IGluIGtleXJpbmc6DQoxMDU1MjQwOTI4OiAtLWFsc3dydiAgICAgMCAgICAgMCB0cnVzdGVkOiBr
bWsNCiQga2V5Y3RsIHBpcGUgMTA1NTI0MDkyOCA+IGttay5ibG9iDQokIGNhdCBrbWsuYmxvYg0K
MDA3ZjAwMjBmZjgwOGJkOGI3MjM5MTk0ZTg5YWFjNmE5NWI0ZDIxMDExNDc0MmMyMGFmYTMzNDkz
ZjAwMmRmZmQwNjg1ZDUxMDAxMGMxMmQ3YWQ1MWViODNkNmQ5Mzg5NWRlMDY2YmYzZDM5NzE4Y2M1
MDNhZGI0ODAyY2IwODdiODhiMmZmZjRiMDQwZmUzYTJiZTZhM2Y4N2M2NzQ5ZDA4N2M5ZmI2ZTg3
MzRjYjIzZjQzOGQ2NDA4NzU4MWExM2JjODNkNWRjM2IwMjZlNzdhODk0ZWNlNjYyMGQwZWI4NWRm
NjQ0OWZmM2M2MDlmZDc3ZDVmMGNhZjc5YjQ1MzViMDAyZTAwMDgwMDBiMDAwMDAwNDAwMDAwMDAx
MDAwMjA5YTViMDBiMGQ1NThmY2Y5ZThjMDI5NTIyNzE1ZTZiNTkwNjM2NmVhZWM1ZjM0MzY3Yjhh
YjE2YzBmYjkwMDlhMDA3MzAwMDAwMDAwMDAyMGUzYjBjNDQyOThmYzFjMTQ5YWZiZjRjODk5NmZi
OTI0MjdhZTQxZTQ2NDliOTM0Y2E0OTU5OTFiNzg1MmI4NTUwMTAwMGIwMDIyMDAwYmRjZGI2OTRl
MTAyZTEzYTBmYmE1MTExMDgxY2I2Y2Y2MTZjMTE4ZDQwNDkzNmNhYzNlODRkYjI0YzcxZTQ3ZDUw
MDIyMDAwYjA0YjVkYjFhYTUyNjM1ZGZiMjQyZTc2ZjZiZGU4ZTIxNzZhZTQ4ZmM2ODI5NDZjNmM3
NmQ5NmY2MDgwNzlkMWYwMDAwMDAyMDM2YjZmY2NhODIwNmM3ZjcyMmRlODU4MjFkN2VjYjQ3ODU5
NzZmZGQ2NDJiYzc1Mzg1MDVhMmE4MThjOGEyMzg4MDIxNDAwMDAwMDEwMDIwMmFlZGRlNDUwOGY1
NDhkMTA4MTkzZWM4ZmUxNjZhN2JlZmRlMTkxMTNmZTcyN2FlMmIyOTkwMWJkZWNlOTZlNQ0KJCBr
ZXljdGwgY2xlYXIgQHUNCiQga2V5Y3RsIGxpc3QgQHUNCmtleXJpbmcgaXMgZW1wdHkNCiQga2V5
Y3RsIGFkZCB0cnVzdGVkIGttayAibG9hZCBgY2F0IGttay5ibG9iYCBrZXloYW5kbGU9MHg4MTAw
MDAwMSIgQHUNCjEwMjI5NjM3MzENCiQga2V5Y3RsIHByaW50IDEwMjI5NjM3MzENCjAwN2YwMDIw
ZmY4MDhiZDhiNzIzOTE5NGU4OWFhYzZhOTViNGQyMTAxMTQ3NDJjMjBhZmEzMzQ5M2YwMDJkZmZk
MDY4NWQ1MTAwMTBjMTJkN2FkNTFlYjgzZDZkOTM4OTVkZTA2NmJmM2QzOTcxOGNjNTAzYWRiNDgw
MmNiMDg3Yjg4YjJmZmY0YjA0MGZlM2EyYmU2YTNmODdjNjc0OWQwODdjOWZiNmU4NzM0Y2IyM2Y0
MzhkNjQwODc1ODFhMTNiYzgzZDVkYzNiMDI2ZTc3YTg5NGVjZTY2MjBkMGViODVkZjY0NDlmZjNj
NjA5ZmQ3N2Q1ZjBjYWY3OWI0NTM1YjAwMmUwMDA4MDAwYjAwMDAwMDQwMDAwMDAwMTAwMDIwOWE1
YjAwYjBkNTU4ZmNmOWU4YzAyOTUyMjcxNWU2YjU5MDYzNjZlYWVjNWYzNDM2N2I4YWIxNmMwZmI5
MDA5YTAwNzMwMDAwMDAwMDAwMjBlM2IwYzQ0Mjk4ZmMxYzE0OWFmYmY0Yzg5OTZmYjkyNDI3YWU0
MWU0NjQ5YjkzNGNhNDk1OTkxYjc4NTJiODU1MDEwMDBiMDAyMjAwMGJkY2RiNjk0ZTEwMmUxM2Ew
ZmJhNTExMTA4MWNiNmNmNjE2YzExOGQ0MDQ5MzZjYWMzZTg0ZGIyNGM3MWU0N2Q1MDAyMjAwMGIw
NGI1ZGIxYWE1MjYzNWRmYjI0MmU3NmY2YmRlOGUyMTc2YWU0OGZjNjgyOTQ2YzZjNzZkOTZmNjA4
MDc5ZDFmMDAwMDAwMjAzNmI2ZmNjYTgyMDZjN2Y3MjJkZTg1ODIxZDdlY2I0Nzg1OTc2ZmRkNjQy
YmM3NTM4NTA1YTJhODE4YzhhMjM4ODAyMTQwMDAwMDAxMDAyMDJhZWRkZTQ1MDhmNTQ4ZDEwODE5
M2VjOGZlMTY2YTdiZWZkZTE5MTEzZmU3MjdhZTJiMjk5MDFiZGVjZTk2ZTUNCg0KMi4gVGhlIGZv
bGxvd2luZyBrZXJuZWwgZmlsZSBpcyByZWxhdGVkIHdpdGggdGhpcyBwcm9ibGVtLiANCi9zZWN1
cml0eS9rZXlzL2tleWN0bC5jDQovc2VjdXJpdHkva2V5cy9rZXkuYw0KL3NlY3VyaXR5L2tleXMv
dHJ1c3RlZC1rZXlzL3RydXN0ZWRfdHBtMS5jDQovc2VjdXJpdHkva2V5cy90cnVzdGVkLWtleXMv
dHJ1c3RlZF90cG0yLmMNCg0KVG8gbG9hZCB0aGUgUENSIHBvbGljeSBwcm90ZWN0aW9uIHRydXN0
ZWQga2V5LCB0aGUgY2FsbCBzdGFjayBpczogDQpTWVNDQUxMX0RFRklORTUoYWRkX2tleSwuLi4p
IC0tPiBrZXlfY3JlYXRlX29yX3VwZGF0ZSgpIC0tPiBfX2tleV9pbnN0YW50aWF0ZV9hbmRfbGlu
aygpIC0tPiAgdHJ1c3RlZF9pbnN0YW50aWF0ZSgpIC0tPiB0cG0yX3Vuc2VhbF90cnVzdGVkKCkg
LS0+IHRwbTJfdW5zZWFsX2NtZCgpLiANCg0KQ2hlY2sgZG1lc2csIHRoZXJlIHdpbGwgYmUgZXJy
b3I6IA0KWzczMzM2LjM1MTU5Nl0gdHJ1c3RlZF9rZXk6IGtleV91bnNlYWwgZmFpbGVkICgtMSkN
Cg0KLSBTaGlybGV5IA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTWltaSBa
b2hhciA8em9oYXJAbGludXguaWJtLmNvbT4gDQpTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDI3
LCAyMDE5IDM6MjggQU0NClRvOiBaaGFvLCBTaGlybGV5IDxzaGlybGV5LnpoYW9AaW50ZWwuY29t
PjsgSmFtZXMgQm90dG9tbGV5IDxqZWpiQGxpbnV4LmlibS5jb20+OyBKYXJra28gU2Fra2luZW4g
PGphcmtrby5zYWtraW5lbkBsaW51eC5pbnRlbC5jb20+OyBKb25hdGhhbiBDb3JiZXQgPGNvcmJl
dEBsd24ubmV0Pg0KQ2M6IGxpbnV4LWludGVncml0eUB2Z2VyLmtlcm5lbC5vcmc7IGtleXJpbmdz
QHZnZXIua2VybmVsLm9yZzsgbGludXgtZG9jQHZnZXIua2VybmVsLm9yZzsgbGludXgta2VybmVs
QHZnZXIua2VybmVsLm9yZzsgJ01hdXJvIENhcnZhbGhvIENoZWhhYicgPG1jaGVoYWIrc2Ftc3Vu
Z0BrZXJuZWwub3JnPjsgWmh1LCBCaW5nIDxiaW5nLnpodUBpbnRlbC5jb20+OyBDaGVuLCBMdWhh
aSA8bHVoYWkuY2hlbkBpbnRlbC5jb20+DQpTdWJqZWN0OiBSZTogT25lIHF1ZXN0aW9uIGFib3V0
IHRydXN0ZWQga2V5IG9mIGtleXJpbmcgaW4gTGludXgga2VybmVsLg0KDQpPbiBUdWUsIDIwMTkt
MTEtMjYgYXQgMDc6MzIgKzAwMDAsIFpoYW8sIFNoaXJsZXkgd3JvdGU6DQo+IFRoYW5rcyBmb3Ig
eW91ciBmZWVkYmFjaywgTWltaS4gDQo+IEJ1dCB0aGUgZG9jdW1lbnQgb2YgZHJhY3V0IGNhbid0
IHNvbHZlIG15IHByb2JsZW0uIA0KPiANCj4gSSBkaWQgbW9yZSB0ZXN0IHRoZXNlIGRheXMgYW5k
IHRyeSB0byBkZXNjcmlwdCBteSBxdWVzdGlvbiBpbiBtb3JlIGRldGFpbC4gDQo+IA0KPiBJbiBt
eSBzY2VuYXJpbywgdGhlIHRydXN0ZWQga2V5IHdpbGwgYmUgc2VhbGVkIGludG8gVFBNIHdpdGgg
UENSIHBvbGljeS4gDQo+IEFuZCB0aGVyZSBhcmUgc29tZSByZWxhdGVkIG9wdGlvbnMgaW4gbWFu
dWFsIGxpa2UgDQo+ICAgICAgICBoYXNoPSAgICAgICAgIGhhc2ggYWxnb3JpdGhtIG5hbWUgYXMg
YSBzdHJpbmcuIEZvciBUUE0gMS54IHRoZSBvbmx5DQo+ICAgICAgICAgICAgICAgICAgICAgIGFs
bG93ZWQgdmFsdWUgaXMgc2hhMS4gRm9yIFRQTSAyLnggdGhlIGFsbG93ZWQgdmFsdWVzDQo+ICAg
ICAgICAgICAgICAgICAgICAgIGFyZSBzaGExLCBzaGEyNTYsIHNoYTM4NCwgc2hhNTEyIGFuZCBz
bTMtMjU2Lg0KPiAgICAgICAgcG9saWN5ZGlnZXN0PSBkaWdlc3QgZm9yIHRoZSBhdXRob3JpemF0
aW9uIHBvbGljeS4gbXVzdCBiZSBjYWxjdWxhdGVkDQo+ICAgICAgICAgICAgICAgICAgICAgIHdp
dGggdGhlIHNhbWUgaGFzaCBhbGdvcml0aG0gYXMgc3BlY2lmaWVkIGJ5IHRoZSAnaGFzaD0nDQo+
ICAgICAgICAgICAgICAgICAgICAgIG9wdGlvbi4NCj4gICAgICAgIHBvbGljeWhhbmRsZT0gaGFu
ZGxlIHRvIGFuIGF1dGhvcml6YXRpb24gcG9saWN5IHNlc3Npb24gdGhhdCBkZWZpbmVzIHRoZQ0K
PiAgICAgICAgICAgICAgICAgICAgICBzYW1lIHBvbGljeSBhbmQgd2l0aCB0aGUgc2FtZSBoYXNo
IGFsZ29yaXRobSBhcyB3YXMgdXNlZCB0bw0KPiAgICAgICAgICAgICAgICAgICAgICBzZWFsIHRo
ZSBrZXkuIA0KPiANCj4gSGVyZSBpcyBteSB0ZXN0IHN0ZXAuIA0KPiBGaXJzdGx5LCB0aGUgcGNy
IHBvbGljeSBpcyBnZW5lcmF0ZWQgYXMgYmVsb3c6IA0KPiAkIHRwbTJfY3JlYXRlcG9saWN5IC0t
cG9saWN5LXBjciAtLXBjci1saXN0IHNoYTI1Njo3IC0tcG9saWN5IA0KPiBwY3I3X2Jpbi5wb2xp
Y3kgPiBwY3I3LnBvbGljeQ0KPiANCj4gUGNyNy5wb2xpY3kgaXMgdGhlIGFzY2lpIGhleCBvZiBw
b2xpY3k6DQo+ICQgY2F0IHBjcjcucG9saWN5DQo+IDMyMWZiZDI4YjYwZmNjMjMwMTdkNTAxYjEz
M2JkNWRiZjI4ODk4MTQ1ODhlOGEyMzUxMGZlMTAxMDVjYjJjYzkNCj4gDQo+IFRoZW4gZ2VuZXJh
dGUgdGhlIHRydXN0ZWQga2V5IGFuZCBjb25maWd1cmUgcG9saWN5ZGlnZXN0IGFuZCBnZXQgdGhl
IGtleSBJRDogDQo+ICQga2V5Y3RsIGFkZCB0cnVzdGVkIGttayAibmV3IDMyIGtleWhhbmRsZT0w
eDgxMDAwMDAxIGhhc2g9c2hhMjU2IA0KPiBwb2xpY3lkaWdlc3Q9YGNhdCBwY3I3LnBvbGljeWAi
IEB1DQo+IDg3NDExNzA0NQ0KPiANCj4gU2F2ZSB0aGUgdHJ1c3RlZCBrZXkuIA0KPiAkIGtleWN0
bCBwaXBlIDg3NDExNzA0NSA+IGttay5ibG9iDQo+IA0KPiBSZWJvb3QgYW5kIGxvYWQgdGhlIGtl
eS4gDQo+IFN0YXJ0IGEgYXV0aCBzZXNzaW9uIHRvIGdlbmVyYXRlIHRoZSBwb2xpY3k6DQo+ICQg
dHBtMl9zdGFydGF1dGhzZXNzaW9uIC1TIHNlc3Npb24uY3R4DQo+IHNlc3Npb24taGFuZGxlOiAw
eDMwMDAwMDANCj4gJCB0cG0yX3Bjcmxpc3QgLUwgc2hhMjU2OjcgLW8gcGNyNy5zaGEyNTYgJCB0
cG0yX3BvbGljeXBjciAtUyANCj4gc2Vzc2lvbi5jdHggLUwgc2hhMjU2OjcgLUYgcGNyNy5zaGEy
NTYgLWYgcGNyNy5wb2xpY3kNCj4gcG9saWN5LWRpZ2VzdDogDQo+IDB4MzIxRkJEMjhCNjBGQ0My
MzAxN0Q1MDFCMTMzQkQ1REJGMjg4OTgxNDU4OEU4QTIzNTEwRkUxMDEwNUNCMkNDOQ0KPiANCj4g
SW5wdXQgdGhlIHBvbGljeSBoYW5kbGUgdG8gbG9hZCB0cnVzdGVkIGtleToNCj4gJCBrZXljdGwg
YWRkIHRydXN0ZWQga21rICJsb2FkIGBjYXQga21rLmJsb2JgIGtleWhhbmRsZT0weDgxMDAwMDAx
IA0KPiBwb2xpY3loYW5kbGU9MHgzMDAwMDAwIiBAdQ0KPiBhZGRfa2V5OiBPcGVyYXRpb24gbm90
IHBlcm1pdHRlZA0KPiANCj4gVGhlIGVycm9yIHNob3VsZCBiZSBwb2xpY3kgY2hlY2sgZmFpbGVk
LCBiZWNhdXNlIEkgdXNlIFRQTSBjb21tYW5kIHRvIHVuc2VhbCBkaXJlY3RseSB3aXRoIGVycm9y
IG9mIHBvbGljeSBjaGVjayBmYWlsZWQuIA0KPiAkIHRwbTJfdW5zZWFsIC1jIDB4ODEwMDAwMDEg
LUwgc2hhMjU2OjcgRVJST1Igb24gbGluZTogIjgxIiBpbiBmaWxlOiANCj4gIi4vbGliL2xvZy5o
IjogVHNzMl9TeXNfVW5zZWFsKDB4OTlEKSAtIHRwbTpzZXNzaW9uKDEpOmEgcG9saWN5IGNoZWNr
IA0KPiBmYWlsZWQgRVJST1Igb24gbGluZTogIjIxMyIgaW4gZmlsZTogInRvb2xzL3RwbTJfdW5z
ZWFsLmMiOiBVbnNlYWwgZmFpbGVkIQ0KPiBFUlJPUiBvbiBsaW5lOiAiMTY2IiBpbiBmaWxlOiAi
dG9vbHMvdHBtMl90b29sLmMiOiBVbmFibGUgdG8gcnVuIA0KPiB0cG0yX3Vuc2VhbA0KPiANCj4g
U28gbXkgcXVlc3Rpb24gaXM6DQo+IDEuIEhvdyB0byB1c2UgdGhlIG9wdGlvbiwgcG9saWN5ZGln
ZXN0LCBwb2xpY3loYW5kbGU/PyBJcyB0aGVyZSBhbnkgZXhhbXBsZT8gDQo+IDIuIFdoYXQncyB3
cm9uZyB3aXRoIG15IHRlc3Qgc3RlcD8gDQoNCldoZW4gcmVwb3J0aW5nIGEgcHJvYmxlbSBwbGVh
c2Ugc3RhdGUgd2hpY2gga2VybmVsIGlzIGV4cGVyaWVuY2luZyB0aGlzIHByb2JsZW0uIMKgUmVj
ZW50bHkgdGhlcmUgd2FzIGEgdHJ1c3RlZCBrZXkgcmVncmVzc2lvbi4gwqBSZWZlciB0byBjb21t
aXQgZTEzY2QyMWZmZDUwICJ0cG06IFdyYXAgdGhlIGJ1ZmZlciBmcm9tIHRoZSBjYWxsZXIgdG8g
dHBtX2J1ZiBpbiB0cG1fc2VuZCgpIiBmb3IgdGhlIGRldGFpbHMuDQoNCkJlZm9yZSBkZWx2aW5n
IGludG8gdGhpcyBwYXJ0aWN1bGFyIHByb2JsZW0sIGZpcnN0IHBsZWFzZSBtYWtlIHN1cmUgeW91
IGFyZSBhYmxlIHRvIGNyZWF0ZSwgc2F2ZSwgcmVtb3ZlLCBhbmQgdGhlbiByZWxvYWQgYSB0cnVz
dGVkIGtleSBub3Qgc2VhbGVkIHRvIGEgUENSLg0KDQpNaW1pwqANCg0K

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.

[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.

[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]

SGksIEphbWVzLCANCg0KTWF5YmUgdGhlIFRQTSBjb21tYW5kIGNvbmZ1c2VkIHlvdS4gDQoNClRo
ZSBxdWVzdGlvbiBpcyBJIHVzZSBrZXljdGwgY29tbWFuZCBzZWFsZWQgYSB0cnVzdGVkIGtleSB3
aXRoIFBDUiBwb2xpY3ksIGJ1dCBsb2FkIGl0IGZhaWxlZCBhZnRlciByZWJvb3QuIA0KSSBkb24n
dCBrbm93IHdoeSBpdCB3YXMgbG9hZGVkIGZhaWxlZC4gSSB1c2UgVFBNIGNvbW1hbmQgdG8gaGVs
cCBmaW5kIGl0LCBpdCByZXBvcnQgcG9saWN5IGNoZWNrIGZhaWxlZC4gDQoNClNvIG15IHF1ZXN0
aW9uIGlzIGhvdyB0byBsb2FkIHRoZSBQQ1IgcG9saWN5IHNlYWxlZCB0cnVzdGVkIGtleSBjb3Jy
ZWN0bHk/IA0KSG93IHRvIHVzZSBwb2xpY3lkaWdlc3QgYW5kIHBvbGljeWhhbmRsZSBjb3JyZWN0
bHkuIA0KDQpUaGFua3MuIA0KDQotIFNoaXJsZXkgDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t
LS0tDQpGcm9tOiBKYW1lcyBCb3R0b21sZXkgPGplamJAbGludXguaWJtLmNvbT4gDQpTZW50OiBU
aHVyc2RheSwgTm92ZW1iZXIgMjgsIDIwMTkgMjowNiBBTQ0KVG86IFpoYW8sIFNoaXJsZXkgPHNo
aXJsZXkuemhhb0BpbnRlbC5jb20+OyBNaW1pIFpvaGFyIDx6b2hhckBsaW51eC5pYm0uY29tPjsg
SmFya2tvIFNha2tpbmVuIDxqYXJra28uc2Fra2luZW5AbGludXguaW50ZWwuY29tPjsgSm9uYXRo
YW4gQ29yYmV0IDxjb3JiZXRAbHduLm5ldD4NCkNjOiBsaW51eC1pbnRlZ3JpdHlAdmdlci5rZXJu
ZWwub3JnOyBrZXlyaW5nc0B2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4LWRvY0B2Z2VyLmtlcm5lbC5v
cmc7IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7ICdNYXVybyBDYXJ2YWxobyBDaGVoYWIn
IDxtY2hlaGFiK3NhbXN1bmdAa2VybmVsLm9yZz47IFpodSwgQmluZyA8YmluZy56aHVAaW50ZWwu
Y29tPjsgQ2hlbiwgTHVoYWkgPGx1aGFpLmNoZW5AaW50ZWwuY29tPg0KU3ViamVjdDogUmU6IE9u
ZSBxdWVzdGlvbiBhYm91dCB0cnVzdGVkIGtleSBvZiBrZXlyaW5nIGluIExpbnV4IGtlcm5lbC4N
Cg0KT24gVHVlLCAyMDE5LTExLTI2IGF0IDA3OjMyICswMDAwLCBaaGFvLCBTaGlybGV5IHdyb3Rl
Og0KPiBUaGFua3MgZm9yIHlvdXIgZmVlZGJhY2ssIE1pbWkuIA0KPiBCdXQgdGhlIGRvY3VtZW50
IG9mIGRyYWN1dCBjYW4ndCBzb2x2ZSBteSBwcm9ibGVtLiANCj4gDQo+IEkgZGlkIG1vcmUgdGVz
dCB0aGVzZSBkYXlzIGFuZCB0cnkgdG8gZGVzY3JpcHQgbXkgcXVlc3Rpb24gaW4gbW9yZSANCj4g
ZGV0YWlsLg0KPiANCj4gSW4gbXkgc2NlbmFyaW8sIHRoZSB0cnVzdGVkIGtleSB3aWxsIGJlIHNl
YWxlZCBpbnRvIFRQTSB3aXRoIFBDUiANCj4gcG9saWN5Lg0KPiBBbmQgdGhlcmUgYXJlIHNvbWUg
cmVsYXRlZCBvcHRpb25zIGluIG1hbnVhbCBsaWtlIA0KPiAgICAgICAgaGFzaD0gICAgICAgICBo
YXNoIGFsZ29yaXRobSBuYW1lIGFzIGEgc3RyaW5nLiBGb3IgVFBNIDEueCB0aGUNCj4gb25seQ0K
PiAgICAgICAgICAgICAgICAgICAgICBhbGxvd2VkIHZhbHVlIGlzIHNoYTEuIEZvciBUUE0gMi54
IHRoZSBhbGxvd2VkIA0KPiB2YWx1ZXMNCj4gICAgICAgICAgICAgICAgICAgICAgYXJlIHNoYTEs
IHNoYTI1Niwgc2hhMzg0LCBzaGE1MTIgYW5kIHNtMy0yNTYuDQo+ICAgICAgICBwb2xpY3lkaWdl
c3Q9IGRpZ2VzdCBmb3IgdGhlIGF1dGhvcml6YXRpb24gcG9saWN5LiBtdXN0IGJlIA0KPiBjYWxj
dWxhdGVkDQo+ICAgICAgICAgICAgICAgICAgICAgIHdpdGggdGhlIHNhbWUgaGFzaCBhbGdvcml0
aG0gYXMgc3BlY2lmaWVkIGJ5IHRoZSANCj4gJ2hhc2g9Jw0KPiAgICAgICAgICAgICAgICAgICAg
ICBvcHRpb24uDQo+ICAgICAgICBwb2xpY3loYW5kbGU9IGhhbmRsZSB0byBhbiBhdXRob3JpemF0
aW9uIHBvbGljeSBzZXNzaW9uIHRoYXQgDQo+IGRlZmluZXMgdGhlDQo+ICAgICAgICAgICAgICAg
ICAgICAgIHNhbWUgcG9saWN5IGFuZCB3aXRoIHRoZSBzYW1lIGhhc2ggYWxnb3JpdGhtIGFzIA0K
PiB3YXMgdXNlZCB0bw0KPiAgICAgICAgICAgICAgICAgICAgICBzZWFsIHRoZSBrZXkuIA0KPiAN
Cj4gSGVyZSBpcyBteSB0ZXN0IHN0ZXAuIA0KPiBGaXJzdGx5LCB0aGUgcGNyIHBvbGljeSBpcyBn
ZW5lcmF0ZWQgYXMgYmVsb3c6IA0KPiAkIHRwbTJfY3JlYXRlcG9saWN5IC0tcG9saWN5LXBjciAt
LXBjci1saXN0IHNoYTI1Njo3IC0tcG9saWN5IA0KPiBwY3I3X2Jpbi5wb2xpY3kgPiBwY3I3LnBv
bGljeQ0KPiANCj4gUGNyNy5wb2xpY3kgaXMgdGhlIGFzY2lpIGhleCBvZiBwb2xpY3k6DQo+ICQg
Y2F0IHBjcjcucG9saWN5DQo+IDMyMWZiZDI4YjYwZmNjMjMwMTdkNTAxYjEzM2JkNWRiZjI4ODk4
MTQ1ODhlOGEyMzUxMGZlMTAxMDVjYjJjYzkNCj4gDQo+IFRoZW4gZ2VuZXJhdGUgdGhlIHRydXN0
ZWQga2V5IGFuZCBjb25maWd1cmUgcG9saWN5ZGlnZXN0IGFuZCBnZXQgdGhlIA0KPiBrZXkgSUQ6
DQo+ICQga2V5Y3RsIGFkZCB0cnVzdGVkIGttayAibmV3IDMyIGtleWhhbmRsZT0weDgxMDAwMDAx
IGhhc2g9c2hhMjU2IA0KPiBwb2xpY3lkaWdlc3Q9YGNhdCBwY3I3LnBvbGljeWAiIEB1DQo+IDg3
NDExNzA0NQ0KPiANCj4gU2F2ZSB0aGUgdHJ1c3RlZCBrZXkuIA0KPiAkIGtleWN0bCBwaXBlIDg3
NDExNzA0NSA+IGttay5ibG9iDQo+IA0KPiBSZWJvb3QgYW5kIGxvYWQgdGhlIGtleS4gDQo+IFN0
YXJ0IGEgYXV0aCBzZXNzaW9uIHRvIGdlbmVyYXRlIHRoZSBwb2xpY3k6DQo+ICQgdHBtMl9zdGFy
dGF1dGhzZXNzaW9uIC1TIHNlc3Npb24uY3R4DQo+IHNlc3Npb24taGFuZGxlOiAweDMwMDAwMDAN
Cj4gJCB0cG0yX3Bjcmxpc3QgLUwgc2hhMjU2OjcgLW8gcGNyNy5zaGEyNTYgJCB0cG0yX3BvbGlj
eXBjciAtUyANCj4gc2Vzc2lvbi5jdHggLUwgc2hhMjU2OjcgLUYgcGNyNy5zaGEyNTYgLWYgcGNy
Ny5wb2xpY3kNCj4gcG9saWN5LWRpZ2VzdDoNCj4gMHgzMjFGQkQyOEI2MEZDQzIzMDE3RDUwMUIx
MzNCRDVEQkYyODg5ODE0NTg4RThBMjM1MTBGRTEwMTA1Q0IyQ0M5DQo+IA0KPiBJbnB1dCB0aGUg
cG9saWN5IGhhbmRsZSB0byBsb2FkIHRydXN0ZWQga2V5Og0KPiAkIGtleWN0bCBhZGQgdHJ1c3Rl
ZCBrbWsgImxvYWQgYGNhdCBrbWsuYmxvYmAga2V5aGFuZGxlPTB4ODEwMDAwMDEgDQo+IHBvbGlj
eWhhbmRsZT0weDMwMDAwMDAiIEB1DQo+IGFkZF9rZXk6IE9wZXJhdGlvbiBub3QgcGVybWl0dGVk
DQo+IA0KPiBUaGUgZXJyb3Igc2hvdWxkIGJlIHBvbGljeSBjaGVjayBmYWlsZWQsIGJlY2F1c2Ug
SSB1c2UgVFBNIGNvbW1hbmQgdG8gDQo+IHVuc2VhbCBkaXJlY3RseSB3aXRoIGVycm9yIG9mIHBv
bGljeSBjaGVjayBmYWlsZWQuDQo+ICQgdHBtMl91bnNlYWwgLWMgMHg4MTAwMDAwMSAtTCBzaGEy
NTY6NyBFUlJPUiBvbiBsaW5lOiAiODEiIGluIGZpbGU6IA0KPiAiLi9saWIvbG9nLmgiOiBUc3My
X1N5c19VbnNlYWwoMHg5OUQpIC0gdHBtOnNlc3Npb24oMSk6YSBwb2xpY3kgY2hlY2sgDQo+IGZh
aWxlZCBFUlJPUiBvbiBsaW5lOiAiMjEzIiBpbiBmaWxlOiAidG9vbHMvdHBtMl91bnNlYWwuYyI6
IFVuc2VhbCANCj4gZmFpbGVkIQ0KPiBFUlJPUiBvbiBsaW5lOiAiMTY2IiBpbiBmaWxlOiAidG9v
bHMvdHBtMl90b29sLmMiOiBVbmFibGUgdG8gcnVuIA0KPiB0cG0yX3Vuc2VhbA0KDQpJIHRoaW5r
IHRoZXJlJ3MgYSBtaXNjb21tdW5pY2F0aW9uIGhlcmU6IHlvdSdyZSBjb21wbGFpbmluZyBhYm91
dCB0aGUgZXJyb3IgcmV0dXJuZWQgZnJvbSBhIHRydXN0ZWQga2V5IHVuc2VhbCBvcGVyYXRpb24g
dGhhdCAqc2hvdWxkKiBmYWlsLCBjb3JyZWN0PyAgWW91IHRoaW5rIGl0IHNob3VsZCByZXR1cm4g
YSBUUE0gZXJyb3IgYnV0IGluc3RlYWQgaXQgcmV0dXJucyAtRVBFUk0uICBUaGF0J3MgY29tcGxl
dGVseSBjb3JyZWN0OiB3ZSB0cmFuc2xhdGUgYWxsIFRQTSBlcnJvcnMgaW50byBsaW51eCBvbmVz
IGFzIHdlIHBhc3MgdGhlbSB1cCB0byB1c2Vyc3BhY2UsIHNvIHRoZSBiZXN0IHdlIGNhbiBkbyBp
cyBvcGVyYXRpb24gbm90IHBlcm1pdHRlZC4NCg0KSmFtZXMNCg0K

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]

SGksIE1pbWksIA0KDQpNeSB0ZXN0IGVudmlyb25tZW50IGlzIFVidW50dSAxOC4wNC4zLCBrZXJu
ZWwgdmVyc2lvbiBpcyA1LjAuMC0zNi1nZW5lcmljLiANCiQgY2F0IC9wcm9jL3ZlcnNpb24NCkxp
bnV4IHZlcnNpb24gNS4wLjAtMzYtZ2VuZXJpYyAoYnVpbGRkQGxndzAxLWFtZDY0LTA2MCkgKGdj
YyB2ZXJzaW9uIDcuNC4wIChVYnVudHUgNy40LjAtMXVidW50dTF+MTguMDQuMSkpICMzOX4xOC4w
NC4xLVVidW50dSBTTVAgVHVlIE5vdiAxMiAxMTowOTo1MCBVVEMgMjAxOQ0KJCBsc2JfcmVsZWFz
ZSAtYQ0KTm8gTFNCIG1vZHVsZXMgYXJlIGF2YWlsYWJsZS4NCkRpc3RyaWJ1dG9yIElEOiBVYnVu
dHUNCkRlc2NyaXB0aW9uOiAgICBVYnVudHUgMTguMDQuMyBMVFMNClJlbGVhc2U6ICAgICAgICAx
OC4wNA0KQ29kZW5hbWU6ICAgICAgIGJpb25pYw0KDQpJdCBpcyBUUE0yLjAsIGRUUE0uIA0KDQpB
bmQgSSBkaWRu4oCZdCBydW4gaXQgb24gb3RoZXIgdmVyc2lvbi4gDQoNCkl0IGhhcyBubyByZWxh
dGlvbnNoaXAgd2l0aCBUUE0gY29tbWFuZCwgaXQgaXMganVzdCB1c2VkIHRvIGhlbHAgZmluZCB0
aGUgZmFpbCByZWFzb24uIA0KTXkgcXVlc3Rpb24gaXMgaG93IHRvIGxvYWQgYSB0cnVzdGVkIGtl
eSB3aGljaCBpcyBzZWFsZWQgd2l0aCBQQ1IgcG9saWN5IGNvcnJlY3RseSBhZnRlciByZWJvb3Qu
DQpUaGF0IGlzIGJldHRlciBpZiB0aGVyZSBpcyBzb21lIGV4YW1wbGUgYWJvdXQgaG93IHRvIHVz
ZSAicG9saWN5ZGlnZXN0IiwgInBvbGljeWhhbmRsZSIgdG8gc2VhbC91bnNlYWwgYSB0cnVzdGVk
IGtleS4gDQoNClRoYW5rcy4gDQoNCi0gU2hpcmxleSANCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVz
c2FnZS0tLS0tDQpGcm9tOiBNaW1pIFpvaGFyIDx6b2hhckBsaW51eC5pYm0uY29tPiANClNlbnQ6
IFdlZG5lc2RheSwgTm92ZW1iZXIgMjcsIDIwMTkgMTE6MzkgUE0NClRvOiBaaGFvLCBTaGlybGV5
IDxzaGlybGV5LnpoYW9AaW50ZWwuY29tPjsgSmFtZXMgQm90dG9tbGV5IDxqZWpiQGxpbnV4Lmli
bS5jb20+OyBKYXJra28gU2Fra2luZW4gPGphcmtrby5zYWtraW5lbkBsaW51eC5pbnRlbC5jb20+
OyBKb25hdGhhbiBDb3JiZXQgPGNvcmJldEBsd24ubmV0Pg0KQ2M6IGxpbnV4LWludGVncml0eUB2
Z2VyLmtlcm5lbC5vcmc7IGtleXJpbmdzQHZnZXIua2VybmVsLm9yZzsgbGludXgtZG9jQHZnZXIu
a2VybmVsLm9yZzsgbGludXgta2VybmVsQHZnZXIua2VybmVsLm9yZzsgJ01hdXJvIENhcnZhbGhv
IENoZWhhYicgPG1jaGVoYWIrc2Ftc3VuZ0BrZXJuZWwub3JnPjsgWmh1LCBCaW5nIDxiaW5nLnpo
dUBpbnRlbC5jb20+OyBDaGVuLCBMdWhhaSA8bHVoYWkuY2hlbkBpbnRlbC5jb20+DQpTdWJqZWN0
OiBSZTogT25lIHF1ZXN0aW9uIGFib3V0IHRydXN0ZWQga2V5IG9mIGtleXJpbmcgaW4gTGludXgg
a2VybmVsLg0KDQpIaSBTaGlybGV5LA0KDQpPbiBXZWQsIDIwMTktMTEtMjcgYXQgMDI6NDYgKzAw
MDAsIFpoYW8sIFNoaXJsZXkgd3JvdGU6DQo+IEhpLCBNaW1pLA0KPiANCj4gQW5zd2VyIHlvdXIg
dHdvIHF1ZXN0aW9uczoNCj4gDQo+IDEuIFllcywgSSBoYXZlIHZlcmlmaWVkIHRydXN0ZWQga2V5
IHdvcmtzIHdlbGwgd2l0aG91dCBQQ1IgcG9saWN5IA0KPiBwcm90ZWN0aW9uIGFzIGJlbG93Og0K
PiAkIGtleWN0bCBhZGQgdHJ1c3RlZCBrbWsgIm5ldyAzMiBrZXloYW5kbGU9MHg4MTAwMDAwMSIg
QHUNCj4gMTA1NTI0MDkyOA0KPiAkIGtleWN0bCBsaXN0IEB1DQo+IDEga2V5cyBpbiBrZXlyaW5n
Og0KPiAxMDU1MjQwOTI4OiAtLWFsc3dydiAgICAgMCAgICAgMCB0cnVzdGVkOiBrbWsNCj4gJCBr
ZXljdGwgcGlwZSAxMDU1MjQwOTI4ID4ga21rLmJsb2INCj4gJCBjYXQga21rLmJsb2INCj4gMDA3
ZjAwMjBmZjgwOGJkOGI3MjM5MTk0ZTg5YWFjNmE5NWI0ZDIxMDExNDc0MmMyMGFmYTMzNDkzZjAw
MmRmZmQwNjgNCj4gNWQ1MTAwMTBjMTJkN2FkNTFlYjgzZDZkOTM4OTVkZTA2NmJmM2QzOTcxOGNj
NTAzYWRiNDgwMmNiMDg3Yjg4YjJmZmYNCj4gNGIwNDBmZTNhMmJlNmEzZjg3YzY3NDlkMDg3Yzlm
YjZlODczNGNiMjNmNDM4ZDY0MDg3NTgxYTEzYmM4M2Q1ZGMzYjANCj4gMjZlNzdhODk0ZWNlNjYy
MGQwZWI4NWRmNjQ0OWZmM2M2MDlmZDc3ZDVmMGNhZjc5YjQ1MzViMDAyZTAwMDgwMDBiMDANCj4g
MDAwMDQwMDAwMDAwMTAwMDIwOWE1YjAwYjBkNTU4ZmNmOWU4YzAyOTUyMjcxNWU2YjU5MDYzNjZl
YWVjNWYzNDM2N2INCj4gOGFiMTZjMGZiOTAwOWEwMDczMDAwMDAwMDAwMDIwZTNiMGM0NDI5OGZj
MWMxNDlhZmJmNGM4OTk2ZmI5MjQyN2FlNDENCj4gZTQ2NDliOTM0Y2E0OTU5OTFiNzg1MmI4NTUw
MTAwMGIwMDIyMDAwYmRjZGI2OTRlMTAyZTEzYTBmYmE1MTExMDgxY2INCj4gNmNmNjE2YzExOGQ0
MDQ5MzZjYWMzZTg0ZGIyNGM3MWU0N2Q1MDAyMjAwMGIwNGI1ZGIxYWE1MjYzNWRmYjI0MmU3NmYN
Cj4gNmJkZThlMjE3NmFlNDhmYzY4Mjk0NmM2Yzc2ZDk2ZjYwODA3OWQxZjAwMDAwMDIwMzZiNmZj
Y2E4MjA2YzdmNzIyZGUNCj4gODU4MjFkN2VjYjQ3ODU5NzZmZGQ2NDJiYzc1Mzg1MDVhMmE4MThj
OGEyMzg4MDIxNDAwMDAwMDEwMDIwMmFlZGRlNDUNCj4gMDhmNTQ4ZDEwODE5M2VjOGZlMTY2YTdi
ZWZkZTE5MTEzZmU3MjdhZTJiMjk5MDFiZGVjZTk2ZTUNCj4gJCBrZXljdGwgY2xlYXIgQHUNCj4g
JCBrZXljdGwgbGlzdCBAdQ0KPiBrZXlyaW5nIGlzIGVtcHR5DQo+ICQga2V5Y3RsIGFkZCB0cnVz
dGVkIGttayAibG9hZCBgY2F0IGttay5ibG9iYCBrZXloYW5kbGU9MHg4MTAwMDAwMSINCj4gQHUN
Cj4gMTAyMjk2MzczMQ0KPiAkIGtleWN0bCBwcmludCAxMDIyOTYzNzMxDQo+IDAwN2YwMDIwZmY4
MDhiZDhiNzIzOTE5NGU4OWFhYzZhOTViNGQyMTAxMTQ3NDJjMjBhZmEzMzQ5M2YwMDJkZmZkMDY4
DQo+IDVkNTEwMDEwYzEyZDdhZDUxZWI4M2Q2ZDkzODk1ZGUwNjZiZjNkMzk3MThjYzUwM2FkYjQ4
MDJjYjA4N2I4OGIyZmZmDQo+IDRiMDQwZmUzYTJiZTZhM2Y4N2M2NzQ5ZDA4N2M5ZmI2ZTg3MzRj
YjIzZjQzOGQ2NDA4NzU4MWExM2JjODNkNWRjM2IwDQo+IDI2ZTc3YTg5NGVjZTY2MjBkMGViODVk
ZjY0NDlmZjNjNjA5ZmQ3N2Q1ZjBjYWY3OWI0NTM1YjAwMmUwMDA4MDAwYjAwDQo+IDAwMDA0MDAw
MDAwMDEwMDAyMDlhNWIwMGIwZDU1OGZjZjllOGMwMjk1MjI3MTVlNmI1OTA2MzY2ZWFlYzVmMzQz
NjdiDQo+IDhhYjE2YzBmYjkwMDlhMDA3MzAwMDAwMDAwMDAyMGUzYjBjNDQyOThmYzFjMTQ5YWZi
ZjRjODk5NmZiOTI0MjdhZTQxDQo+IGU0NjQ5YjkzNGNhNDk1OTkxYjc4NTJiODU1MDEwMDBiMDAy
MjAwMGJkY2RiNjk0ZTEwMmUxM2EwZmJhNTExMTA4MWNiDQo+IDZjZjYxNmMxMThkNDA0OTM2Y2Fj
M2U4NGRiMjRjNzFlNDdkNTAwMjIwMDBiMDRiNWRiMWFhNTI2MzVkZmIyNDJlNzZmDQo+IDZiZGU4
ZTIxNzZhZTQ4ZmM2ODI5NDZjNmM3NmQ5NmY2MDgwNzlkMWYwMDAwMDAyMDM2YjZmY2NhODIwNmM3
ZjcyMmRlDQo+IDg1ODIxZDdlY2I0Nzg1OTc2ZmRkNjQyYmM3NTM4NTA1YTJhODE4YzhhMjM4ODAy
MTQwMDAwMDAxMDAyMDJhZWRkZTQ1DQo+IDA4ZjU0OGQxMDgxOTNlYzhmZTE2NmE3YmVmZGUxOTEx
M2ZlNzI3YWUyYjI5OTAxYmRlY2U5NmU1DQo+IA0KPiAyLiBUaGUgZm9sbG93aW5nIGtlcm5lbCBm
aWxlIGlzIHJlbGF0ZWQgd2l0aCB0aGlzIHByb2JsZW0uIA0KPiAvc2VjdXJpdHkva2V5cy9rZXlj
dGwuYyAvc2VjdXJpdHkva2V5cy9rZXkuYyANCj4gL3NlY3VyaXR5L2tleXMvdHJ1c3RlZC1rZXlz
L3RydXN0ZWRfdHBtMS5jDQo+IC9zZWN1cml0eS9rZXlzL3RydXN0ZWQta2V5cy90cnVzdGVkX3Rw
bTIuYw0KPiANCj4gVG8gbG9hZCB0aGUgUENSIHBvbGljeSBwcm90ZWN0aW9uIHRydXN0ZWQga2V5
LCB0aGUgY2FsbCBzdGFjayBpczoNCj4gU1lTQ0FMTF9ERUZJTkU1KGFkZF9rZXksLi4uKSAtLT4g
a2V5X2NyZWF0ZV9vcl91cGRhdGUoKSAtLT4NCj4gX19rZXlfaW5zdGFudGlhdGVfYW5kX2xpbmso
KSAtLT4gIHRydXN0ZWRfaW5zdGFudGlhdGUoKSAtLT4NCj4gdHBtMl91bnNlYWxfdHJ1c3RlZCgp
IC0tPiB0cG0yX3Vuc2VhbF9jbWQoKS4NCj4gDQo+IENoZWNrIGRtZXNnLCB0aGVyZSB3aWxsIGJl
IGVycm9yOg0KPiBbNzMzMzYuMzUxNTk2XSB0cnVzdGVkX2tleToga2V5X3Vuc2VhbCBmYWlsZWQg
KC0xKQ0KDQpMaWtlIHRoZSBvdGhlciBrZXJuZWwgbWFpbGluZyBsaXN0cywgcGxlYXNlIGJvdHRv
bSBwb3N0LiDCoFdoZW4gcmVwb3J0aW5nIGEgcHJvYmxlbSwgcGxlYXNlIGluY2x1ZGUgdGhlIGtl
cm5lbCB2ZXJzaW9uIGFuZCBvdGhlciByZWxldmFudCBkZXRhaWxzLiDCoEZvciBleGFtcGxlLCB0
aGUgVFBNIHZlcnNpb24gYW5kIHR5cGUgKGVnLiBoYXJkd2FyZSB2ZW5kb3IsIHNvZnR3YXJlIFRQ
TSwgZXRjKS4gwqBQbGVhc2UgaW5kaWNhdGUgaWYgdGhpcyBpcyBhIG5ldyBwcm9ibGVtIGFuZCB3
aGljaCBrZXJuZWwgcmVsZWFzZSBpdCBmaXJzdCBzdGFydCBoYXBwZW5pbmc/DQoNCkkgaGF2ZSBu
byBleHBlcmllbmNlIHdpdGggdGhlIHRwbTJfIGNvbW1hbmRzLCDCoEkgc3VnZ2VzdCB0cnlpbmcg
dG8gZXh0ZW5kIGEgc2luZ2xlIG1lYXN1cmVtZW50IHRvIGEgUENSIGFuZCBzZWFsaW5nIHRvIHRo
YXQgdmFsdWUuDQoNCk1pbWkNCg0K

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.

[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.

[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]

SGksIEphbWVzLCANCg0KVGhlIHZhbHVlIG9mIFBDUjcgaXMgbm90IGNoYW5nZWQuIEkgaGF2ZSBj
aGVja2VkIGl0IHdpdGggVFBNIGNvbW1hbmQgdHBtX3Bjcmxpc3QuIA0KDQpTbyBJIHRoaW5rIHRo
ZSBwcm9ibGVtIGlzIGhvdyB0byB1c2UgdGhlIG9wdGlvbiBwb2xpY3lkaWdlc3QgYW5kIHBvbGlj
eWhhbmRsZT8gSXMgdGhlcmUgYW55IGV4YW1wbGU/DQpNYXliZSB0aGUgZm9ybWF0IGluIG15IGNv
bW1hbmQgaXMgbm90IGNvcnJlY3QuIA0KDQpUaGFua3MuIA0KDQotIFNoaXJsZXkgDQoNCi0tLS0t
T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBKYW1lcyBCb3R0b21sZXkgPGplamJAbGludXgu
aWJtLmNvbT4gDQpTZW50OiBTYXR1cmRheSwgTm92ZW1iZXIgMzAsIDIwMTkgNDowNSBBTQ0KVG86
IFpoYW8sIFNoaXJsZXkgPHNoaXJsZXkuemhhb0BpbnRlbC5jb20+OyBNaW1pIFpvaGFyIDx6b2hh
ckBsaW51eC5pYm0uY29tPjsgSmFya2tvIFNha2tpbmVuIDxqYXJra28uc2Fra2luZW5AbGludXgu
aW50ZWwuY29tPjsgSm9uYXRoYW4gQ29yYmV0IDxjb3JiZXRAbHduLm5ldD4NCkNjOiBsaW51eC1p
bnRlZ3JpdHlAdmdlci5rZXJuZWwub3JnOyBrZXlyaW5nc0B2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4
LWRvY0B2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7ICdNYXVy
byBDYXJ2YWxobyBDaGVoYWInIDxtY2hlaGFiK3NhbXN1bmdAa2VybmVsLm9yZz47IFpodSwgQmlu
ZyA8YmluZy56aHVAaW50ZWwuY29tPjsgQ2hlbiwgTHVoYWkgPGx1aGFpLmNoZW5AaW50ZWwuY29t
Pg0KU3ViamVjdDogUmU6IE9uZSBxdWVzdGlvbiBhYm91dCB0cnVzdGVkIGtleSBvZiBrZXlyaW5n
IGluIExpbnV4IGtlcm5lbC4NCg0KT24gRnJpLCAyMDE5LTExLTI5IGF0IDAxOjQwICswMDAwLCBa
aGFvLCBTaGlybGV5IHdyb3RlOg0KPiBIaSwgSmFtZXMsDQo+IA0KPiBNYXliZSB0aGUgVFBNIGNv
bW1hbmQgY29uZnVzZWQgeW91LiANCg0KV2VsbCB5b3UgZGlkIHNlZW0gdG8gYmUgc2F5aW5nIHdl
IGhhZCBhIHByb2JsZW0gaW4gdGhlIFRQTSBzZWFsZWQga2V5IHN1YnN5c3RlbS4NCg0KPiBUaGUg
cXVlc3Rpb24gaXMgSSB1c2Uga2V5Y3RsIGNvbW1hbmQgc2VhbGVkIGEgdHJ1c3RlZCBrZXkgd2l0
aCBQQ1IgDQo+IHBvbGljeSwgYnV0IGxvYWQgaXQgZmFpbGVkIGFmdGVyIHJlYm9vdC4NCj4gSSBk
b24ndCBrbm93IHdoeSBpdCB3YXMgbG9hZGVkIGZhaWxlZC4gSSB1c2UgVFBNIGNvbW1hbmQgdG8g
aGVscCBmaW5kIA0KPiBpdCwgaXQgcmVwb3J0IHBvbGljeSBjaGVjayBmYWlsZWQuDQoNClJpZ2h0
LCBzbyB5b3VyIHF1ZXN0aW9uIHNlZW1zIHRvIGJlIHdoeSBhZnRlciBhIHJlYm9vdCwgdGhlIFRQ
TSBwb2xpY3kgbm8gbG9uZ2VyIHdvcmtzIHRvIGF1dGhvcml6ZSB0aGUga2V5IGV2ZW4gZnJvbSB1
c2VyIHNwYWNlPyAgTXkgYmVzdCBndWVzcyB3b3VsZCBiZSB0aGUgUENSIHZhbHVlIHlvdSd2ZSBz
ZWFsZWQgaXQgdG8gY2hhbmdlZCBvdmVyIHRoZSByZWJvb3QgZm9yIHNvbWUgcmVhc29uLg0KDQo+
IFNvIG15IHF1ZXN0aW9uIGlzIGhvdyB0byBsb2FkIHRoZSBQQ1IgcG9saWN5IHNlYWxlZCB0cnVz
dGVkIGtleSANCj4gY29ycmVjdGx5Pw0KDQpZb3UgaGF2ZSB0byBzZXQgdGhlIHNlYWxpbmcgcmVs
ZWFzZSBwb2xpY3kgdG8gc29tZXRoaW5nIHlvdSBrbm93IHdpbGwgYmUgaW52YXJpYW50IGFjcm9z
cyByZWJvb3RzIGZvciBhbiB1bnNlYWwgdG8gaGFwcGVuIHJlbGlhYmx5LiAgSG93ZXZlciwgdXN1
YWxseSB5b3UgYWxzbyB3YW50IHRoZSB1bnNlYWwgdG8gZmFpbCBpZiBzb21ldGhpbmcgeW91IGRv
bid0IGxpa2UgY2hhbmdlcywgc28geW91IHNldCB0aGUgcG9saWN5IHRvIGJlIHNvbWV0aGluZyB0
aGF0J3MgaW52YXJpYW50IHVubGVzcyB0aGF0IGhhcHBlbnMuICBOb3QgcmVhbGx5IGtub3dpbmcg
d2hhdCB5b3VyIGNvbmRpdGlvbnMgYXJlIHdlIGNhbid0IHJlYWxseSB0ZWxsIHlvdSB3aGF0IHlv
dXIgcG9saWN5IHNob3VsZCBsb29rIGxpa2UuDQoNCj4gSG93IHRvIHVzZSBwb2xpY3lkaWdlc3Qg
YW5kIHBvbGljeWhhbmRsZSBjb3JyZWN0bHkuIA0KDQpJJ3ZlIG5vIHJlYWwgaWRlYSBob3cgdGhl
IHRwbTJfIGNvbW1hbmRzIHdvcmssIGJ1dCB0aGUgdHNzcG9saWN5IGNvbW1hbmRzIGFsbCBoYXZl
IG1hbiBwYWdlcyB3aGljaCBkbyBhIHByZXR0eSBnb29kIGV4cGxhbmF0aW9uLiAgSWYgSSBpbmZl
ciBob3cgeW91ciB0cG0yXyBjb21tYW5kcyBzZWVtIHRvIGJlIHdvcmtpbmcsIEkgdGhpbmsgeW91
J3JlIHNlYWxpbmcgdG8gYSBwY3I3IGhhc2g/ICBwY3I3IGlzIHRoZSBvbmUgdGhhdCdzIHN1cHBv
c2VkIHRvIG1lYXN1cmUgdGhlIHNlY3VyZSBib290IHBhdGggYW5kIHByb3BlcnRpZXMgYW5kIGFz
IHN1Y2ggc2hvdWxkbid0IGNoYW5nZSBhY3Jvc3MgcmVib290cywgc28gSSB0aGluayB5b3VyIHBy
b2JsZW0gYmVjb21lcyBmaW5kaW5nIG91dCB3aHkgaXQgY2hhbmdlZC4NCg0KSmFtZXMNCg0K

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.

[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.

[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]

VGhhbmtzIGZvciB5b3VyIGZlZWRiYWNrLCBKYW1lcy4NCg0KVGhlIHBvbGljeSBpcyBnZW5lcmF0
ZWQgYnkgVFBNIGNvbW1hbmQsIHRwbTJfY3JlYXRlcG9saWN5LCBpdCBqdXN0IHVzZSB0aGUgYWxn
b3JpdGhtIHlvdSBtZW50aW9uZWQsIHdoaWNoIGlzIGRlZmluZWQgaW4gVFBNIHNwZWMuIA0KSSBy
ZS1hdHRhY2ggbXkgdGVzdCBzdGVwcyBhcyBiZWxvdy4gDQpQbGVhc2UgaGVscCBjaGVjayBpdCwg
aXMgdGhlcmUgYW55dGhpbmcgd3JvbmcsIGVzcGVjaWFsbHkgdGhlIGZvcm1hdCBvZiBrZXljdGwg
Y29tbWFuZC4gDQoNCkZpcnN0bHksIHRoZSBwY3IgcG9saWN5IGlzIGdlbmVyYXRlZCBhcyBiZWxv
dzogDQokIHRwbTJfY3JlYXRlcG9saWN5IC0tcG9saWN5LXBjciAtLXBjci1saXN0IHNoYTI1Njo3
IC0tcG9saWN5IHBjcjdfYmluLnBvbGljeSA+IHBjcjcucG9saWN5DQoNClBjcjcucG9saWN5IGlz
IHRoZSBhc2NpaSBoZXggb2YgcG9saWN5Og0KJCBjYXQgcGNyNy5wb2xpY3kNCjMyMWZiZDI4YjYw
ZmNjMjMwMTdkNTAxYjEzM2JkNWRiZjI4ODk4MTQ1ODhlOGEyMzUxMGZlMTAxMDVjYjJjYzkNCg0K
VGhlbiBnZW5lcmF0ZSB0aGUgdHJ1c3RlZCBrZXkgYW5kIGNvbmZpZ3VyZSBwb2xpY3lkaWdlc3Qg
YW5kIGdldCB0aGUga2V5IElEOiANCiQga2V5Y3RsIGFkZCB0cnVzdGVkIGttayAibmV3IDMyIGtl
eWhhbmRsZT0weDgxMDAwMDAxIGhhc2g9c2hhMjU2IHBvbGljeWRpZ2VzdD1gY2F0IHBjcjcucG9s
aWN5YCIgQHUNCjg3NDExNzA0NQ0KDQpTYXZlIHRoZSB0cnVzdGVkIGtleS4gDQokIGtleWN0bCBw
aXBlIDg3NDExNzA0NSA+IGttay5ibG9iDQoNClJlYm9vdCBhbmQgbG9hZCB0aGUga2V5LiANClN0
YXJ0IGEgYXV0aCBzZXNzaW9uIHRvIGdlbmVyYXRlIHRoZSBwb2xpY3k6DQokIHRwbTJfc3RhcnRh
dXRoc2Vzc2lvbiAtUyBzZXNzaW9uLmN0eA0Kc2Vzc2lvbi1oYW5kbGU6IDB4MzAwMDAwMA0KJCB0
cG0yX3Bjcmxpc3QgLUwgc2hhMjU2OjcgLW8gcGNyNy5zaGEyNTYgJCB0cG0yX3BvbGljeXBjciAt
UyBzZXNzaW9uLmN0eCAtTCBzaGEyNTY6NyAtRiBwY3I3LnNoYTI1NiAtZiBwY3I3LnBvbGljeQ0K
cG9saWN5LWRpZ2VzdDogMHgzMjFGQkQyOEI2MEZDQzIzMDE3RDUwMUIxMzNCRDVEQkYyODg5ODE0
NTg4RThBMjM1MTBGRTEwMTA1Q0IyQ0M5DQoNCklucHV0IHRoZSBwb2xpY3kgaGFuZGxlIHRvIGxv
YWQgdHJ1c3RlZCBrZXk6DQokIGtleWN0bCBhZGQgdHJ1c3RlZCBrbWsgImxvYWQgYGNhdCBrbWsu
YmxvYmAga2V5aGFuZGxlPTB4ODEwMDAwMDEgcG9saWN5aGFuZGxlPTB4MzAwMDAwMCIgQHUNCmFk
ZF9rZXk6IE9wZXJhdGlvbiBub3QgcGVybWl0dGVkDQoNClRoZSBlcnJvciBzaG91bGQgYmUgcG9s
aWN5IGNoZWNrIGZhaWxlZCwgYmVjYXVzZSBJIHVzZSBUUE0gY29tbWFuZCB0byB1bnNlYWwgZGly
ZWN0bHkgd2l0aCBlcnJvciBvZiBwb2xpY3kgY2hlY2sgZmFpbGVkLiANCiQgdHBtMl91bnNlYWwg
LWMgMHg4MTAwMDAwMSAtTCBzaGEyNTY6Nw0KRVJST1Igb24gbGluZTogIjgxIiBpbiBmaWxlOiAi
Li9saWIvbG9nLmgiOiBUc3MyX1N5c19VbnNlYWwoMHg5OUQpIC0gdHBtOnNlc3Npb24oMSk6YSBw
b2xpY3kgY2hlY2sgZmFpbGVkIEVSUk9SIG9uIGxpbmU6ICIyMTMiIGluIGZpbGU6ICJ0b29scy90
cG0yX3Vuc2VhbC5jIjogVW5zZWFsIGZhaWxlZCENCkVSUk9SIG9uIGxpbmU6ICIxNjYiIGluIGZp
bGU6ICJ0b29scy90cG0yX3Rvb2wuYyI6IFVuYWJsZSB0byBydW4gdHBtMl91bnNlYWwNCg0KLSBT
aGlybGV5IA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSmFtZXMgQm90dG9t
bGV5IDxqZWpiQGxpbnV4LmlibS5jb20+IA0KU2VudDogTW9uZGF5LCBEZWNlbWJlciAyLCAyMDE5
IDEyOjE3IFBNDQpUbzogWmhhbywgU2hpcmxleSA8c2hpcmxleS56aGFvQGludGVsLmNvbT47IE1p
bWkgWm9oYXIgPHpvaGFyQGxpbnV4LmlibS5jb20+OyBKYXJra28gU2Fra2luZW4gPGphcmtrby5z
YWtraW5lbkBsaW51eC5pbnRlbC5jb20+OyBKb25hdGhhbiBDb3JiZXQgPGNvcmJldEBsd24ubmV0
Pg0KQ2M6IGxpbnV4LWludGVncml0eUB2Z2VyLmtlcm5lbC5vcmc7IGtleXJpbmdzQHZnZXIua2Vy
bmVsLm9yZzsgbGludXgtZG9jQHZnZXIua2VybmVsLm9yZzsgbGludXgta2VybmVsQHZnZXIua2Vy
bmVsLm9yZzsgJ01hdXJvIENhcnZhbGhvIENoZWhhYicgPG1jaGVoYWIrc2Ftc3VuZ0BrZXJuZWwu
b3JnPjsgWmh1LCBCaW5nIDxiaW5nLnpodUBpbnRlbC5jb20+OyBDaGVuLCBMdWhhaSA8bHVoYWku
Y2hlbkBpbnRlbC5jb20+DQpTdWJqZWN0OiBSZTogT25lIHF1ZXN0aW9uIGFib3V0IHRydXN0ZWQg
a2V5IG9mIGtleXJpbmcgaW4gTGludXgga2VybmVsLg0KDQpPbiBNb24sIDIwMTktMTItMDIgYXQg
MDE6NDQgKzAwMDAsIFpoYW8sIFNoaXJsZXkgd3JvdGU6DQo+IEhpLCBKYW1lcywNCj4gDQo+IFRo
ZSB2YWx1ZSBvZiBQQ1I3IGlzIG5vdCBjaGFuZ2VkLiBJIGhhdmUgY2hlY2tlZCBpdCB3aXRoIFRQ
TSBjb21tYW5kIA0KPiB0cG1fcGNybGlzdC4NCj4gDQo+IFNvIEkgdGhpbmsgdGhlIHByb2JsZW0g
aXMgaG93IHRvIHVzZSB0aGUgb3B0aW9uIHBvbGljeWRpZ2VzdCBhbmQgDQo+IHBvbGljeWhhbmRs
ZT8gSXMgdGhlcmUgYW55IGV4YW1wbGU/DQo+IE1heWJlIHRoZSBmb3JtYXQgaW4gbXkgY29tbWFu
ZCBpcyBub3QgY29ycmVjdC4gDQoNCk9LLCBzbyBwcmV2aW91c2x5IHlvdSBzYWlkIHRoYXQgdXNp
bmcgdGhlIEludGVsIFRTUyB0aGUgcG9saWN5IGFsc28gZmFpbGVkIGFmdGVyIGEgcmVib290Og0K
DQo+IFRoZSBlcnJvciBzaG91bGQgYmUgcG9saWN5IGNoZWNrIGZhaWxlZCwgYmVjYXVzZSBJIHVz
ZSBUUE0gY29tbWFuZCB0byANCj4gdW5zZWFsIGRpcmVjdGx5IHdpdGggZXJyb3Igb2YgcG9saWN5
IGNoZWNrIGZhaWxlZC4NCj4gJCB0cG0yX3Vuc2VhbCAtYyAweDgxMDAwMDAxIC1MIHNoYTI1Njo3
IEVSUk9SIG9uIGxpbmU6ICI4MSIgaW4gZmlsZTogDQo+ICIuL2xpYi9sb2cuaCI6IFRzczJfU3lz
X1Vuc2VhbCgweDk5RCkgLSB0cG06c2Vzc2lvbigxKTphIHBvbGljeSBjaGVjayANCj4gZmFpbGVk
IEVSUk9SIG9uIGxpbmU6ICIyMTMiIGluIGZpbGU6ICJ0b29scy90cG0yX3Vuc2VhbC5jIjogVW5z
ZWFsIA0KPiBmYWlsZWQhDQo+IEVSUk9SIG9uIGxpbmU6ICIxNjYiIGluIGZpbGU6ICJ0b29scy90
cG0yX3Rvb2wuYyI6IFVuYWJsZSB0byBydW4gDQo+IHRwbTJfdW5zZWFsDQoNClNvIHRoaXMgbXVz
dCBtZWFuIHRoZSBhY3R1YWwgcG9saWN5IGhhc2ggeW91IGNvbnN0cnVjdGVkIHdhcyB3cm9uZyBp
biBzb21lIHdheTogaXQgZGlkbid0IGNvcnJlc3BvbmQgc2ltcGx5IHRvIGEgdmFsdWUgb2YgcGNy
NyAuLi4gd2VsbCBhc3N1bWluZyB0aGUgLUwgc2hhMjU2OjcgbWVhbnMgY29uc3RydWN0IGEgcG9s
aWN5IG9mIHRoZSBzaGEyNTYgdmFsdWUgb2YgcGNyNyBhbmQgdXNlIGl0IGluIHRoZSB1bnNlYWwu
DQoNCkkgY2FuIHRlbGwgeW91IGhvdyB0byBjb25zdHJ1Y3QgcG9saWNpZXMgdXNpbmcgVFBNMiBj
b21tYW5kcywgYnV0IEkgdGhpbmsgeW91IHdhbnQgdG8ga25vdyBob3cgdG8gZG8gaXQgdXNpbmcg
dGhlIEludGVsIFRTUz8gIEluIHdoaWNoIGNhc2UgeW91IHJlYWxseSBuZWVkIHRvIGNvbnN1bHQg
dGhlIGV4cGVydHMgaW4gdGhhdCBUU1MsIGxpa2UgUGhpbCBUcmljY2EuDQoNCkZvciB0aGUgcGxh
aW4gVFBNMiBjYXNlLCB0aGUgcG9saWN5IGxvb2tzIGxpa2UNCg0KVFBNX0NDX1BvbGljeVBDUiB8
fCBwY3JzIHx8IHBjckRpZ2VzdA0KDQpXaGVyZSBUUE1fQ0NfUG9saWN5UENSID0gMDAwMDAxN2Yg
YW5kIGZvciBzZWxlY3RpbmcgcGNyNyBvbmx5LiAgcGNycyBpcyBhIGNvbXBsaWNhdGVkIGVudGl0
eTogaXQncyBhIGNvdW50ZWQgYXJyYXkgb2YgcGNyIHNlbGVjdGlvbnMuICBGb3IgeW91ciBwb2xp
Y3kgeW91IG9ubHkgbmVlZCBvbmUgZW50cnksIHNvIGl0IHdvdWxkIGJlIDAwMDAwMDAxIGZvbGxv
d2VkIGJ5IGEgc2luZ2xlIHBjclNlbGVjdGlvbiBlbnRyeS4gIHBjclNlbGVjdGlvbiBpcyB0aGUg
aGFzaCBhbGdvcml0aG0sIHRoZSBzaXplIG9mIHRoZSBzZWxlY3Rpb24gYml0bWFwIChhbHdheXMg
MyBzaW5jZSBldmVyeSBjdXJyZW50IFRQTSBvbmx5IGhhcw0KMjQgUENScykgYW5kIGEgYml0bWFw
IHNlbGVjdGluZyB0aGUgUENScyBpbiBiaWcgZW5kaWFuIGZvcm1hdCwgc28gZm9yDQpQQ1I3IHVz
aW5nIHNoYTI1NiAoYWxnb3JpdGhtIDAwMGIpLCBwY3JTZWxlY3Rpb24gPSAwMDBiIDAzIDgwIDAw
IDAwLiANCkFuZCB0aGVuIHlvdSBmb2xsb3cgdGhpcyBieSB0aGUgaGFzaCBvZiB0aGUgUENSIHZh
bHVlIHlvdSdyZSBsb29raW5nIGZvci4gIFRoZSBwb2xpY3loYXNoIGJlY29tZXMgdGhlIGluaXRp
YWwgcG9saWN5IChhbGwgemVyb3MgZm9yIHRoZSBzdGFydCBvZiB0aGUgcG9saWN5IGNoYWluKSBo
YXNoZWQgd2l0aCB0aGlzLg0KDQpSZWdhcmRzLA0KDQpKYW1lcw0KDQo

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.

[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]

SGksIEphbWVzLCANCg0KVGhlIFBDUjcgdmFsdWUgYW5kIFBDUjcgcG9saWN5IGlzIGFzIGJlbG93
LCBwbGVhc2UgcmV2aWV3LCB0aGFua3MuIA0KDQojIHRwbTJfcGNybGlzdCAtTCBzaGEyNTY6NyAt
byBwY3I3XzIuc2hhMjU2DQpzaGEyNTY6DQogIDcgOiAweDA2MUFBRDA3MDVBNjIzNjFBRDE4RTU4
QjY1RDNENzM4M0Y0RDEwRjdGNUE3RTc4OTI0QkUwNTdBQzY3OTc0MDgNCg0KIyB0cG0yX2NyZWF0
ZXBvbGljeSAtLXBvbGljeS1wY3IgLS1wY3ItbGlzdCBzaGEyNTY6NyAtLXBvbGljeSBwY3I3X2Jp
bi5wb2xpY3kgPiBwY3I3LnBvbGljeQ0KMzIxZmJkMjhiNjBmY2MyMzAxN2Q1MDFiMTMzYmQ1ZGJm
Mjg4OTgxNDU4OGU4YTIzNTEwZmUxMDEwNWNiMmNjOQ0KDQojIGNhdCBwY3I3LnBvbGljeQ0KMzIx
ZmJkMjhiNjBmY2MyMzAxN2Q1MDFiMTMzYmQ1ZGJmMjg4OTgxNDU4OGU4YTIzNTEwZmUxMDEwNWNi
MmNjOQ0KDQotIFNoaXJsZXkgDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBK
YW1lcyBCb3R0b21sZXkgPGplamJAbGludXguaWJtLmNvbT4gDQpTZW50OiBNb25kYXksIERlY2Vt
YmVyIDIsIDIwMTkgMjoxOCBQTQ0KVG86IFpoYW8sIFNoaXJsZXkgPHNoaXJsZXkuemhhb0BpbnRl
bC5jb20+OyBNaW1pIFpvaGFyIDx6b2hhckBsaW51eC5pYm0uY29tPjsgSmFya2tvIFNha2tpbmVu
IDxqYXJra28uc2Fra2luZW5AbGludXguaW50ZWwuY29tPjsgSm9uYXRoYW4gQ29yYmV0IDxjb3Ji
ZXRAbHduLm5ldD4NCkNjOiBsaW51eC1pbnRlZ3JpdHlAdmdlci5rZXJuZWwub3JnOyBrZXlyaW5n
c0B2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4LWRvY0B2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4LWtlcm5l
bEB2Z2VyLmtlcm5lbC5vcmc7ICdNYXVybyBDYXJ2YWxobyBDaGVoYWInIDxtY2hlaGFiK3NhbXN1
bmdAa2VybmVsLm9yZz47IFpodSwgQmluZyA8YmluZy56aHVAaW50ZWwuY29tPjsgQ2hlbiwgTHVo
YWkgPGx1aGFpLmNoZW5AaW50ZWwuY29tPg0KU3ViamVjdDogUmU6IE9uZSBxdWVzdGlvbiBhYm91
dCB0cnVzdGVkIGtleSBvZiBrZXlyaW5nIGluIExpbnV4IGtlcm5lbC4NCg0KT24gTW9uLCAyMDE5
LTEyLTAyIGF0IDA1OjU1ICswMDAwLCBaaGFvLCBTaGlybGV5IHdyb3RlOg0KPiBUaGFua3MgZm9y
IHlvdXIgZmVlZGJhY2ssIEphbWVzLg0KPiANCj4gVGhlIHBvbGljeSBpcyBnZW5lcmF0ZWQgYnkg
VFBNIGNvbW1hbmQsIHRwbTJfY3JlYXRlcG9saWN5LCBpdCBqdXN0IHVzZSANCj4gdGhlIGFsZ29y
aXRobSB5b3UgbWVudGlvbmVkLCB3aGljaCBpcyBkZWZpbmVkIGluIFRQTSBzcGVjLg0KPiBJIHJl
LWF0dGFjaCBteSB0ZXN0IHN0ZXBzIGFzIGJlbG93LiANCj4gUGxlYXNlIGhlbHAgY2hlY2sgaXQs
IGlzIHRoZXJlIGFueXRoaW5nIHdyb25nLCBlc3BlY2lhbGx5IHRoZSBmb3JtYXQgDQo+IG9mIGtl
eWN0bCBjb21tYW5kLg0KPiANCj4gRmlyc3RseSwgdGhlIHBjciBwb2xpY3kgaXMgZ2VuZXJhdGVk
IGFzIGJlbG93OiANCj4gJCB0cG0yX2NyZWF0ZXBvbGljeSAtLXBvbGljeS1wY3IgLS1wY3ItbGlz
dCBzaGEyNTY6NyAtLXBvbGljeSANCj4gcGNyN19iaW4ucG9saWN5ID4gcGNyNy5wb2xpY3kNCg0K
SSBkb24ndCB1c2UgdGhlIEludGVsIFRTUywgc28gSSBjYW4ndCBoZWxwIHlvdSB3aXRoIHRoaXMg
Y29tbWFuZDogeW91IG5lZWQgdG8gYXNrIHNvbWVvbmUgd2hvIGRvZXMgdXNlIGl0IGl0LCBsaWtl
IFBoaWwuDQoNCj4gUGNyNy5wb2xpY3kgaXMgdGhlIGFzY2lpIGhleCBvZiBwb2xpY3k6DQo+ICQg
Y2F0IHBjcjcucG9saWN5DQo+IDMyMWZiZDI4YjYwZmNjMjMwMTdkNTAxYjEzM2JkNWRiZjI4ODk4
MTQ1ODhlOGEyMzUxMGZlMTAxMDVjYjJjYzkNCg0KWW91IGhhdmVuJ3QgcHJvdmlkZWQgZW5vdWdo
IGluZm9ybWF0aW9uLiAgSWYgeW91IHRlbGwgbWUgd2hhdCB0aGUgcGNyNyB2YWx1ZSB5b3UgdGll
ZCB0aGUgcG9saWN5IHRvIGlzLCBJIGNhbiBydW4gaXQgdGhyb3VnaCB0aGUgSUJNIFRTUyBwb2xp
Y3kgbWFrZXIgYW5kIHRlbGwgeW91IGlmIHRoaXMgaXMgdGhlIGNvcnJlY3QgaGFzaC4gIEJ1dCBv
YnZpb3VzbHksIHNpbmNlIGl0J3MgYSBoYXNoLCBJIGNhbid0IHJldmVyc2UgaXQgdG8gdGVsbCB5
b3Ugd2hhdCB0aGUgcG9saWN5IGl0IG1hbmRhdGVzIGlzLg0KDQpKYW1lcw0KDQo+IFRoZW4gZ2Vu
ZXJhdGUgdGhlIHRydXN0ZWQga2V5IGFuZCBjb25maWd1cmUgcG9saWN5ZGlnZXN0IGFuZCBnZXQg
dGhlIA0KPiBrZXkgSUQ6DQo+ICQga2V5Y3RsIGFkZCB0cnVzdGVkIGttayAibmV3IDMyIGtleWhh
bmRsZT0weDgxMDAwMDAxIGhhc2g9c2hhMjU2IA0KPiBwb2xpY3lkaWdlc3Q9YGNhdCBwY3I3LnBv
bGljeWAiIEB1DQo+IDg3NDExNzA0NQ0KPiANCj4gU2F2ZSB0aGUgdHJ1c3RlZCBrZXkuIA0KPiAk
IGtleWN0bCBwaXBlIDg3NDExNzA0NSA+IGttay5ibG9iDQo+IA0KPiBSZWJvb3QgYW5kIGxvYWQg
dGhlIGtleS4gDQo+IFN0YXJ0IGEgYXV0aCBzZXNzaW9uIHRvIGdlbmVyYXRlIHRoZSBwb2xpY3k6
DQo+ICQgdHBtMl9zdGFydGF1dGhzZXNzaW9uIC1TIHNlc3Npb24uY3R4DQo+IHNlc3Npb24taGFu
ZGxlOiAweDMwMDAwMDANCj4gJCB0cG0yX3Bjcmxpc3QgLUwgc2hhMjU2OjcgLW8gcGNyNy5zaGEy
NTYgJCB0cG0yX3BvbGljeXBjciAtUyANCj4gc2Vzc2lvbi5jdHggLUwgc2hhMjU2OjcgLUYgcGNy
Ny5zaGEyNTYgLWYgcGNyNy5wb2xpY3kNCj4gcG9saWN5LWRpZ2VzdDoNCj4gMHgzMjFGQkQyOEI2
MEZDQzIzMDE3RDUwMUIxMzNCRDVEQkYyODg5ODE0NTg4RThBMjM1MTBGRTEwMTA1Q0IyQ0M5DQo+
IA0KPiBJbnB1dCB0aGUgcG9saWN5IGhhbmRsZSB0byBsb2FkIHRydXN0ZWQga2V5Og0KPiAkIGtl
eWN0bCBhZGQgdHJ1c3RlZCBrbWsgImxvYWQgYGNhdCBrbWsuYmxvYmAga2V5aGFuZGxlPTB4ODEw
MDAwMDEgDQo+IHBvbGljeWhhbmRsZT0weDMwMDAwMDAiIEB1DQo+IGFkZF9rZXk6IE9wZXJhdGlv
biBub3QgcGVybWl0dGVkDQo+IA0KPiBUaGUgZXJyb3Igc2hvdWxkIGJlIHBvbGljeSBjaGVjayBm
YWlsZWQsIGJlY2F1c2UgSSB1c2UgVFBNIGNvbW1hbmQgdG8gDQo+IHVuc2VhbCBkaXJlY3RseSB3
aXRoIGVycm9yIG9mIHBvbGljeSBjaGVjayBmYWlsZWQuDQo+ICQgdHBtMl91bnNlYWwgLWMgMHg4
MTAwMDAwMSAtTCBzaGEyNTY6NyBFUlJPUiBvbiBsaW5lOiAiODEiIGluIGZpbGU6IA0KPiAiLi9s
aWIvbG9nLmgiOiBUc3MyX1N5c19VbnNlYWwoMHg5OUQpIC0gdHBtOnNlc3Npb24oMSk6YSBwb2xp
Y3kgY2hlY2sgDQo+IGZhaWxlZCBFUlJPUiBvbiBsaW5lOiAiMjEzIiBpbiBmaWxlOg0KPiAidG9v
bHMvdHBtMl91bnNlYWwuYyI6IFVuc2VhbCBmYWlsZWQhDQo+IEVSUk9SIG9uIGxpbmU6ICIxNjYi
IGluIGZpbGU6ICJ0b29scy90cG0yX3Rvb2wuYyI6IFVuYWJsZSB0byBydW4gDQo+IHRwbTJfdW5z
ZWFsDQo+IA0KPiAtIFNoaXJsZXkNCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+
IEZyb206IEphbWVzIEJvdHRvbWxleSA8amVqYkBsaW51eC5pYm0uY29tPg0KPiBTZW50OiBNb25k
YXksIERlY2VtYmVyIDIsIDIwMTkgMTI6MTcgUE0NCj4gVG86IFpoYW8sIFNoaXJsZXkgPHNoaXJs
ZXkuemhhb0BpbnRlbC5jb20+OyBNaW1pIFpvaGFyIDx6b2hhckBsaW51eC5pIA0KPiBibS5jb20+
OyBKYXJra28gU2Fra2luZW4gPGphcmtrby5zYWtraW5lbkBsaW51eC5pbnRlbC5jb20+OyBKb25h
dGhhbiANCj4gQ29yYmV0IDxjb3JiZXRAbHduLm5ldD4NCj4gQ2M6IGxpbnV4LWludGVncml0eUB2
Z2VyLmtlcm5lbC5vcmc7IGtleXJpbmdzQHZnZXIua2VybmVsLm9yZzsgbGludXgtIA0KPiBkb2NA
dmdlci5rZXJuZWwub3JnOyBsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnOyAnTWF1cm8gQ2Fy
dmFsaG8gDQo+IENoZWhhYicgPG1jaGVoYWIrc2Ftc3VuZ0BrZXJuZWwub3JnPjsgWmh1LCBCaW5n
IDxiaW5nLnpodUBpbnRlbC5jb20+OyANCj4gQ2hlbiwgTHVoYWkgPGx1aGFpLmNoZW5AaW50ZWwu
Y29tPg0KPiBTdWJqZWN0OiBSZTogT25lIHF1ZXN0aW9uIGFib3V0IHRydXN0ZWQga2V5IG9mIGtl
eXJpbmcgaW4gTGludXggDQo+IGtlcm5lbC4NCj4gDQo+IE9uIE1vbiwgMjAxOS0xMi0wMiBhdCAw
MTo0NCArMDAwMCwgWmhhbywgU2hpcmxleSB3cm90ZToNCj4gPiBIaSwgSmFtZXMsDQo+ID4gDQo+
ID4gVGhlIHZhbHVlIG9mIFBDUjcgaXMgbm90IGNoYW5nZWQuIEkgaGF2ZSBjaGVja2VkIGl0IHdp
dGggVFBNIGNvbW1hbmQgDQo+ID4gdHBtX3Bjcmxpc3QuDQo+ID4gDQo+ID4gU28gSSB0aGluayB0
aGUgcHJvYmxlbSBpcyBob3cgdG8gdXNlIHRoZSBvcHRpb24gcG9saWN5ZGlnZXN0IGFuZCANCj4g
PiBwb2xpY3loYW5kbGU/IElzIHRoZXJlIGFueSBleGFtcGxlPw0KPiA+IE1heWJlIHRoZSBmb3Jt
YXQgaW4gbXkgY29tbWFuZCBpcyBub3QgY29ycmVjdC4gDQo+IA0KPiBPSywgc28gcHJldmlvdXNs
eSB5b3Ugc2FpZCB0aGF0IHVzaW5nIHRoZSBJbnRlbCBUU1MgdGhlIHBvbGljeSBhbHNvIA0KPiBm
YWlsZWQgYWZ0ZXIgYSByZWJvb3Q6DQo+IA0KPiA+IFRoZSBlcnJvciBzaG91bGQgYmUgcG9saWN5
IGNoZWNrIGZhaWxlZCwgYmVjYXVzZSBJIHVzZSBUUE0gY29tbWFuZCANCj4gPiB0byB1bnNlYWwg
ZGlyZWN0bHkgd2l0aCBlcnJvciBvZiBwb2xpY3kgY2hlY2sgZmFpbGVkLg0KPiA+ICQgdHBtMl91
bnNlYWwgLWMgMHg4MTAwMDAwMSAtTCBzaGEyNTY6NyBFUlJPUiBvbiBsaW5lOiAiODEiIGluDQo+
ID4gZmlsZTogDQo+ID4gIi4vbGliL2xvZy5oIjogVHNzMl9TeXNfVW5zZWFsKDB4OTlEKSAtIHRw
bTpzZXNzaW9uKDEpOmEgcG9saWN5IA0KPiA+IGNoZWNrIGZhaWxlZCBFUlJPUiBvbiBsaW5lOiAi
MjEzIiBpbiBmaWxlOiAidG9vbHMvdHBtMl91bnNlYWwuYyI6IA0KPiA+IFVuc2VhbCBmYWlsZWQh
DQo+ID4gRVJST1Igb24gbGluZTogIjE2NiIgaW4gZmlsZTogInRvb2xzL3RwbTJfdG9vbC5jIjog
VW5hYmxlIHRvIHJ1biANCj4gPiB0cG0yX3Vuc2VhbA0KPiANCj4gU28gdGhpcyBtdXN0IG1lYW4g
dGhlIGFjdHVhbCBwb2xpY3kgaGFzaCB5b3UgY29uc3RydWN0ZWQgd2FzIHdyb25nIGluIA0KPiBz
b21lIHdheTogaXQgZGlkbid0IGNvcnJlc3BvbmQgc2ltcGx5IHRvIGEgdmFsdWUgb2YgcGNyNyAu
Li4gd2VsbCANCj4gYXNzdW1pbmcgdGhlIC1MIHNoYTI1Njo3IG1lYW5zIGNvbnN0cnVjdCBhIHBv
bGljeSBvZiB0aGUgc2hhMjU2IHZhbHVlIA0KPiBvZiBwY3I3IGFuZCB1c2UgaXQgaW4gdGhlIHVu
c2VhbC4NCj4gDQo+IEkgY2FuIHRlbGwgeW91IGhvdyB0byBjb25zdHJ1Y3QgcG9saWNpZXMgdXNp
bmcgVFBNMiBjb21tYW5kcywgYnV0IEkgDQo+IHRoaW5rIHlvdSB3YW50IHRvIGtub3cgaG93IHRv
IGRvIGl0IHVzaW5nIHRoZSBJbnRlbCBUU1M/ICBJbiB3aGljaCANCj4gY2FzZSB5b3UgcmVhbGx5
IG5lZWQgdG8gY29uc3VsdCB0aGUgZXhwZXJ0cyBpbiB0aGF0IFRTUywgbGlrZSBQaGlsIA0KPiBU
cmljY2EuDQo+IA0KPiBGb3IgdGhlIHBsYWluIFRQTTIgY2FzZSwgdGhlIHBvbGljeSBsb29rcyBs
aWtlDQo+IA0KPiBUUE1fQ0NfUG9saWN5UENSIHx8IHBjcnMgfHwgcGNyRGlnZXN0DQo+IA0KPiBX
aGVyZSBUUE1fQ0NfUG9saWN5UENSID0gMDAwMDAxN2YgYW5kIGZvciBzZWxlY3RpbmcgcGNyNyBv
bmx5LiAgcGNycyANCj4gaXMgYSBjb21wbGljYXRlZCBlbnRpdHk6IGl0J3MgYSBjb3VudGVkIGFy
cmF5IG9mIHBjciBzZWxlY3Rpb25zLiAgRm9yIA0KPiB5b3VyIHBvbGljeSB5b3Ugb25seSBuZWVk
IG9uZSBlbnRyeSwgc28gaXQgd291bGQgYmUgMDAwMDAwMDEgZm9sbG93ZWQgDQo+IGJ5IGEgc2lu
Z2xlIHBjclNlbGVjdGlvbiBlbnRyeS4gIHBjclNlbGVjdGlvbiBpcyB0aGUgaGFzaCBhbGdvcml0
aG0sIA0KPiB0aGUgc2l6ZSBvZiB0aGUgc2VsZWN0aW9uIGJpdG1hcCAoYWx3YXlzIDMgc2luY2Ug
ZXZlcnkgY3VycmVudCBUUE0gDQo+IG9ubHkgaGFzDQo+IDI0IFBDUnMpIGFuZCBhIGJpdG1hcCBz
ZWxlY3RpbmcgdGhlIFBDUnMgaW4gYmlnIGVuZGlhbiBmb3JtYXQsIHNvIGZvcg0KPiBQQ1I3IHVz
aW5nIHNoYTI1NiAoYWxnb3JpdGhtIDAwMGIpLCBwY3JTZWxlY3Rpb24gPSAwMDBiIDAzIDgwIDAw
IDAwLiANCj4gQW5kIHRoZW4geW91IGZvbGxvdyB0aGlzIGJ5IHRoZSBoYXNoIG9mIHRoZSBQQ1Ig
dmFsdWUgeW91J3JlIGxvb2tpbmcgDQo+IGZvci4gIFRoZSBwb2xpY3loYXNoIGJlY29tZXMgdGhl
IGluaXRpYWwgcG9saWN5IChhbGwgemVyb3MgZm9yIHRoZSANCj4gc3RhcnQgb2YgdGhlIHBvbGlj
eSBjaGFpbikgaGFzaGVkIHdpdGggdGhpcy4NCj4gDQo+IFJlZ2FyZHMsDQo+IA0KPiBKYW1lcw0K
PiANCg0K

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.

[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]

U28gSSBndWVzcyBtb3N0bHkgbGlrZSwgaXQgaXMgdGhlIGZvcm1hdCBvZiBwb2xpY3lkaWdlc3Qs
IHBvbGljeWhhbmRsZSBpcyBub3QgY29ycmVjdGx5IGluIG15IGtleWN0bCBjb21tYW5kLiANCkJ1
dCB3aGF0IGlzIHRoZSBjb3JyZWN0IHVzaW5nPw0KDQpNeSBrZXljdGwgY29tbWFuZHMgYXJlIGF0
dGFjaGVkIGFzIGJlbG93OiANCiQga2V5Y3RsIGFkZCB0cnVzdGVkIGttayAibmV3IDMyIGtleWhh
bmRsZT0weDgxMDAwMDAxIGhhc2g9c2hhMjU2IHBvbGljeWRpZ2VzdD1gY2F0IHBjcjcucG9saWN5
YCIgQHUNCjg3NDExNzA0NQ0KDQpTYXZlIHRoZSB0cnVzdGVkIGtleS4gDQokIGtleWN0bCBwaXBl
IDg3NDExNzA0NSA+IGttay5ibG9iDQoNClJlYm9vdCBhbmQgbG9hZCB0aGUga2V5LiANClN0YXJ0
IGEgYXV0aCBzZXNzaW9uIHRvIGdlbmVyYXRlIHRoZSBwb2xpY3k6DQokIHRwbTJfc3RhcnRhdXRo
c2Vzc2lvbiAtUyBzZXNzaW9uLmN0eA0Kc2Vzc2lvbi1oYW5kbGU6IDB4MzAwMDAwMA0KJCB0cG0y
X3Bjcmxpc3QgLUwgc2hhMjU2OjcgLW8gcGNyNy5zaGEyNTYgJCB0cG0yX3BvbGljeXBjciAtUyBz
ZXNzaW9uLmN0eCAtTCBzaGEyNTY6NyAtRiBwY3I3LnNoYTI1NiAtZiBwY3I3LnBvbGljeQ0KcG9s
aWN5LWRpZ2VzdDogMHgzMjFGQkQyOEI2MEZDQzIzMDE3RDUwMUIxMzNCRDVEQkYyODg5ODE0NTg4
RThBMjM1MTBGRTEwMTA1Q0IyQ0M5DQoNCklucHV0IHRoZSBwb2xpY3kgaGFuZGxlIHRvIGxvYWQg
dHJ1c3RlZCBrZXk6DQokIGtleWN0bCBhZGQgdHJ1c3RlZCBrbWsgImxvYWQgYGNhdCBrbWsuYmxv
YmAga2V5aGFuZGxlPTB4ODEwMDAwMDEgcG9saWN5aGFuZGxlPTB4MzAwMDAwMCIgQHUNCmFkZF9r
ZXk6IE9wZXJhdGlvbiBub3QgcGVybWl0dGVkDQoNCg0KVGhhbmtzLiANCg0KLSBTaGlybGV5IA0K
DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBKYW1lcyBCb3R0b21sZXkgPGpl
amJAbGludXguaWJtLmNvbT4gDQpTZW50OiBNb25kYXksIERlY2VtYmVyIDIsIDIwMTkgMjo0NSBQ
TQ0KVG86IFpoYW8sIFNoaXJsZXkgPHNoaXJsZXkuemhhb0BpbnRlbC5jb20+OyBNaW1pIFpvaGFy
IDx6b2hhckBsaW51eC5pYm0uY29tPjsgSmFya2tvIFNha2tpbmVuIDxqYXJra28uc2Fra2luZW5A
bGludXguaW50ZWwuY29tPjsgSm9uYXRoYW4gQ29yYmV0IDxjb3JiZXRAbHduLm5ldD4NCkNjOiBs
aW51eC1pbnRlZ3JpdHlAdmdlci5rZXJuZWwub3JnOyBrZXlyaW5nc0B2Z2VyLmtlcm5lbC5vcmc7
IGxpbnV4LWRvY0B2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7
ICdNYXVybyBDYXJ2YWxobyBDaGVoYWInIDxtY2hlaGFiK3NhbXN1bmdAa2VybmVsLm9yZz47IFpo
dSwgQmluZyA8YmluZy56aHVAaW50ZWwuY29tPjsgQ2hlbiwgTHVoYWkgPGx1aGFpLmNoZW5AaW50
ZWwuY29tPg0KU3ViamVjdDogUmU6IE9uZSBxdWVzdGlvbiBhYm91dCB0cnVzdGVkIGtleSBvZiBr
ZXlyaW5nIGluIExpbnV4IGtlcm5lbC4NCg0KT24gTW9uLCAyMDE5LTEyLTAyIGF0IDA2OjIzICsw
MDAwLCBaaGFvLCBTaGlybGV5IHdyb3RlOg0KPiBIaSwgSmFtZXMsDQo+IA0KPiBUaGUgUENSNyB2
YWx1ZSBhbmQgUENSNyBwb2xpY3kgaXMgYXMgYmVsb3csIHBsZWFzZSByZXZpZXcsIHRoYW5rcy4g
DQo+IA0KPiAjIHRwbTJfcGNybGlzdCAtTCBzaGEyNTY6NyAtbyBwY3I3XzIuc2hhMjU2DQo+IHNo
YTI1NjoNCj4gICA3IDoNCj4gMHgwNjFBQUQwNzA1QTYyMzYxQUQxOEU1OEI2NUQzRDczODNGNEQx
MEY3RjVBN0U3ODkyNEJFMDU3QUM2Nzk3NDA4DQo+IA0KPiAjIHRwbTJfY3JlYXRlcG9saWN5IC0t
cG9saWN5LXBjciAtLXBjci1saXN0IHNoYTI1Njo3IC0tcG9saWN5IA0KPiBwY3I3X2Jpbi5wb2xp
Y3kgPiBwY3I3LnBvbGljeQ0KPiAzMjFmYmQyOGI2MGZjYzIzMDE3ZDUwMWIxMzNiZDVkYmYyODg5
ODE0NTg4ZThhMjM1MTBmZTEwMTA1Y2IyY2M5DQo+IA0KPiAjIGNhdCBwY3I3LnBvbGljeQ0KPiAz
MjFmYmQyOGI2MGZjYzIzMDE3ZDUwMWIxMzNiZDVkYmYyODg5ODE0NTg4ZThhMjM1MTBmZTEwMTA1
Y2IyY2M5DQoNCldlbGwsIHRoZSBJQk0gVFNTIHNheXMgdGhhdCdzIHRoZSBjb3JyZWN0IHBvbGlj
eS4gIFlvdXIgcG9saWN5IGNvbW1hbmQgaXMNCg0KamVqYkBqYXJ2aXM6fj4gdHNzcG9saWN5bWFr
ZXJwY3IgLWJtIDAwMDA4MCAtaWYgfi9wY3I3LnR4dCAtcHIgfCB0ZWUgdG1wLnBvbGljeSAwMDAw
MDE3ZjAwMDAwMDAxMDAwYjAzODAwMDAwOWE0NzM1MGZkYmNjNzdlYmVhZGNiNGI0ODE4ZDhlODJh
MjE3MTdlYTI0NDM0MzMzYzc5MWMwY2QwZDFkYzE0ZQ0KDQpBbmQgdGhhdCBoYXNoZXMgdG8NCmpl
amJAamFydmlzOn4+IHRzc3BvbGljeW1ha2VyIC1pZiB+L3RtcC5wb2xpY3kgIC1wciAgcG9saWN5
IGRpZ2VzdCBsZW5ndGggMzINCiAzMiAxZiBiZCAyOCBiNiAwZiBjYyAyMyAwMSA3ZCA1MCAxYiAx
MyAzYiBkNSBkYg0KIGYyIDg4IDk4IDE0IDU4IDhlIDhhIDIzIDUxIDBmIGUxIDAxIDA1IGNiIDJj
IGM5IA0KDQpTbyBJIGRvbid0IHVuZGVyc3RhbmQgd2h5IHRoZSB1c2Vyc3BhY2UgSW50ZWwgVFNT
IGNvbW1hbmQgaXMgZmFpbGluZyB0byBkbyB0aGUgdW5zZWFsLg0KDQpKYW1lcw0KDQo

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.

[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]

VGhhbmtzIHNvIG11Y2ggZm9yIHlvdSBmZWVkYmFjaywgSmFtZXMuIA0KQW5kIGdsYWQgdG8gaGVh
ciB0aGF0IHRoZSBBUEkgd2lsbCBiZSBtYWRlIG1vcmUgZnJpZW5kbHkuIA0KDQpCdXQgSSBoYXZl
IGEgbGl0dGxlIGNvbmZ1c2VkIGFib3V0IHRoZSBjYWxsIHN0YWNrLiANCkZyb20gdGhlIGRvY3Vt
ZW50LCBodHRwczovL2dpdGh1Yi5jb20vdG9ydmFsZHMvbGludXgvYmxvYi9tYXN0ZXIvRG9jdW1l
bnRhdGlvbi9zZWN1cml0eS9rZXlzL3RydXN0ZWQtZW5jcnlwdGVkLnJzdCBhbmQgDQpodHRwczov
L2dpdGh1Yi5jb20vemZzb25saW51eC9kcmFjdXQvdHJlZS9tYXN0ZXIvbW9kdWxlcy5kLzk3bWFz
dGVya2V5LCB0aGUgdHJ1c3RlZCBrZXkgaXMgYSByYW5kb20gbnVtYmVyIGFuZCBnZW5lcmF0ZWQg
YnkgVFBNMi4wIGFuZCBzZWFsZWQgd2l0aCBUUE0yLjAgMjA0OCBSU0Ega2V5LiANCg0KVGhlIDIw
NDggUlNBIGtleSBpcyBnZW5lcmF0ZWQgYnkgdHBtMl9jcmVhdGVwcmltYXJ5LCBhbmQgaXQgY2Fu
IGJlIGdvdCBieSB0aGUgVFBNMi4wIGhhbmRsZSwganVzdCB0aGUgImtleWhhbmRsZSIgdXNlZCBp
biB0aGUgZm9sbG93aW5nIGtleWN0bCBjb21tYW5kLiANCiQga2V5Y3RsIGFkZCB0cnVzdGVkIGtt
ayAibmV3IDMyIGtleWhhbmRsZT0weDgxMDAwMDAxIGhhc2g9c2hhMjU2IHBvbGljeWRpZ2VzdD1g
Y2F0IHBjcjcucG9saWN5YCIgQHUNCg0KSWYgcmVib290LCB0byByZS1sb2FkIHRoZSB0cnVzdGVk
IGtleSBiYWNrIHRvIGtleXJpbmcsIGp1c3QgY2FsbCB0cG0yX3Vuc2VhbCBpcyBlbm91Z2gsIGRv
bid0IG5lZWQgdG8gY2FsbCB0cG0yX2xvYWQgdG8gbG9hZCB0aGUgVFBNMi4wIDIwNDggUlNBIGtl
eS4NCklmIHRoZSB0cnVzdGVkIGtleSBpcyBhbHNvIHByb3RlY3RlZCBieSBwb2xpY3ksIHRoZW4g
dGhlIHBvbGljeSB3aWxsIGJlIGNoZWNrZWQgZHVyaW5nIHRwbTJfdW5zZWFsLiANCg0KQWZ0ZXIg
Y2hlY2sgdGhlIHNvdXJjZSBjb2RlLCB0aGUgY2FsbCBzdGFjayBpcyBtb3N0bHkgbGlrZTogDQpT
WVNDQUxMX0RFRklORTUoYWRkX2tleSwuLi4pIC0tPiBrZXlfY3JlYXRlX29yX3VwZGF0ZSgpIC0t
PiBfX2tleV9pbnN0YW50aWF0ZV9hbmRfbGluaygpIC0tPiAgdHJ1c3RlZF9pbnN0YW50aWF0ZSgp
IC0tPiB0cG0yX3Vuc2VhbF90cnVzdGVkKCkgLS0+IHRwbTJfdW5zZWFsX2NtZCgpLg0KDQpBbm90
aGVyIHByb2JsZW0gaGVyZSBpcywgdG8gYnVpbGQgdGhlIHBvbGljeSB0byB1bnNlYWwgdGhlIGtl
eSwgaXQgbmVlZCB0byBzdGFydCBhbiBwb2xpY3kgc2Vzc2lvbiwgYW5kIHRyYW5zZmVyIHRoZSBz
ZXNzaW9uIGhhbmRsZSB0byBUUE0yLjAgdW5zZWFsIGNvbW1hbmQuIA0KSW4gbXkga2V5Y3RsIGNv
bW1hbmQsIEkgdXNlIHRwbTIuMCBjb21tYW5kIHRvIHN0YXJ0IHRoZSBzZXNzaW9uIGFuZCBnZXQg
dGhlIGhhbmRsZSwgcHV0IGl0IGludG8gdGhlIGtleWN0bCBjb21tYW5kIGxpa2U6DQprZXljdGwg
YWRkIHRydXN0ZWQga21rICJsb2FkIGBjYXQga21rLmJsb2JgIGtleWhhbmRsZT0weDgxMDAwMDAx
IHBvbGljeWhhbmRsZT0weDMwMDAwMDAiIEB1DQoNCkkgYW0gbm90IHN1cmUgd2hldGhlciBpdCBp
cyBjb3JyZWN0LiANCg0KVGhhbmtzLiANCg0KLSBTaGlybGV5IA0KDQoNCi0tLS0tT3JpZ2luYWwg
TWVzc2FnZS0tLS0tDQpGcm9tOiBKYW1lcyBCb3R0b21sZXkgPGplamJAbGludXguaWJtLmNvbT4g
DQpTZW50OiBUdWVzZGF5LCBEZWNlbWJlciAzLCAyMDE5IDI6NTYgQU0NClRvOiBaaGFvLCBTaGly
bGV5IDxzaGlybGV5LnpoYW9AaW50ZWwuY29tPjsgTWltaSBab2hhciA8em9oYXJAbGludXguaWJt
LmNvbT47IEphcmtrbyBTYWtraW5lbiA8amFya2tvLnNha2tpbmVuQGxpbnV4LmludGVsLmNvbT47
IEpvbmF0aGFuIENvcmJldCA8Y29yYmV0QGx3bi5uZXQ+DQpDYzogbGludXgtaW50ZWdyaXR5QHZn
ZXIua2VybmVsLm9yZzsga2V5cmluZ3NAdmdlci5rZXJuZWwub3JnOyBsaW51eC1kb2NAdmdlci5r
ZXJuZWwub3JnOyBsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnOyAnTWF1cm8gQ2FydmFsaG8g
Q2hlaGFiJyA8bWNoZWhhYitzYW1zdW5nQGtlcm5lbC5vcmc+OyBaaHUsIEJpbmcgPGJpbmcuemh1
QGludGVsLmNvbT47IENoZW4sIEx1aGFpIDxsdWhhaS5jaGVuQGludGVsLmNvbT4NClN1YmplY3Q6
IFJlOiBPbmUgcXVlc3Rpb24gYWJvdXQgdHJ1c3RlZCBrZXkgb2Yga2V5cmluZyBpbiBMaW51eCBr
ZXJuZWwuDQoNCk9uIE1vbiwgMjAxOS0xMi0wMiBhdCAwNjo1MCArMDAwMCwgWmhhbywgU2hpcmxl
eSB3cm90ZToNCj4gU28gSSBndWVzcyBtb3N0bHkgbGlrZSwgaXQgaXMgdGhlIGZvcm1hdCBvZiBw
b2xpY3lkaWdlc3QsIHBvbGljeWhhbmRsZSANCj4gaXMgbm90IGNvcnJlY3RseSBpbiBteSBrZXlj
dGwgY29tbWFuZC4NCj4gQnV0IHdoYXQgaXMgdGhlIGNvcnJlY3QgdXNpbmc/DQo+IA0KPiBNeSBr
ZXljdGwgY29tbWFuZHMgYXJlIGF0dGFjaGVkIGFzIGJlbG93OiANCj4gJCBrZXljdGwgYWRkIHRy
dXN0ZWQga21rICJuZXcgMzIga2V5aGFuZGxlPTB4ODEwMDAwMDEgaGFzaD1zaGEyNTYgDQo+IHBv
bGljeWRpZ2VzdD1gY2F0IHBjcjcucG9saWN5YCIgQHUNCj4gODc0MTE3MDQ1DQo+IA0KPiBTYXZl
IHRoZSB0cnVzdGVkIGtleS4gDQo+ICQga2V5Y3RsIHBpcGUgODc0MTE3MDQ1ID4ga21rLmJsb2IN
Cg0KT0ssIGxvb2tpbmcgYXQgdGhlIGFjdHVhbCBjb2RlLCBpdCBzZWVtcyB0aGF0IHdob2V2ZXIg
d3JvdGUgaXQgZGlkbid0IGFjY291bnQgZm9yIHRoZSBkaWZmZXJlbmNlcyBiZXR3ZWVuIFRQTTEu
MiBhbmQgVFBNMi4wLiAgV2l0aCBUUE0yLjAgVFBNMl9DcmVhdGUgcmV0dXJucyB0aGUgcHVibGlj
IGFuZCBwcml2YXRlIHBhcnRzIHBsdXMgdGhyZWUgb3RoZXIgdHBtMmIgZW50aXRlcyB1c2VkIHRv
IGNlcnRpZnkgYW5kIGNoZWNrIHRoZSBrZXkuICBXaGVuIHlvdSBsb2FkIHRoZSBibG9iIGJhY2sg
dXNpbmcgVFBNMl9Mb2FkLCBpdCBvbmx5IGFjY2VwdHMgdGhlIHB1YmxpYyBhbmQgcHJpdmF0ZSBw
YXJ0cy4gDQpIb3dldmVyLCB5b3VyIGJsb2IgY29udGFpbnMgdGhlIG90aGVyIGV4dHJhbmVvdXMg
ZWxlbWVudHMsIHRoYXQncyB3aHkgaXQgY2FuJ3QgYmUgbG9hZGVkLiAgWW91IGNvdWxkIG1ha2Ug
aXQgbG9hZGFibGUgYnkgc3RyaXBwaW5nIG9mZiB0aGUgZXh0cmFuZW91cyBwaWVjZXMgLi4uIGp1
c3QgdGFrZSB0aGUgZmlyc3QgdHdvIHRwbTJiIGVsZW1lbnRzIG9mIHRoZSBibG9iIGJ1dCBpdCBs
b29rcyBsaWtlIHdlIG5lZWQgdG8gZml4IHRoZSBBUEkuICBJIHN1cHBvc2UgdGhlIGdvb2QgbmV3
cyBpcyBnaXZlbiB0aGlzIGZhaWx1cmUgdGhhdCB3ZSBoYXZlIHRoZSBvcHBvcnR1bml0eSB0byBy
ZXdyaXRlIHRoZSBBUEkgc2luY2Ugbm8tb25lIGVsc2UgY2FuIGhhdmUgdXNlZCBpdCBmb3IgYW55
dGhpbmcgYmVjYXVzZSBvZiB0aGlzLiAgVGhlIGZ1bmRhbWVudGFsIHByb2JsZW0gd2l0aCB0aGUg
Y3VycmVudCBBUEkgaXMgdGhhdCBtb3N0IFRQTTIncyBvbmx5IGhhdmUgdGhyZWUgYXZhaWxhYmxl
IHNlc3Npb24gcmVnaXN0ZXJzLiAgSXQncyBzaW1wbHkgbm90IHNjYWxhYmxlIHRvIHNldCB0aGVt
IHVwIGluIHVzZXJzcGFjZSBhbmQgaGF2ZSB0aGUga2VybmVsIHVzZSB0aGVtLCBzbyB3aGF0IHdl
IHNob3VsZCBiZSBkb2luZyBpcyBwYXNzaW5nIGRvd24gdGhlIGFjdHVhbCBwb2xpY3kgYW5kIGhh
dmluZyB0aGUga2VybmVsIGNvbnN0cnVjdCB0aGUgc2Vzc2lvbiBhdCB0aGUgcG9pbnQgb2YgdXNl
IGFuZCB0aGVuIGZsdXNoIGl0LCB0aHVzIHNvbHZpbmcgdGhlIHBvdGVudGlhbCBzZXNzaW9uIGV4
aGF1c3Rpb24gaXNzdWUuDQoNCkknZCBhY3R1YWxseSBwcm9wb3NlIHdlIG1ha2UgYSBUU1NMT0FE
QUJMRSB0aGUgZnVuZGFtZW50YWwgZWxlbWVudCBvZiBvcGVyYXRpb24gZm9yIHRydXN0ZWQga2V5
cy4gIFRoZSBJQk0gYW5kIEludGVsIFRTUyBwZW9wbGUgaGF2ZSBhZ3JlZWQgdG8gZG8gdGhpcyBh
cyB0aGUgZm9ybWF0IGZvciBUUE0gbG9hZGFibGUga2V5cywgYnV0IGl0IHNob3VsZCBhbHNvIGFw
cGx5IHRvIHNlYWxlZCBkYXRhLiAgVGhlIGJlYXV0eSBvZiBUU1NMT0FEQUJMRSBpcyB0aGF0IHRo
ZSBBU04uMSBmb3JtYXQgaW5jbHVkZXMgYSBwb2xpY3kgc3BlY2lmaWNhdGlvbjoNCg0KLyoNCiAq
IFRTU0xPQURBQkxFIDo6PSBTRVFVRU5DRSB7DQogKgl0eXBlCQlPQkpFQ1QgSURFTlRJRklFUg0K
ICoJZW1wdHlBdXRoCVswXSBFWFBMSUNJVCBCT09MRUFOIE9QVElPTkFMDQogKglwb2xpY3kJCVsx
XSBFWFBMSUNJVCBTRVFVRU5DRSBPRiBUUE1Qb2xpY3kgT1BUSU9OQUwNCiAqCXNlY3JldAkJWzJd
IEVYUExJQ0lUIE9DVEVUIFNUUklORyBPUFRJT05BTA0KICoJcGFyZW50CQlJTlRFR0VSDQogKglw
dWJrZXkJCU9DVEVUIFNUUklORw0KICoJcHJpdmtleQkJT0NURVQgU1RSSU5HDQogKiB9DQogKiBU
UE1Qb2xpY3kgOjo9IFNFUVVFTkNFIHsNCiAqCUNvbW1hbmRDb2RlCQlbMF0gRVhQTElDSVQgSU5U
RUdFUg0KICoJQ29tbWFuZFBvbGljeQkJWzFdIEVYUExJQ0lUIE9DVEVUIFNUUklORw0KICogfQ0K
ICovDQoNCkphbWVzDQoNCg=

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.

[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]

SGksIEphbWVzLCANCg0KVXNpbmcgcG9saWN5IGRpZ2VzdCB0byByZWxvYWQgdHJ1c3RlZCBrZXks
IGRvZXNuJ3Qgd29yaywgZWl0aGVyLiANClBsZWFzZSBjaGVjayB0aGUgc3RlcHMgYmVsb3cuIA0K
SSB0aGluayBwb2xpY3kgZGlnZXN0IHNob3VsZCBiZSBjYWxjdWxhdGVkIGJ5IFRQTSB3aGVuIHZl
cmlmeWluZyB0aGUgcG9saWN5IHRvIHJlbG9hZCBrZXkuIA0KDQovLy8vLy8vIGJ1aWxkIHBvbGlj
eQ0KIyB0cG0yX3Bjcmxpc3QgLUwgc2hhMjU2OjcgLW8gcGNyNy5zaGEyNTYNCnNoYTI1NjoNCiAg
NyA6IDB4MDYxQUFEMDcwNUE2MjM2MUFEMThFNThCNjVEM0Q3MzgzRjREMTBGN0Y1QTdFNzg5MjRC
RTA1N0FDNjc5NzQwOA0KIyB0cG0yX2NyZWF0ZXBvbGljeSAtLXBvbGljeS1wY3IgLS1wY3ItbGlz
dCBzaGEyNTY6NyAtLXBvbGljeSBwY3I3X2Jpbi5wb2xpY3kgPiBwY3I3LnBvbGljeQ0KIyBjYXQg
cGNyNy5wb2xpY3kNCjMyMWZiZDI4YjYwZmNjMjMwMTdkNTAxYjEzM2JkNWRiZjI4ODk4MTQ1ODhl
OGEyMzUxMGZlMTAxMDVjYjJjYzkNCg0KLy8vLy8vLyBuZXcgdHJ1c3RlZCBrZXkgYW5kIHVzZSBw
b2xpY3kgdG8gcHJvdGVjdA0KIyBrZXljdGwgYWRkIHRydXN0ZWQga21rICJuZXcgMzIga2V5aGFu
ZGxlPTB4ODEwMDAwMDEgaGFzaD1zaGEyNTYgcG9saWN5ZGlnZXN0PWBjYXQgcGNyNy5wb2xpY3lg
IiBAdQ0KNDY2MTA3NTc4DQojIGtleWN0bCBwaXBlIDQ2NjEwNzU3OCA+IGttay5ibG9iDQojIGtl
eWN0bCBwcmludCA0NjYxMDc1NzgNCjAwN2YwMDIwYTkyMmNhNzY0ZDNhZTlmZWFlNGMzYTFiMTQw
YzYxMGFkMWRmODM2ZGY2ZDcwNTQ5NTdmM2Y1ZGExNDA0MmYyOTAwMTBkM2NhODNhY2EwOGVkMTBh
NDMzYmE1ODVhNTE0NzEyNmQyMDdmMGM1MmU1M2ExZWRiZmMzMWI4OWIzMDk4ODA1Mzg3MDU1M2Vm
NjkyYzc3YzI4YjJjN2FkYjYzZTFmYzY5ODY5ZDdmMmU4YWIyYjlkODkwNmUwMmJkOTUzZGM1OGMz
YTViMWRlMDg1OGVjMzhhNmRjYjU1MTM4NGYzOGQ2ODM0ODQyZmQyMmI0YTljNjFjMDMyMDAwNGUw
MDA4MDAwYjAwMDAwMDAwMDAyMDMyMWZiZDI4YjYwZmNjMjMwMTdkNTAxYjEzM2JkNWRiZjI4ODk4
MTQ1ODhlOGEyMzUxMGZlMTAxMDVjYjJjYzkwMDEwMDAyMDAyODAzMjE4MTBhNjZkZjYzOTA1ZDQ4
NDZlMzllNmFkM2VjNjliNzdkZWFjMzM5ZjQyMDlmMjkxMDc4NDgzYzEwMDczMDAwMDAwMDAwMDIw
ZTNiMGM0NDI5OGZjMWMxNDlhZmJmNGM4OTk2ZmI5MjQyN2FlNDFlNDY0OWI5MzRjYTQ5NTk5MWI3
ODUyYjg1NTAxMDAwYjAwMjIwMDBiZGNkYjY5NGUxMDJlMTNhMGZiYTUxMTEwODFjYjZjZjYxNmMx
MThkNDA0OTM2Y2FjM2U4NGRiMjRjNzFlNDdkNTAwMjIwMDBiMDRiNWRiMWFhNTI2MzVkZmIyNDJl
NzZmNmJkZThlMjE3NmFlNDhmYzY4Mjk0NmM2Yzc2ZDk2ZjYwODA3OWQxZjAwMDAwMDIwMzZiNmZj
Y2E4MjA2YzdmNzIyZGU4NTgyMWQ3ZWNiNDc4NTk3NmZkZDY0MmJjNzUzODUwNWEyYTgxOGM4YTIz
ODgwMjE0MDAwMDAwMTAwMjAxNGI0MzlkYTliOTQ5MGQ5YmI2ZTVhOTNlN2U2ZWQ0MDhiMWQ1MWFl
NDVhYmNjZDVkNWRjYzYyNWQ5NjgyODJkDQojIGNhdCBrbWsuYmxvYg0KMDA3ZjAwMjBhOTIyY2E3
NjRkM2FlOWZlYWU0YzNhMWIxNDBjNjEwYWQxZGY4MzZkZjZkNzA1NDk1N2YzZjVkYTE0MDQyZjI5
MDAxMGQzY2E4M2FjYTA4ZWQxMGE0MzNiYTU4NWE1MTQ3MTI2ZDIwN2YwYzUyZTUzYTFlZGJmYzMx
Yjg5YjMwOTg4MDUzODcwNTUzZWY2OTJjNzdjMjhiMmM3YWRiNjNlMWZjNjk4NjlkN2YyZThhYjJi
OWQ4OTA2ZTAyYmQ5NTNkYzU4YzNhNWIxZGUwODU4ZWMzOGE2ZGNiNTUxMzg0ZjM4ZDY4MzQ4NDJm
ZDIyYjRhOWM2MWMwMzIwMDA0ZTAwMDgwMDBiMDAwMDAwMDAwMDIwMzIxZmJkMjhiNjBmY2MyMzAx
N2Q1MDFiMTMzYmQ1ZGJmMjg4OTgxNDU4OGU4YTIzNTEwZmUxMDEwNWNiMmNjOTAwMTAwMDIwMDI4
MDMyMTgxMGE2NmRmNjM5MDVkNDg0NmUzOWU2YWQzZWM2OWI3N2RlYWMzMzlmNDIwOWYyOTEwNzg0
ODNjMTAwNzMwMDAwMDAwMDAwMjBlM2IwYzQ0Mjk4ZmMxYzE0OWFmYmY0Yzg5OTZmYjkyNDI3YWU0
MWU0NjQ5YjkzNGNhNDk1OTkxYjc4NTJiODU1MDEwMDBiMDAyMjAwMGJkY2RiNjk0ZTEwMmUxM2Ew
ZmJhNTExMTA4MWNiNmNmNjE2YzExOGQ0MDQ5MzZjYWMzZTg0ZGIyNGM3MWU0N2Q1MDAyMjAwMGIw
NGI1ZGIxYWE1MjYzNWRmYjI0MmU3NmY2YmRlOGUyMTc2YWU0OGZjNjgyOTQ2YzZjNzZkOTZmNjA4
MDc5ZDFmMDAwMDAwMjAzNmI2ZmNjYTgyMDZjN2Y3MjJkZTg1ODIxZDdlY2I0Nzg1OTc2ZmRkNjQy
YmM3NTM4NTA1YTJhODE4YzhhMjM4ODAyMTQwMDAwMDAxMDAyMDE0YjQzOWRhOWI5NDkwZDliYjZl
NWE5M2U3ZTZlZDQwOGIxZDUxYWU0NWFiY2NkNWQ1ZGNjNjI1ZDk2ODI4MmQNCg0KLy8vLy8vLy8v
L2NsZWFyIHRydXN0ZWQga2V5IGFuZCByZWxvYWQNCiMga2V5Y3RsIGNsZWFyIEB1DQprZXljdGwg
bGlzdCBAdQ0Ka2V5cmluZyBpcyBlbXB0eQ0KIyBrZXljdGwgYWRkIHRydXN0ZWQga21rICJsb2Fk
IGBjYXQga21rLmJsb2JgIGtleWhhbmRsZT0weDgxMDAwMDAxIGhhc2g9c2hhMjU2IHBvbGljeWRp
Z2VzdD1gY2F0IHBjcjcucG9saWN5YCIgQHUNCmFkZF9rZXk6IE9wZXJhdGlvbiBub3QgcGVybWl0
dGVkDQoNCg0KVGhhbmtzLiANCg0KLSBTaGlybGV5IA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut
LS0tLQ0KRnJvbTogSmFtZXMgQm90dG9tbGV5IDxqZWpiQGxpbnV4LmlibS5jb20+IA0KU2VudDog
VHVlc2RheSwgRGVjZW1iZXIgMywgMjAxOSAxMToxMiBBTQ0KVG86IFpoYW8sIFNoaXJsZXkgPHNo
aXJsZXkuemhhb0BpbnRlbC5jb20+OyBNaW1pIFpvaGFyIDx6b2hhckBsaW51eC5pYm0uY29tPjsg
SmFya2tvIFNha2tpbmVuIDxqYXJra28uc2Fra2luZW5AbGludXguaW50ZWwuY29tPjsgSm9uYXRo
YW4gQ29yYmV0IDxjb3JiZXRAbHduLm5ldD4NCkNjOiBsaW51eC1pbnRlZ3JpdHlAdmdlci5rZXJu
ZWwub3JnOyBrZXlyaW5nc0B2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4LWRvY0B2Z2VyLmtlcm5lbC5v
cmc7IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7ICdNYXVybyBDYXJ2YWxobyBDaGVoYWIn
IDxtY2hlaGFiK3NhbXN1bmdAa2VybmVsLm9yZz47IFpodSwgQmluZyA8YmluZy56aHVAaW50ZWwu
Y29tPjsgQ2hlbiwgTHVoYWkgPGx1aGFpLmNoZW5AaW50ZWwuY29tPg0KU3ViamVjdDogUmU6IE9u
ZSBxdWVzdGlvbiBhYm91dCB0cnVzdGVkIGtleSBvZiBrZXlyaW5nIGluIExpbnV4IGtlcm5lbC4N
Cg0KT24gVHVlLCAyMDE5LTEyLTAzIGF0IDAyOjExICswMDAwLCBaaGFvLCBTaGlybGV5IHdyb3Rl
Og0KPiBUaGFua3Mgc28gbXVjaCBmb3IgeW91IGZlZWRiYWNrLCBKYW1lcy4gDQo+IEFuZCBnbGFk
IHRvIGhlYXIgdGhhdCB0aGUgQVBJIHdpbGwgYmUgbWFkZSBtb3JlIGZyaWVuZGx5LiANCj4gDQo+
IEJ1dCBJIGhhdmUgYSBsaXR0bGUgY29uZnVzZWQgYWJvdXQgdGhlIGNhbGwgc3RhY2suIA0KPiBG
cm9tIHRoZSBkb2N1bWVudCwgaHR0cHM6Ly9naXRodWIuY29tL3RvcnZhbGRzL2xpbnV4L2Jsb2Iv
bWFzdGVyL0RvY3UNCj4gbWVudGF0aW9uL3NlY3VyaXR5L2tleXMvdHJ1c3RlZC1lbmNyeXB0ZWQu
cnN0IGFuZCANCj4gaHR0cHM6Ly9naXRodWIuY29tL3pmc29ubGludXgvZHJhY3V0L3RyZWUvbWFz
dGVyL21vZHVsZXMuZC85N21hc3RlcmtlDQo+IHksIHRoZSB0cnVzdGVkIGtleSBpcyBhIHJhbmRv
bSBudW1iZXIgYW5kIGdlbmVyYXRlZCBieSBUUE0yLjAgYW5kIA0KPiBzZWFsZWQgd2l0aCBUUE0y
LjAgMjA0OCBSU0Ega2V5Lg0KDQpXZWxsLCB1bSwgdGhhdCBkb2N1bWVudCBzZWVtcyB0byBiZSBi
YXNlZCBvbiBUUE0gMS4yIC4uLiBhIGxvdCBvZiB3aGF0IGl0IHNheXMgaXNuJ3QgcXVpdGUgdHJ1
ZSBmb3IgVFBNIDIuMC4gIEZvciBpbnN0YW5jZSBhbGwgVFBNIDIuMCBwcmltYXJ5IGtleXMgY29t
ZSB3aXRoIGEgc3ltbWV0cmljIGNvbXBvbmVudCwgc28gdGhlIHNlYWxlZCBkYXRhIGluIFRQTSAy
LjAgaXMgYWN0dWFsbHkgc3ltbWV0cmljYWxseSBlbmNyeXB0ZWQgdG8gYSBwcmltYXJ5IGtleS4N
Cg0KPiBUaGUgMjA0OCBSU0Ega2V5IGlzIGdlbmVyYXRlZCBieSB0cG0yX2NyZWF0ZXByaW1hcnks
IGFuZCBpdCBjYW4gYmUgZ290IA0KPiBieSB0aGUgVFBNMi4wIGhhbmRsZSwganVzdCB0aGUgImtl
eWhhbmRsZSIgdXNlZCBpbiB0aGUgZm9sbG93aW5nIA0KPiBrZXljdGwgY29tbWFuZC4NCj4gJCBr
ZXljdGwgYWRkIHRydXN0ZWQga21rICJuZXcgMzIga2V5aGFuZGxlPTB4ODEwMDAwMDEgaGFzaD1z
aGEyNTYgDQo+IHBvbGljeWRpZ2VzdD1gY2F0IHBjcjcucG9saWN5YCIgQHUNCg0KVGhlIHByb2Js
ZW0gVFBNIDIuMCBoYXMgaXMgdGhhdCBtb3N0IG9mIHRoZW0gY2FuJ3QgZ2VuZXJhdGUgcHJpbWUg
bnVtYmVycyB2ZXJ5IGZhc3QsIHNvIGV2ZW4gdGhyb3VnaCB0aGUga2VybmVsIGNvdWxkIGdlbmVy
YXRlIHRoZSBSU0EgcHJpbWFyeSwgaXQgd291bGQgdXN1YWxseSB0YWtlIGZhciB0b28gbG9uZywg
c28gaWYgeW91IHdhbnQgdG8gdXNlIGEgUlNBIHByaW1hcnkgeW91IGhhdmUgdG8gcHJlLWdlbmVy
YXRlIG9uZSBhbmQgcGxhY2UgaXQgaW4gTlYgc3RvcmFnZTsgdGhlIFRDRyByZWNvbW1lbmRzIGRv
aW5nIHRoaXMgYXQgaGFuZGxlIDgxMDAwMDAxLCB3aGljaCBpcyB3aGF0IHlvdSBoYXZlIGFib3Zl
LiAgSG93ZXZlciwgdGhlIG1vcmUgbW9kZXJuIHdheSBpcyB0byBkZXJpdmUgYW4gZWxsaXB0aWMg
Y3VydmUga2V5IHByaW1hcnkga2V5IGV2ZXJ5IHRpbWUgLi4uIEVDIGtleXMgY2FuIGJlIGdlbmVy
YXRlZCBieSBtb3N0IFRQTXMgaW4gMTBzIG9mIG1pbGxpc2Vjb25kcywgc28gdGhlIHByaW1hcnkg
ZG9lc24ndCBuZWVkIHRvIGJlIHByZXNlbnQgaW4gTlZSQU0uDQoNClRIZSBrZXJuZWwgc2hvdWxk
IGJlIHVzaW5nIHRoZSBFQyBwcmltYXJ5IG1ldGhvZCBmb3IgdGhlIHBhcmVudC4gIFRoZSBvbmx5
IGV4Y2VwdGlvbiBpcyB3aGVuIHRoZSBrZXkgaGFzIGFuIGludGVybWVkaWF0ZSBwYXJlbnQsIGFu
ZCB0aGVuIGl0IGNhbiBiZSBzaW1wbHkgbG9hZGVkIGZyb20gYSBmaWxlLg0KDQo+IElmIHJlYm9v
dCwgdG8gcmUtbG9hZCB0aGUgdHJ1c3RlZCBrZXkgYmFjayB0byBrZXlyaW5nLCBqdXN0IGNhbGwg
DQo+IHRwbTJfdW5zZWFsIGlzIGVub3VnaCwgZG9uJ3QgbmVlZCB0byBjYWxsIHRwbTJfbG9hZCB0
byBsb2FkIHRoZQ0KPiBUUE0yLjAgMjA0OCBSU0Ega2V5Lg0KPiBJZiB0aGUgdHJ1c3RlZCBrZXkg
aXMgYWxzbyBwcm90ZWN0ZWQgYnkgcG9saWN5LCB0aGVuIHRoZSBwb2xpY3kgd2lsbCANCj4gYmUg
Y2hlY2tlZCBkdXJpbmcgdHBtMl91bnNlYWwuDQo+IA0KPiBBZnRlciBjaGVjayB0aGUgc291cmNl
IGNvZGUsIHRoZSBjYWxsIHN0YWNrIGlzIG1vc3RseSBsaWtlOiANCj4gU1lTQ0FMTF9ERUZJTkU1
KGFkZF9rZXksLi4uKSAtLT4ga2V5X2NyZWF0ZV9vcl91cGRhdGUoKSAtLT4NCj4gX19rZXlfaW5z
dGFudGlhdGVfYW5kX2xpbmsoKSAtLT4gIHRydXN0ZWRfaW5zdGFudGlhdGUoKSAtLT4NCj4gdHBt
Ml91bnNlYWxfdHJ1c3RlZCgpIC0tPiB0cG0yX3Vuc2VhbF9jbWQoKS4NCg0KV2VsbCwgdGhlIEFQ
SSBpcyBjb25mdXNpbmcsIGJ1dCB0aGUgY29kZSBzZWVtcyB0byBpbXBseSB0aGUgcGFyZW50IHNo
b3VsZCBiZSBwcmVzZW50IHNvbWVob3cuICBBIGtleSBpbiBOVlJBTSwgbGlrZSA4MTAwMDAwMSBp
cyBhbHdheXMgcHJlc2VudCBzbyBpdCBkb2Vzbid0IG5lZWQgdG8gYmUgbG9hZGVkIGl0IGNhbiBq
dXN0IGJlIHVzZWQgYXMgaXMuDQoNCj4gQW5vdGhlciBwcm9ibGVtIGhlcmUgaXMsIHRvIGJ1aWxk
IHRoZSBwb2xpY3kgdG8gdW5zZWFsIHRoZSBrZXksIGl0IA0KPiBuZWVkIHRvIHN0YXJ0IGFuIHBv
bGljeSBzZXNzaW9uLCBhbmQgdHJhbnNmZXIgdGhlIHNlc3Npb24gaGFuZGxlIHRvDQo+IFRQTTIu
MCB1bnNlYWwgY29tbWFuZC4gDQo+IEluIG15IGtleWN0bCBjb21tYW5kLCBJIHVzZSB0cG0yLjAg
Y29tbWFuZCB0byBzdGFydCB0aGUgc2Vzc2lvbiBhbmQgDQo+IGdldCB0aGUgaGFuZGxlLCBwdXQg
aXQgaW50byB0aGUga2V5Y3RsIGNvbW1hbmQgbGlrZToNCj4ga2V5Y3RsIGFkZCB0cnVzdGVkIGtt
ayAibG9hZCBgY2F0IGttay5ibG9iYCBrZXloYW5kbGU9MHg4MTAwMDAwMSANCj4gcG9saWN5aGFu
ZGxlPTB4MzAwMDAwMCIgQHUNCg0KQXMgSSBzYWlkLCB1c2luZyBwb2xpY3kgaGFuZGxlcyBzaW1w
bHkgd29uJ3Qgc2NhbGUsIHNvIHdlIG5lZWQgdG8gdXNlIHRoZSBhY3R1YWwgcG9saWN5IGluc3Rl
YWQgLi4uIHRodXMgdGhlIHBvbGljeSBzaG91bGQgYmUgcGFzc2VkIGludG8gdGhlIGtlcm5lbCAg
YXMgcGFydCBvZiB0aGUgdHJ1c3RlZCBrZXkgYW5kIHRoZSBrZXJuZWwgaXRzZWxmIHdvdWxkIGdl
bmVyYXRlIGEgcG9saWN5IHNlc3Npb24gZnJvbSB0aGUgcG9saWN5IHN0YXRlbWVudHMgLi4uIHRo
aXMgYXBwcm9hY2ggaXMgYXJlYWR5IHByb3ZlbiB0byBiZSB1c2VmdWwgYW5kIGZ1bmN0aW9uYWwg
aW4gdGhlIHRwbTIgb3BlbnNzbCBlbmdpbmUgY29kZS4NCg0KSmFtZXMNCg0K

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.

[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]

T2gsIGdldCB5b3UsIEphbWVzLiANClVuZGVyc3RhbmQsIHRoYW5rcyBmb3IgeW91ciBmZWVkYmFj
ay4gDQpMb29raW5nIGZvcndhcmQgZm9yIHlvdXIgcHJvcG9zZWQgQVBJLiANCg0KLSBTaGlybGV5
IA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSmFtZXMgQm90dG9tbGV5IDxq
ZWpiQGxpbnV4LmlibS5jb20+IA0KU2VudDogV2VkbmVzZGF5LCBEZWNlbWJlciA0LCAyMDE5IDEx
OjMzIEFNDQpUbzogWmhhbywgU2hpcmxleSA8c2hpcmxleS56aGFvQGludGVsLmNvbT47IE1pbWkg
Wm9oYXIgPHpvaGFyQGxpbnV4LmlibS5jb20+OyBKYXJra28gU2Fra2luZW4gPGphcmtrby5zYWtr
aW5lbkBsaW51eC5pbnRlbC5jb20+OyBKb25hdGhhbiBDb3JiZXQgPGNvcmJldEBsd24ubmV0Pg0K
Q2M6IGxpbnV4LWludGVncml0eUB2Z2VyLmtlcm5lbC5vcmc7IGtleXJpbmdzQHZnZXIua2VybmVs
Lm9yZzsgbGludXgtZG9jQHZnZXIua2VybmVsLm9yZzsgbGludXgta2VybmVsQHZnZXIua2VybmVs
Lm9yZzsgJ01hdXJvIENhcnZhbGhvIENoZWhhYicgPG1jaGVoYWIrc2Ftc3VuZ0BrZXJuZWwub3Jn
PjsgWmh1LCBCaW5nIDxiaW5nLnpodUBpbnRlbC5jb20+OyBDaGVuLCBMdWhhaSA8bHVoYWkuY2hl
bkBpbnRlbC5jb20+DQpTdWJqZWN0OiBSZTogT25lIHF1ZXN0aW9uIGFib3V0IHRydXN0ZWQga2V5
IG9mIGtleXJpbmcgaW4gTGludXgga2VybmVsLg0KDQpPbiBXZWQsIDIwMTktMTItMDQgYXQgMDM6
MDEgKzAwMDAsIFpoYW8sIFNoaXJsZXkgd3JvdGU6DQo+IEhpLCBKYW1lcywNCj4gDQo+IFVzaW5n
IHBvbGljeSBkaWdlc3QgdG8gcmVsb2FkIHRydXN0ZWQga2V5LCBkb2Vzbid0IHdvcmssIGVpdGhl
ci4gDQo+IFBsZWFzZSBjaGVjayB0aGUgc3RlcHMgYmVsb3cuIA0KPiBJIHRoaW5rIHBvbGljeSBk
aWdlc3Qgc2hvdWxkIGJlIGNhbGN1bGF0ZWQgYnkgVFBNIHdoZW4gdmVyaWZ5aW5nIHRoZSANCj4g
cG9saWN5IHRvIHJlbG9hZCBrZXkuDQoNCllvdSBtaXN1bmRlcnN0YW5kIG15IG1lYW5pbmc6IHRo
ZSBBUEkgd2UgaGF2ZSBub3cgZG9lc24ndCB3b3JrOyB0aGUga2V5IGJsb2IgdGhlIGtlcm5lbCBy
ZXR1cm5zIGN1cnJlbnRseSBhZnRlciBrZXkgY3JlYXRlIHdvbid0IHJlbG9hZCBiZWNhdXNlIGl0
IGNvbnRhaW5zIGV4dHJhbmVvdXMgZGF0YS4gIEkgd2FzIHByb3Bvc2luZyBhIHdvcmtpbmcgQVBJ
IEkgdGhvdWdodCBtaWdodCByZXBsYWNlIGl0LCBidXQgb2J2aW91c2x5IGl0IGhhcyB0byBiZSBj
b2RlZCB1cCBhbmQgYWNjZXB0ZWQgaW50byBhIGtlcm5lbCB2ZXJzaW9uIGJlZm9yZSB5b3UgY2Fu
IHVzZSBpdC4NCg0KSWYgeW91IHdhbnQgdG8gZ2V0IHRydXN0ZWQga2V5cyB3b3JraW5nIHRvZGF5
LCBJIHRoaW5rIHRoZSBUUE0gMS4yIEFQSSBzdGlsbCB3b3JrcyBpZiB5b3UgaGF2ZSBhIFRQTSAx
LjIgc3lzdGVtLg0KDQpKYW1lcw0KDQo

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

[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.

[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.

[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 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 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: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

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