* Re: One question about trusted key of keyring in Linux kernel. [not found] <A888B25CD99C1141B7C254171A953E8E49094313@shsmsx102.ccr.corp.intel.com> @ 2019-11-13 15:46 ` Mimi Zohar 2019-11-14 17:01 ` Jarkko Sakkinen 1 sibling, 0 replies; 66+ messages in thread From: Mimi Zohar @ 2019-11-13 15:46 UTC (permalink / raw) To: Zhao, Shirley, James Bottomley, Jarkko Sakkinen, Jonathan Corbet Cc: linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab' 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: One question about trusted key of keyring in Linux kernel. @ 2019-11-13 15:46 ` Mimi Zohar 0 siblings, 0 replies; 66+ messages in thread From: Mimi Zohar @ 2019-11-13 15:46 UTC (permalink / raw) To: Zhao, Shirley, James Bottomley, Jarkko Sakkinen, Jonathan Corbet Cc: linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab' 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* RE: One question about trusted key of keyring in Linux kernel. 2019-11-13 15:46 ` Mimi Zohar @ 2019-11-26 7:32 ` Zhao, Shirley -1 siblings, 0 replies; 66+ messages in thread From: Zhao, Shirley @ 2019-11-26 7:32 UTC (permalink / raw) To: Mimi Zohar, James Bottomley, Jarkko Sakkinen, Jonathan Corbet Cc: linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* RE: One question about trusted key of keyring in Linux kernel. @ 2019-11-26 7:32 ` Zhao, Shirley 0 siblings, 0 replies; 66+ messages in thread From: Zhao, Shirley @ 2019-11-26 7:32 UTC (permalink / raw) To: Mimi Zohar, James Bottomley, Jarkko Sakkinen, Jonathan Corbet Cc: linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: One question about trusted key of keyring in Linux kernel. 2019-11-26 7:32 ` Zhao, Shirley @ 2019-11-26 19:27 ` Mimi Zohar -1 siblings, 0 replies; 66+ messages in thread From: Mimi Zohar @ 2019-11-26 19:27 UTC (permalink / raw) To: Zhao, Shirley, James Bottomley, Jarkko Sakkinen, Jonathan Corbet Cc: linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: One question about trusted key of keyring in Linux kernel. @ 2019-11-26 19:27 ` Mimi Zohar 0 siblings, 0 replies; 66+ messages in thread From: Mimi Zohar @ 2019-11-26 19:27 UTC (permalink / raw) To: Zhao, Shirley, James Bottomley, Jarkko Sakkinen, Jonathan Corbet Cc: linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* RE: One question about trusted key of keyring in Linux kernel. 2019-11-26 19:27 ` Mimi Zohar @ 2019-11-27 2:46 ` Zhao, Shirley -1 siblings, 0 replies; 66+ messages in thread From: Zhao, Shirley @ 2019-11-27 2:46 UTC (permalink / raw) To: Mimi Zohar, James Bottomley, Jarkko Sakkinen, Jonathan Corbet Cc: linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* RE: One question about trusted key of keyring in Linux kernel. @ 2019-11-27 2:46 ` Zhao, Shirley 0 siblings, 0 replies; 66+ messages in thread From: Zhao, Shirley @ 2019-11-27 2:46 UTC (permalink / raw) To: Mimi Zohar, James Bottomley, Jarkko Sakkinen, Jonathan Corbet Cc: linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: One question about trusted key of keyring in Linux kernel. 2019-11-27 2:46 ` Zhao, Shirley @ 2019-11-27 15:39 ` Mimi Zohar -1 siblings, 0 replies; 66+ messages in thread From: Mimi Zohar @ 2019-11-27 15:39 UTC (permalink / raw) To: Zhao, Shirley, James Bottomley, Jarkko Sakkinen, Jonathan Corbet Cc: linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: One question about trusted key of keyring in Linux kernel. @ 2019-11-27 15:39 ` Mimi Zohar 0 siblings, 0 replies; 66+ messages in thread From: Mimi Zohar @ 2019-11-27 15:39 UTC (permalink / raw) To: Zhao, Shirley, James Bottomley, Jarkko Sakkinen, Jonathan Corbet Cc: linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* RE: One question about trusted key of keyring in Linux kernel. 2019-11-27 15:39 ` Mimi Zohar @ 2019-11-29 1:54 ` Zhao, Shirley -1 siblings, 0 replies; 66+ messages in thread From: Zhao, Shirley @ 2019-11-29 1:54 UTC (permalink / raw) To: Mimi Zohar, James Bottomley, Jarkko Sakkinen, Jonathan Corbet Cc: linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* RE: One question about trusted key of keyring in Linux kernel. @ 2019-11-29 1:54 ` Zhao, Shirley 0 siblings, 0 replies; 66+ messages in thread From: Zhao, Shirley @ 2019-11-29 1:54 UTC (permalink / raw) To: Mimi Zohar, James Bottomley, Jarkko Sakkinen, Jonathan Corbet Cc: linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: One question about trusted key of keyring in Linux kernel. 2019-11-26 19:27 ` Mimi Zohar @ 2019-11-29 23:01 ` Jarkko Sakkinen -1 siblings, 0 replies; 66+ messages in thread From: Jarkko Sakkinen @ 2019-11-29 23:01 UTC (permalink / raw) To: Mimi Zohar Cc: Zhao, Shirley, James Bottomley, Jonathan Corbet, linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: One question about trusted key of keyring in Linux kernel. @ 2019-11-29 23:01 ` Jarkko Sakkinen 0 siblings, 0 replies; 66+ messages in thread From: Jarkko Sakkinen @ 2019-11-29 23:01 UTC (permalink / raw) To: Mimi Zohar Cc: Zhao, Shirley, James Bottomley, Jonathan Corbet, linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* RE: One question about trusted key of keyring in Linux kernel. 2019-11-29 23:01 ` Jarkko Sakkinen @ 2019-12-02 1:45 ` Zhao, Shirley -1 siblings, 0 replies; 66+ messages in thread From: Zhao, Shirley @ 2019-12-02 1:45 UTC (permalink / raw) To: Jarkko Sakkinen, Mimi Zohar Cc: James Bottomley, Jonathan Corbet, linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* RE: One question about trusted key of keyring in Linux kernel. @ 2019-12-02 1:45 ` Zhao, Shirley 0 siblings, 0 replies; 66+ messages in thread From: Zhao, Shirley @ 2019-12-02 1:45 UTC (permalink / raw) To: Jarkko Sakkinen, Mimi Zohar Cc: James Bottomley, Jonathan Corbet, linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: One question about trusted key of keyring in Linux kernel. 2019-12-02 1:45 ` Zhao, Shirley @ 2019-12-06 21:20 ` Jarkko Sakkinen -1 siblings, 0 replies; 66+ messages in thread From: Jarkko Sakkinen @ 2019-12-06 21:20 UTC (permalink / raw) To: Zhao, Shirley Cc: Mimi Zohar, James Bottomley, Jonathan Corbet, linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: One question about trusted key of keyring in Linux kernel. @ 2019-12-06 21:20 ` Jarkko Sakkinen 0 siblings, 0 replies; 66+ messages in thread From: Jarkko Sakkinen @ 2019-12-06 21:20 UTC (permalink / raw) To: Zhao, Shirley Cc: Mimi Zohar, James Bottomley, Jonathan Corbet, linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: One question about trusted key of keyring in Linux kernel. 2019-11-26 7:32 ` Zhao, Shirley @ 2019-11-27 18:06 ` James Bottomley -1 siblings, 0 replies; 66+ messages in thread From: James Bottomley @ 2019-11-27 18:06 UTC (permalink / raw) To: Zhao, Shirley, Mimi Zohar, Jarkko Sakkinen, Jonathan Corbet Cc: linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: One question about trusted key of keyring in Linux kernel. @ 2019-11-27 18:06 ` James Bottomley 0 siblings, 0 replies; 66+ messages in thread From: James Bottomley @ 2019-11-27 18:06 UTC (permalink / raw) To: Zhao, Shirley, Mimi Zohar, Jarkko Sakkinen, Jonathan Corbet Cc: linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* RE: One question about trusted key of keyring in Linux kernel. 2019-11-27 18:06 ` James Bottomley @ 2019-11-29 1:40 ` Zhao, Shirley -1 siblings, 0 replies; 66+ messages in thread From: Zhao, Shirley @ 2019-11-29 1:40 UTC (permalink / raw) To: James Bottomley, Mimi Zohar, Jarkko Sakkinen, Jonathan Corbet Cc: linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* RE: One question about trusted key of keyring in Linux kernel. @ 2019-11-29 1:40 ` Zhao, Shirley 0 siblings, 0 replies; 66+ messages in thread From: Zhao, Shirley @ 2019-11-29 1:40 UTC (permalink / raw) To: James Bottomley, Mimi Zohar, Jarkko Sakkinen, Jonathan Corbet Cc: linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: One question about trusted key of keyring in Linux kernel. 2019-11-29 1:40 ` Zhao, Shirley @ 2019-11-29 20:05 ` James Bottomley -1 siblings, 0 replies; 66+ messages in thread From: James Bottomley @ 2019-11-29 20:05 UTC (permalink / raw) To: Zhao, Shirley, Mimi Zohar, Jarkko Sakkinen, Jonathan Corbet Cc: linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: One question about trusted key of keyring in Linux kernel. @ 2019-11-29 20:05 ` James Bottomley 0 siblings, 0 replies; 66+ messages in thread From: James Bottomley @ 2019-11-29 20:05 UTC (permalink / raw) To: Zhao, Shirley, Mimi Zohar, Jarkko Sakkinen, Jonathan Corbet Cc: linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* RE: One question about trusted key of keyring in Linux kernel. 2019-11-29 20:05 ` James Bottomley @ 2019-12-02 1:44 ` Zhao, Shirley -1 siblings, 0 replies; 66+ messages in thread From: Zhao, Shirley @ 2019-12-02 1:44 UTC (permalink / raw) To: James Bottomley, Mimi Zohar, Jarkko Sakkinen, Jonathan Corbet Cc: linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* RE: One question about trusted key of keyring in Linux kernel. @ 2019-12-02 1:44 ` Zhao, Shirley 0 siblings, 0 replies; 66+ messages in thread From: Zhao, Shirley @ 2019-12-02 1:44 UTC (permalink / raw) To: James Bottomley, Mimi Zohar, Jarkko Sakkinen, Jonathan Corbet Cc: linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: One question about trusted key of keyring in Linux kernel. 2019-12-02 1:44 ` Zhao, Shirley @ 2019-12-02 4:17 ` James Bottomley -1 siblings, 0 replies; 66+ messages in thread From: James Bottomley @ 2019-12-02 4:17 UTC (permalink / raw) To: Zhao, Shirley, Mimi Zohar, Jarkko Sakkinen, Jonathan Corbet Cc: linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: One question about trusted key of keyring in Linux kernel. @ 2019-12-02 4:17 ` James Bottomley 0 siblings, 0 replies; 66+ messages in thread From: James Bottomley @ 2019-12-02 4:17 UTC (permalink / raw) To: Zhao, Shirley, Mimi Zohar, Jarkko Sakkinen, Jonathan Corbet Cc: linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* RE: One question about trusted key of keyring in Linux kernel. 2019-12-02 4:17 ` James Bottomley @ 2019-12-02 5:55 ` Zhao, Shirley -1 siblings, 0 replies; 66+ messages in thread From: Zhao, Shirley @ 2019-12-02 5:55 UTC (permalink / raw) To: James Bottomley, Mimi Zohar, Jarkko Sakkinen, Jonathan Corbet Cc: linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* RE: One question about trusted key of keyring in Linux kernel. @ 2019-12-02 5:55 ` Zhao, Shirley 0 siblings, 0 replies; 66+ messages in thread From: Zhao, Shirley @ 2019-12-02 5:55 UTC (permalink / raw) To: James Bottomley, Mimi Zohar, Jarkko Sakkinen, Jonathan Corbet Cc: linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: One question about trusted key of keyring in Linux kernel. 2019-12-02 5:55 ` Zhao, Shirley @ 2019-12-02 6:17 ` James Bottomley -1 siblings, 0 replies; 66+ messages in thread From: James Bottomley @ 2019-12-02 6:17 UTC (permalink / raw) To: Zhao, Shirley, Mimi Zohar, Jarkko Sakkinen, Jonathan Corbet Cc: linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 > ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: One question about trusted key of keyring in Linux kernel. @ 2019-12-02 6:17 ` James Bottomley 0 siblings, 0 replies; 66+ messages in thread From: James Bottomley @ 2019-12-02 6:17 UTC (permalink / raw) To: Zhao, Shirley, Mimi Zohar, Jarkko Sakkinen, Jonathan Corbet Cc: linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 > ^ permalink raw reply [flat|nested] 66+ messages in thread
* RE: One question about trusted key of keyring in Linux kernel. 2019-12-02 6:17 ` James Bottomley @ 2019-12-02 6:23 ` Zhao, Shirley -1 siblings, 0 replies; 66+ messages in thread From: Zhao, Shirley @ 2019-12-02 6:23 UTC (permalink / raw) To: James Bottomley, Mimi Zohar, Jarkko Sakkinen, Jonathan Corbet Cc: linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* RE: One question about trusted key of keyring in Linux kernel. @ 2019-12-02 6:23 ` Zhao, Shirley 0 siblings, 0 replies; 66+ messages in thread From: Zhao, Shirley @ 2019-12-02 6:23 UTC (permalink / raw) To: James Bottomley, Mimi Zohar, Jarkko Sakkinen, Jonathan Corbet Cc: linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 > ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: One question about trusted key of keyring in Linux kernel. 2019-12-02 6:23 ` Zhao, Shirley @ 2019-12-02 6:44 ` James Bottomley -1 siblings, 0 replies; 66+ messages in thread From: James Bottomley @ 2019-12-02 6:44 UTC (permalink / raw) To: Zhao, Shirley, Mimi Zohar, Jarkko Sakkinen, Jonathan Corbet Cc: linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: One question about trusted key of keyring in Linux kernel. @ 2019-12-02 6:44 ` James Bottomley 0 siblings, 0 replies; 66+ messages in thread From: James Bottomley @ 2019-12-02 6:44 UTC (permalink / raw) To: Zhao, Shirley, Mimi Zohar, Jarkko Sakkinen, Jonathan Corbet Cc: linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* RE: One question about trusted key of keyring in Linux kernel. 2019-12-02 6:44 ` James Bottomley @ 2019-12-02 6:50 ` Zhao, Shirley -1 siblings, 0 replies; 66+ messages in thread From: Zhao, Shirley @ 2019-12-02 6:50 UTC (permalink / raw) To: James Bottomley, Mimi Zohar, Jarkko Sakkinen, Jonathan Corbet Cc: linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* RE: One question about trusted key of keyring in Linux kernel. @ 2019-12-02 6:50 ` Zhao, Shirley 0 siblings, 0 replies; 66+ messages in thread From: Zhao, Shirley @ 2019-12-02 6:50 UTC (permalink / raw) To: James Bottomley, Mimi Zohar, Jarkko Sakkinen, Jonathan Corbet Cc: linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: One question about trusted key of keyring in Linux kernel. 2019-12-02 6:50 ` Zhao, Shirley @ 2019-12-02 18:55 ` James Bottomley -1 siblings, 0 replies; 66+ messages in thread From: James Bottomley @ 2019-12-02 18:55 UTC (permalink / raw) To: Zhao, Shirley, Mimi Zohar, Jarkko Sakkinen, Jonathan Corbet Cc: linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: One question about trusted key of keyring in Linux kernel. @ 2019-12-02 18:55 ` James Bottomley 0 siblings, 0 replies; 66+ messages in thread From: James Bottomley @ 2019-12-02 18:55 UTC (permalink / raw) To: Zhao, Shirley, Mimi Zohar, Jarkko Sakkinen, Jonathan Corbet Cc: linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* RE: One question about trusted key of keyring in Linux kernel. 2019-12-02 18:55 ` James Bottomley @ 2019-12-03 2:11 ` Zhao, Shirley -1 siblings, 0 replies; 66+ messages in thread From: Zhao, Shirley @ 2019-12-03 2:11 UTC (permalink / raw) To: James Bottomley, Mimi Zohar, Jarkko Sakkinen, Jonathan Corbet Cc: linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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= ^ permalink raw reply [flat|nested] 66+ messages in thread
* RE: One question about trusted key of keyring in Linux kernel. @ 2019-12-03 2:11 ` Zhao, Shirley 0 siblings, 0 replies; 66+ messages in thread From: Zhao, Shirley @ 2019-12-03 2:11 UTC (permalink / raw) To: James Bottomley, Mimi Zohar, Jarkko Sakkinen, Jonathan Corbet Cc: linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: One question about trusted key of keyring in Linux kernel. 2019-12-03 2:11 ` Zhao, Shirley @ 2019-12-03 3:12 ` James Bottomley -1 siblings, 0 replies; 66+ messages in thread From: James Bottomley @ 2019-12-03 3:12 UTC (permalink / raw) To: Zhao, Shirley, Mimi Zohar, Jarkko Sakkinen, Jonathan Corbet Cc: linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: One question about trusted key of keyring in Linux kernel. @ 2019-12-03 3:12 ` James Bottomley 0 siblings, 0 replies; 66+ messages in thread From: James Bottomley @ 2019-12-03 3:12 UTC (permalink / raw) To: Zhao, Shirley, Mimi Zohar, Jarkko Sakkinen, Jonathan Corbet Cc: linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* RE: One question about trusted key of keyring in Linux kernel. 2019-12-03 3:12 ` James Bottomley @ 2019-12-04 3:01 ` Zhao, Shirley -1 siblings, 0 replies; 66+ messages in thread From: Zhao, Shirley @ 2019-12-04 3:01 UTC (permalink / raw) To: James Bottomley, Mimi Zohar, Jarkko Sakkinen, Jonathan Corbet Cc: linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* RE: One question about trusted key of keyring in Linux kernel. @ 2019-12-04 3:01 ` Zhao, Shirley 0 siblings, 0 replies; 66+ messages in thread From: Zhao, Shirley @ 2019-12-04 3:01 UTC (permalink / raw) To: James Bottomley, Mimi Zohar, Jarkko Sakkinen, Jonathan Corbet Cc: linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: One question about trusted key of keyring in Linux kernel. 2019-12-04 3:01 ` Zhao, Shirley @ 2019-12-04 3:33 ` James Bottomley -1 siblings, 0 replies; 66+ messages in thread From: James Bottomley @ 2019-12-04 3:33 UTC (permalink / raw) To: Zhao, Shirley, Mimi Zohar, Jarkko Sakkinen, Jonathan Corbet Cc: linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: One question about trusted key of keyring in Linux kernel. @ 2019-12-04 3:33 ` James Bottomley 0 siblings, 0 replies; 66+ messages in thread From: James Bottomley @ 2019-12-04 3:33 UTC (permalink / raw) To: Zhao, Shirley, Mimi Zohar, Jarkko Sakkinen, Jonathan Corbet Cc: linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* RE: One question about trusted key of keyring in Linux kernel. 2019-12-04 3:33 ` James Bottomley @ 2019-12-04 6:39 ` Zhao, Shirley -1 siblings, 0 replies; 66+ messages in thread From: Zhao, Shirley @ 2019-12-04 6:39 UTC (permalink / raw) To: James Bottomley, Mimi Zohar, Jarkko Sakkinen, Jonathan Corbet Cc: linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* RE: One question about trusted key of keyring in Linux kernel. @ 2019-12-04 6:39 ` Zhao, Shirley 0 siblings, 0 replies; 66+ messages in thread From: Zhao, Shirley @ 2019-12-04 6:39 UTC (permalink / raw) To: James Bottomley, Mimi Zohar, Jarkko Sakkinen, Jonathan Corbet Cc: linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: One question about trusted key of keyring in Linux kernel. 2019-12-02 18:55 ` James Bottomley @ 2019-12-09 19:47 ` Jarkko Sakkinen -1 siblings, 0 replies; 66+ messages in thread From: Jarkko Sakkinen @ 2019-12-09 19:47 UTC (permalink / raw) To: James Bottomley Cc: Zhao, Shirley, Mimi Zohar, Jonathan Corbet, linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: One question about trusted key of keyring in Linux kernel. @ 2019-12-09 19:47 ` Jarkko Sakkinen 0 siblings, 0 replies; 66+ messages in thread From: Jarkko Sakkinen @ 2019-12-09 19:47 UTC (permalink / raw) To: James Bottomley Cc: Zhao, Shirley, Mimi Zohar, Jonathan Corbet, linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: One question about trusted key of keyring in Linux kernel. 2019-12-09 19:47 ` Jarkko Sakkinen @ 2019-12-09 20:31 ` James Bottomley -1 siblings, 0 replies; 66+ messages in thread From: James Bottomley @ 2019-12-09 20:31 UTC (permalink / raw) To: Jarkko Sakkinen Cc: Zhao, Shirley, Mimi Zohar, Jonathan Corbet, linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: One question about trusted key of keyring in Linux kernel. @ 2019-12-09 20:31 ` James Bottomley 0 siblings, 0 replies; 66+ messages in thread From: James Bottomley @ 2019-12-09 20:31 UTC (permalink / raw) To: Jarkko Sakkinen Cc: Zhao, Shirley, Mimi Zohar, Jonathan Corbet, linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: One question about trusted key of keyring in Linux kernel. 2019-12-09 20:31 ` James Bottomley @ 2019-12-11 17:23 ` Jarkko Sakkinen -1 siblings, 0 replies; 66+ messages in thread From: Jarkko Sakkinen @ 2019-12-11 17:23 UTC (permalink / raw) To: James Bottomley Cc: Zhao, Shirley, Mimi Zohar, Jonathan Corbet, linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: One question about trusted key of keyring in Linux kernel. @ 2019-12-11 17:23 ` Jarkko Sakkinen 0 siblings, 0 replies; 66+ messages in thread From: Jarkko Sakkinen @ 2019-12-11 17:23 UTC (permalink / raw) To: James Bottomley Cc: Zhao, Shirley, Mimi Zohar, Jonathan Corbet, linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: One question about trusted key of keyring in Linux kernel. 2019-12-11 17:23 ` Jarkko Sakkinen @ 2019-12-11 17:33 ` Jarkko Sakkinen -1 siblings, 0 replies; 66+ messages in thread From: Jarkko Sakkinen @ 2019-12-11 17:33 UTC (permalink / raw) To: James Bottomley Cc: Zhao, Shirley, Mimi Zohar, Jonathan Corbet, linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: One question about trusted key of keyring in Linux kernel. @ 2019-12-11 17:33 ` Jarkko Sakkinen 0 siblings, 0 replies; 66+ messages in thread From: Jarkko Sakkinen @ 2019-12-11 17:33 UTC (permalink / raw) To: James Bottomley Cc: Zhao, Shirley, Mimi Zohar, Jonathan Corbet, linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: One question about trusted key of keyring in Linux kernel. 2019-12-11 17:33 ` Jarkko Sakkinen @ 2019-12-11 17:53 ` Jarkko Sakkinen -1 siblings, 0 replies; 66+ messages in thread From: Jarkko Sakkinen @ 2019-12-11 17:53 UTC (permalink / raw) To: James Bottomley Cc: Zhao, Shirley, Mimi Zohar, Jonathan Corbet, linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: One question about trusted key of keyring in Linux kernel. @ 2019-12-11 17:53 ` Jarkko Sakkinen 0 siblings, 0 replies; 66+ messages in thread From: Jarkko Sakkinen @ 2019-12-11 17:53 UTC (permalink / raw) To: James Bottomley Cc: Zhao, Shirley, Mimi Zohar, Jonathan Corbet, linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: One question about trusted key of keyring in Linux kernel. 2019-12-09 19:47 ` Jarkko Sakkinen @ 2019-12-09 21:18 ` Mimi Zohar -1 siblings, 0 replies; 66+ messages in thread From: Mimi Zohar @ 2019-12-09 21:18 UTC (permalink / raw) To: Jarkko Sakkinen, James Bottomley Cc: Zhao, Shirley, Jonathan Corbet, linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: One question about trusted key of keyring in Linux kernel. @ 2019-12-09 21:18 ` Mimi Zohar 0 siblings, 0 replies; 66+ messages in thread From: Mimi Zohar @ 2019-12-09 21:18 UTC (permalink / raw) To: Jarkko Sakkinen, James Bottomley Cc: Zhao, Shirley, Jonathan Corbet, linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: One question about trusted key of keyring in Linux kernel. 2019-12-09 21:18 ` Mimi Zohar @ 2019-12-11 17:12 ` Jarkko Sakkinen -1 siblings, 0 replies; 66+ messages in thread From: Jarkko Sakkinen @ 2019-12-11 17:12 UTC (permalink / raw) To: Mimi Zohar Cc: James Bottomley, Zhao, Shirley, Jonathan Corbet, linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: One question about trusted key of keyring in Linux kernel. @ 2019-12-11 17:12 ` Jarkko Sakkinen 0 siblings, 0 replies; 66+ messages in thread From: Jarkko Sakkinen @ 2019-12-11 17:12 UTC (permalink / raw) To: Mimi Zohar Cc: James Bottomley, Zhao, Shirley, Jonathan Corbet, linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab', Zhu, Bing, Chen, Luhai 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: One question about trusted key of keyring in Linux kernel. [not found] <A888B25CD99C1141B7C254171A953E8E49094313@shsmsx102.ccr.corp.intel.com> @ 2019-11-14 17:01 ` Jarkko Sakkinen 2019-11-14 17:01 ` Jarkko Sakkinen 1 sibling, 0 replies; 66+ messages in thread From: Jarkko Sakkinen @ 2019-11-14 17:01 UTC (permalink / raw) To: Zhao, Shirley Cc: James Bottomley, Mimi Zohar, Jonathan Corbet, linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab' 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: One question about trusted key of keyring in Linux kernel. @ 2019-11-14 17:01 ` Jarkko Sakkinen 0 siblings, 0 replies; 66+ messages in thread From: Jarkko Sakkinen @ 2019-11-14 17:01 UTC (permalink / raw) To: Zhao, Shirley Cc: James Bottomley, Mimi Zohar, Jonathan Corbet, linux-integrity, keyrings, linux-doc, linux-kernel, 'Mauro Carvalho Chehab' 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
end of thread, other threads:[~2019-12-11 17:54 UTC | newest]
Thread overview: 66+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <A888B25CD99C1141B7C254171A953E8E49094313@shsmsx102.ccr.corp.intel.com>
2019-11-13 15:46 ` One question about trusted key of keyring in Linux kernel Mimi Zohar
2019-11-13 15:46 ` Mimi Zohar
2019-11-26 7:32 ` Zhao, Shirley
2019-11-26 7:32 ` Zhao, Shirley
2019-11-26 19:27 ` Mimi Zohar
2019-11-26 19:27 ` Mimi Zohar
2019-11-27 2:46 ` Zhao, Shirley
2019-11-27 2:46 ` Zhao, Shirley
2019-11-27 15:39 ` Mimi Zohar
2019-11-27 15:39 ` Mimi Zohar
2019-11-29 1:54 ` Zhao, Shirley
2019-11-29 1:54 ` Zhao, Shirley
2019-11-29 23:01 ` Jarkko Sakkinen
2019-11-29 23:01 ` Jarkko Sakkinen
2019-12-02 1:45 ` Zhao, Shirley
2019-12-02 1:45 ` Zhao, Shirley
2019-12-06 21:20 ` Jarkko Sakkinen
2019-12-06 21:20 ` Jarkko Sakkinen
2019-11-27 18:06 ` James Bottomley
2019-11-27 18:06 ` James Bottomley
2019-11-29 1:40 ` Zhao, Shirley
2019-11-29 1:40 ` Zhao, Shirley
2019-11-29 20:05 ` James Bottomley
2019-11-29 20:05 ` James Bottomley
2019-12-02 1:44 ` Zhao, Shirley
2019-12-02 1:44 ` Zhao, Shirley
2019-12-02 4:17 ` James Bottomley
2019-12-02 4:17 ` James Bottomley
2019-12-02 5:55 ` Zhao, Shirley
2019-12-02 5:55 ` Zhao, Shirley
2019-12-02 6:17 ` James Bottomley
2019-12-02 6:17 ` James Bottomley
2019-12-02 6:23 ` Zhao, Shirley
2019-12-02 6:23 ` Zhao, Shirley
2019-12-02 6:44 ` James Bottomley
2019-12-02 6:44 ` James Bottomley
2019-12-02 6:50 ` Zhao, Shirley
2019-12-02 6:50 ` Zhao, Shirley
2019-12-02 18:55 ` James Bottomley
2019-12-02 18:55 ` James Bottomley
2019-12-03 2:11 ` Zhao, Shirley
2019-12-03 2:11 ` Zhao, Shirley
2019-12-03 3:12 ` James Bottomley
2019-12-03 3:12 ` James Bottomley
2019-12-04 3:01 ` Zhao, Shirley
2019-12-04 3:01 ` Zhao, Shirley
2019-12-04 3:33 ` James Bottomley
2019-12-04 3:33 ` James Bottomley
2019-12-04 6:39 ` Zhao, Shirley
2019-12-04 6:39 ` Zhao, Shirley
2019-12-09 19:47 ` Jarkko Sakkinen
2019-12-09 19:47 ` Jarkko Sakkinen
2019-12-09 20:31 ` James Bottomley
2019-12-09 20:31 ` James Bottomley
2019-12-11 17:23 ` Jarkko Sakkinen
2019-12-11 17:23 ` Jarkko Sakkinen
2019-12-11 17:33 ` Jarkko Sakkinen
2019-12-11 17:33 ` Jarkko Sakkinen
2019-12-11 17:53 ` Jarkko Sakkinen
2019-12-11 17:53 ` Jarkko Sakkinen
2019-12-09 21:18 ` Mimi Zohar
2019-12-09 21:18 ` Mimi Zohar
2019-12-11 17:12 ` Jarkko Sakkinen
2019-12-11 17:12 ` Jarkko Sakkinen
2019-11-14 17:01 ` Jarkko Sakkinen
2019-11-14 17:01 ` Jarkko Sakkinen
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.