Use encrypted sessions

[nicowilliams]

Encryption sessions would defeat some of the attacks that a system with a discrete TPM can be susceptible to. From the Safeboot docs:

The Discrete TPM is potentially a hardware weakpoint; a physically
proximate adversary could remove the TPM from a machine and connect
it to an untrusted device and then masquarade as the device to which
the TPM had been connected.  This would also potentially allow them to
extract any sealed disk encryption keys, [as described on the threat
model page](threats.md), and is one of the advantages of an fTPM inside
the Management Engine.

A proximate attacker could also interfere with the LPC
or i2c bus of a Discrete TPM using something like
[the TPM Genie](https://www.nccgroup.com/uk/our-research/tpm-genie/),
which allow them to both modify the hashes sent to the TPM during PCR
extension operations, and read the unsealed secrets when they are returned
if the TPM didn't support secret sessions.

With encrypted sessions the only question is: do you know the dTPM's EKpub a priori? If so, then there is no impersonation attack, no spoofing PCRs, nothing. An encryption session allows the first TPM2B request or response parameters to be encrypted, and the full request and response hashes to be authenticated. And if one does not know the dTPM's EKpub a priori, then the next question is: can one "learn" it? If one cannot learn the EKpub then in the end there is an impersonation attack, but the interposed TPM has to stay around for every attestation or else the machine's local storage must be stolen immediately in order to gain anything.

I believe this is enabled by using the --key-context option of tpm2 startauthsession, but I'm not sure how one then uses an encryption session with other tpm2-tools commands. Issue #40 suggests using the tss tools from (I think) tpm2-tools, which apparently always use encryption sessions.

[osresearch]

A practical example of why encrypted sessions might be useful: https://dolosgroup.io/blog/2021/7/9/from-stolen-laptop-to-inside-the-company-network

To recap, we took a locked down FDE laptop, sniffed the BitLocker decryption key coming out of the TPM, backdoored a virtualized image, and used its VPN auto-connect feature to attack the internal corporate network. That is one way to go from stolen laptop to internal compromise.

Matthew Garrett has a short twitter thread on some lessons from this writeup: https://twitter.com/mjg59/status/1420480165113581568

I'm trying to make sense of how the key for the encrypted sessions is derived; it seems like it has to be pre-shared for the HMAC secret, which creates both a chicken-and-egg situation as well as a second problem of where to store the HMAC secret on the x86 that the attacker wouldn't be able to access. The ESAPI specification is as unclear as expected for a TCG document...

[nicowilliams]

Note that to avoid MITM attacks you really need to have the UEFI BIOS a) learn the public key for some primary for the TPM, b) use encrypted sessions and use cpHash and rpHash to provide integrity protection (authentication) of all TPM commands issued (especially TPM2_PCR_Extend()s!).

(a) needs to be done before the OEM ships the box, preferably, or if by the customer, then in a controlled environment.

[nicowilliams]

https://github.com/osresearch/safeboot/issues/40#issuecomment-875197305