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
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?
Show replies by date