TPM proof?

Posted Oct 17, 2018 18:09 UTC (Wed) by jejb (subscriber, #6654)
In reply to: TPM proof? by smurf
Parent article: Secure key handling using the TPM

> How can the TPM prove that it's really a TPM, instead of some software emulating one?

TPMs come with an endorsement key (EK) certificate signed by the manufacturer. Thus you run an X509 verification on this key which proves the public part of the EK (provided you trust the manufacturer, of course) and then the TPM itself will give you various proofs signed by the EK which you can externally verify.

The proposal for defeating TPM Genie with the in-kernel TPM handling relies on the kernel simply using the NULL seed primary as an encryption key but userspace proving after boot that this is indeed a key genuinely produced by the expected TPM.

to post comments

TPM proof?

Posted Oct 21, 2018 15:03 UTC (Sun) by jboone (guest, #128043) [Link] (1 responses)

I suppose there are a few downsides to asking userspace to verify the key.

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...

TPM proof?

Posted Oct 21, 2018 15:05 UTC (Sun) by mjg59 (subscriber, #23239) [Link]

One of the benefits of running the TPM stack on the ME is that MITM becomes a significantly tougher problem (and on chips where the PCH is on package, basically impossible) - I'm actually leaning towards using PTT rather than a physical TPM where possible.