Could TPM disk encryption be compromised with physical device access?

Question

Assuming Linux is installed with full disk encryption and a passphrase-less boot via TPM, could the decryption key exchange between Linux and the TPM be intercepted if an attacker gained physical access to the devices below?

1. A device directly running Linux with a physical/hardwired TPM chip
2. A device indirectly running Linux within a VM emulator/virtualizer (e.g. QEMU, VirtualBox) that virtualizes the TPM

How technically-sophisticated and difficult is (2)? The ArchLinux TPM + Secure Boot article mentions cold boot attacks, which seems to introduce a very difficult challenge to novice attackers.

The goal is to provide our developers with encrypted VMs that compile their software using protected source code. I trust them, but I am also trying to validate a potential attack vector or theft.

Answer 1

For 1, with a physical discrete TPM (dTPM) it's a pretty low-cost attack. Since the CPU can't store any encryption keys, since it doesn't have a firmware TPM (fTPM), the communication between CPU and TPM is unencrypted. Thus there are a bunch of ways to sniff the TPM communications. fTPMs are less vulnerable, since there's no communication outside the CPU package. That doesn't mean they're invulnerable though, the sorts of glitch attacks Christopher Tarnovsky used against some discrete TPMs can likely be done against a CPU with fTPM as well. This is a much higher-cost attack than sniffing the motherboard bus a dTPM communicates with the CPU over.

For 2, if the attacker can execute code at the hypervisor level they can read arbitrary memory out of the guest OSes, including the virtual TPM.

As for protecting source code from developers using it, they can always take photos of the code on their screens. No program on the machine can prevent that. A legal option like a non-disclosure agreement is likely just as good better choice.

Answer 2

1. Yes, if you have physical access to the computer, attacks that physically snoop the bus between the TPM and the CPU are possible, and if the user has not set a passphrase for drive encryption, then yes, recovery of the disk encryption key is possible. However, it is also possible to encrypt the session using more recent TPM functionality - see https://trustedcomputinggroup.org/wp-content/uploads/TCG_CPU_TPM_Bus_Protection_Guidance_Passive_Attack_Mitigation_8May23-3.pdf which may prevent this snooping in more modern TPMs that support TPM2.
2. "Virtual" TPMs rely on the software layer (hypervisor) and/or an external (not the actual real TPM) KMS to protect access to the physical TPM or provide an emulated version of the TPM. In the case of VirtualBox, it's (apparently) possible in later versions of VirtualBox to "passthrough" the physical host TPM to a guest using the --tpm-type==host parameter, but this would "presumably" limit the use of the TPM to a single guest? It seems that few, if anyone, have actually got this working (https://forums.virtualbox.org/viewtopic.php?t=110429). Openstack (with libvirt) provides a virtual TPM too, however this is a "file on disk" protected with a key from a key management service (https://docs.openstack.org/nova/latest/admin/emulated-tpm.html).

Answer 3

Don’t know about Linux. On iOS there is a different 256 bit key built into any CPU. That key cannot be read, you can only use it to encrypt/decrypt things. Yes with this key readable lots of security would be gone. Nobody has found a way yet to do it. Side effect is that you can decrypt the drive only on its iPhone (and not on a more powerful computer)

The second key is a random key generated when you do a factory reset of the phone. Encrypted with the CPU key and stored in two locations so it doesn’t get lost. This is not so much about security, but quick erasure. Overwrite the two copies of the key with zeroes and nothing is ever readable.

The third key is your passcode with some cleverness to change the passcode without re-encrypting all the data. Not everything needs this passcode. Like taking photos, using the calculator app and obviously the code where the user enters their passcode must work before you have entered the passcode.