Decorative Cryptography

Summary

All encryption is end-to-end, if you’re not picky about the ends. config TCG_TPM2_HMAC bool "Use HMAC and encrypted transactions on the TPM bus" default n select CRYPTO_ECDH select CRYPTO_LIB_AESCFB select CRYPTO_LIB_SHA256 select CRYPTO_LIB_UTILS help Setting this causes us to deploy a scheme which uses request and response HMACs in addition to encryption for communicating with the TPM to prevent or detect bus snooping and interposer attacks (see tpm-security.rst). Saying Y here adds some encryption overhead to all kernel to TPM transactions. Last year, I came agross a Linux kernel feature called TCG_TPM2_HMAC. It claims to detect or prevent active and passive interposer attackers. That’s one of my sleeper agent activation phrases, so I dug in. TCG_TPM2_HMAC lives primarily in drivers/char/tpm/sessions.c and is discussed at further length in Documentation/security/tpm/tpm-security.rst. It all sounds really great. We should care about interposer adversaries. It’s great to use the TPM features that were invented to help us with these problems. Let’s draw a little picture of what’s being attempted here. In this threat model, there is an adversary who can access the untrusted bus on which all the TPM traffic is sent during the boot. This can be done using hardware hacking or by hijacking another device that controls the TPM bus (e.g., a BMC). TCG_TPM2_HMAC is a kernel feature, and the kernel boots after the platform firmware and the boot loader, so it can’t do anything about interposer adversaries tampering with firmware and boot loader measurements. Let’s assume for now that the firmware and boot loader are just implicitly trusted to have booted “correct” code and successfully made honest measurements of all the boot stages up to and including the kernel. We also implicitly trust the TPM to behave correctly, here. Or if you have a newer TPM, don’t! Someone familiar with the STRIDE model can easily observe the following threats just on the big red wire in our picture a...