tpm2_makecredential: EK authorization policy hash

[osresearch]

https://github.com/tpm2-software/tpm2-tools/blob/857e6fc7f160f14e7571ffaa70caa84e28c59935/tools/tpm2_makecredential.c#L299

What is the source of this policy hash? It seems like it should have a comment explaining its meaning and use.

[williamcroberts]

Its from the EK Profile spec B3.3.3 Template: https://trustedcomputinggroup.org/resource/tcg-ek-credential-profile-for-tpm-family-2-0/

Its a policy described in B.3 where the auth is tethered to the endorsement hierarchy password.

[williamcroberts]

I see a newer version came out, we should probably add all the templates to CreateEK and let users pick.

[osresearch]

Thanks for the link to the section in the spec. This seems like it would be useful in the source for future explorers.

The spec defines the policy as TPM2_PolicySecret(TPM_RH_ENDORSEMENT), which seems like it can be satisfied with:

# tpm2 startauthsession --session session.ctx --policy-session
# tpm2 policysecret --session session.ctx -c e
837197674484b3f81a90cc8d46a5d724fd52d76e06520b64f2a1da1b331469aa

Section B.6.2 has the math worked out:

policyAlg = SHA256, or SHA384, or SHA512, or SM3_256
policyDigestold = 0x0...0 (32, or 48, or 64 bytes)
TPM_CC_PolicySecret = 0x00000151
authObject→Name is TPM_RH_ENDORSEMENT (=0x4000000B)
policyRef.buffer = not available (policyRef is an Empty Buffer)

The policy digest is calculated as follows:
policyDigestnew ≔ HpolicyAlg(0x0...0 || 0x00000151 || 0x4000000B)
policyDigestnew+1 ≔ HpolicyAlg(policyDigestnew)

[williamcroberts]

Their a reference in in

Thanks for the link to the section in the spec. This seems like it would be useful in the source for future explorers.

I agree, but it is referenced (a different version or something) in: doc/man/tpm2_createek.1.md

The spec defines the policy as TPM2_PolicySecret(TPM_RH_ENDORSEMENT), which seems like it can be satisfied with:

# tpm2 startauthsession --session session.ctx --policy-session
# tpm2 policysecret --session session.ctx -c e
837197674484b3f81a90cc8d46a5d724fd52d76e06520b64f2a1da1b331469aa

Section B.6.2 has the math worked out:

policyAlg = SHA256, or SHA384, or SHA512, or SM3_256
policyDigestold = 0x0...0 (32, or 48, or 64 bytes)
TPM_CC_PolicySecret = 0x00000151
authObject→Name is TPM_RH_ENDORSEMENT (=0x4000000B)
policyRef.buffer = not available (policyRef is an Empty Buffer)

The policy digest is calculated as follows:
policyDigestnew ≔ HpolicyAlg(0x0...0 || 0x00000151 || 0x4000000B)
policyDigestnew+1 ≔ HpolicyAlg(policyDigestnew)

[idesai]

IMHO we should remove this hardcoded policy inclusion in the default key template for makecredential. But it will be a backward compatibility breaking change. What we can instead do is add a -L, --policy option to specify an alternative policy or simply none to not include any policy at all. We should not be restricting the tool usage to keys created with createEK. Keys could also be created with createprimary as an example. This was partially done for activatecredential in f8b528bb. Need to complete this work for makecredential.

[williamcroberts]

IMHO we should remove this hardcoded policy inclusion in the default key template for makecredential. But it will be a backward compatibility breaking change. What we can instead do is add a -L, --policy option to specify an alternative policy or simply none to not include any policy at all. We should not be restricting the tool usage to keys created with createEK. Keys could also be created with createprimary as an example. This was partially done for activatecredential in f8b528b. Need to complete this work for makecredential.

Yep, I agree they should be generic enough to work with everything, but the 80% use case is with the EK. So we probably want a way to create an EK to templates with createek tool, and then know in make credential via an option which template ek they want. This seems to only be a case if they use a PEM file as well. If they use a context file, we have all the data, is that right? If they don't use a template EK they should specify all the bits as command line params. Thoughts?

[idesai]

IMHO we should remove this hardcoded policy inclusion in the default key template for makecredential. But it will be a backward compatibility breaking change. What we can instead do is add a -L, --policy option to specify an alternative policy or simply none to not include any policy at all. We should not be restricting the tool usage to keys created with createEK. Keys could also be created with createprimary as an example. This was partially done for activatecredential in f8b528b. Need to complete this work for makecredential.

Yep, I agree they should be generic enough to work with everything, but the 80% use case is with the EK. So we probably want a way to create an EK to templates with createek tool, and then know in make credential via an option which template ek they want. This seems to only be a case if they use a PEM file as well. If they use a context file, we have all the data, is that right? If they don't use a template EK they should specify all the bits as command line params. Thoughts?

That's correct. If the key is specified in TCG format the key template is already available. To specify the entire key template could also be an option when specifying in pem. Although, we may have to use the TPM2_CC_CreateLoaded command which is the only one able to output a consumable key template. Nevertheless, it is a good option to have.

So for PEM files:

• [ ] --policy only policy can be specified (including blank policy). The rest of the key description is standard EK.
• [ ] --template option the entire template can be specified.