Sealing secrets with PolicyPCR and PolicyAuthorize

[jpbland1]

TPM2 has a special way of controlling access to resources within the TPM called policy authorization. A policy can be created by running any number of policy commands. The policy doesn't have any struct or metadata on what commands were run, instead each policy command updates an internal digest called policyDigest, which is stored within the tpm session being used. If resources are created withing the tpm after setting up a policy, they can only be retrieved by re-running the same policy commands to re-create the policyDigest.

This commit adds wrapper functions to create a policy using PolicyPCR and PolicyAuthorize and then seal and unseal a secret to the TPM, for both NVM and ram storage, with the resulting policyDigest. In effect these functions will gate access to the sealed secret on:

1. The PCR values selected, which is the state of the TPM and the board it manages
2. The presence of a signed policyDigest in case the PCR values have changed but have been re-signed by an authoritative key In the case of NVM storage an authoritative key is not used, only the PCR values are but the policy can still be updated by overwriting the NVM index that holds the policyDigest when the PCR's change

The topic of policies is esoteric so examples have been provided to show how these functions are used in examples/seal/seal_policy_auth and examples/nvram/seal_policy_auth_nv.c.

[HarryR]

I've open-sourced the Linux bootloader code I was working on which is based upon gummiboot (prelude to systemd-boot), the UKI pulls the decryption key from the TPM after satisfying the PCR policy to ensure that after sealing only the machine which has been imprinted with the bootloader can boot it.

Apologies for not getting back to you sooner, and I don't have time to integrate wolftpm/wolfss with this project at the moment.

https://github.com/HarryR/cummiboot