TPM proof?

First, if a man-in-the-middle (interposer) sits on the bus between the kernel and the TPM peripheral, then by the time that userspace executes, the kernel may have already been compromised. For example, this MITM can spoof measurements that are extended into PCRs, making it appear as if a malicious kernel is in fact legitimate. A compromised kernel should be able to present the real key to userspace.

The kernel could itself verify the key prior to communicating with the TPM (for the purposes of PCR extends, unsealing secrets, etc). But I understand why we may not want to do key verification in the kernel, asking the kernel to keep copies of public keys [1] for every TPM manufacturer is a maintenance problem. As an aside, similar challenges are faced by other peripheral drivers, such as the USB Type-C Authentication scheme [2] and the more recent PCIe Device Security Enhancements [3].

The above also holds true for the pre-kernel boot environment. Each boot stage needs to be able to securely communicate with the TPM. As with the kernel, the PCR Extend operations that are performed by the platform's bootloader(s) must be integrity protected. This requires knowledge of the HMAC shared secret, which must be kept hidden from a MITM. So we once again encounter the same problem that is faced by the kernel.

[1] https://www.st.com/content/ccc/resource/technical/digital...
[2] https://community.nxp.com/servlet/JiveServlet/downloadBod...
[3] https://www.intel.com/content/www/us/en/io/pci-express/pc...