I've got more of a spec/capability question than a tool specific question. With TPM2.0 and the new Extended Authorization (EA) stuff, I've been reading things like: "Policy authorization, also known as Extended Authorization (EA), is the Swiss army knife of TPM authorizations. With the right expertise, you can do just about any kind of authorization with it." - A Practical Guide to TPM2.0, pg. 207. So this got me wondering if it would be possible to create an authorization that relies on some external data being signed, and that signature being verified by the TPM with a loaded public key. More specifically, is it possible to tie some TPM protected secret to this signature verification result? The example I'm thinking is: Let's say I want the TPM to only allow reading of an NV secret if a system booted a signed kernel, and I want the secret to be releasable on any kernel signed by the correct key. I have seen Microsoft's TrEE EFI protocol and according to mjg59's blog post on the subject maybe this is exactly what I'm after, and I understand that booting signed kernels is already within the realm of Secure Boot but hey, this still seems like a useful exercise to think about with regards to TPM and maybe could be used on systems that don't have UEFI or don't boot with Secure Boot, but can use the TPM2.0. I guess a simple way to do this might be to verify the signature with software prior to GRUB loading the kernel, and just ensure that GRUB module, configuration, and public key get hashed and tie a secret to those. Maybe that's what I should be pursuing, but I'm just wondering if the TPM itself can do the verification. So this seems like it would need: * TPM support for a signature verification command that ultimately modifies a policy digest based only on whether the signature verified correctly or not. * A grub module to do this verification prior to loading the kernel * The grub module and configuration itself probably needs to be measured if it isn't already (PCR 5?), and the measurement needs to be included in the policy so that someone can't just replace the module and verify the signature but boot a different kernel... According to the specs, we have TPM2_VerifySignature. It's not a policy command, so I don't think I can use it in a policy, but it does return a TPMT_TK_VERIFIED ticket. The TPMT_TK_VERIFIED is only consumed by TPM2_PolicyAuthorize, but I'm not trying to authorize a new policy here. And then there is TPM2_PolicyTicket, which looks like it updates the policy digest based on whether a ticket checks out, but looking closer at the command definition, it takes in a TPMT_TK_AUTH ticket, not a TPMT_TK_VERIFIED ticket, and it looks like that kind of ticket is only produced by TPM2_PolicySigned and TPM2_PolicySecret, which seem to be for authorizing specific commands and their parameters by signing them. So maybe I'm misunderstanding or skipping over something, but am I correct in thinking the TPM commands defined in the spec may not be able to do this, even with EA? And if so, is there any roadblock or flaw in doing the verification with software by GRUB prior to loading the kernel?