The purpose of a system is what it does 1. The purpose of BitLocker is to generate articles about interposer attacks.
post on HackerNews
Disclaimer: I work on TPM at Trusted Computing Group. As always, the views expressed in this blog are my own.
And every year, I assume a conversation like this occurs in Redmond:
“Should we fix BitLocker to deal with this issue?”
“No, we (picked our threat model 20 years ago|are too afraid of the code|sacked the people responsible for that so the execs could get bigger bonuses last year).”
Invariably, the telephone game that is tech journalism and social media pollutes the conversation, and people end up asking “why does the TPM suck so much?” (Answer: It’s not the TPM that sucks in this situation).
Security is about solving threat models, not extra credit. People (e.g., I) have asked the BitLocker team to update their threat model in the past. They haven’t so far. They probably won’t this year, or next time this topic hits my feed. So I am going to assume that BitLocker will never change. But here is how a full-disk encryption system like BitLocker could use the TPM properly. If Microsoft wants to hire an intern to finally fix BitLocker’s threat model some summer, that would be cool too.
See the diagram at the top of the post.
The naive implementation of a system that uses the TPM to unseal a disk encryption key causes the disk encryption key to appear in-the-clear on the TPM bus (typically, LPC or SPI). It’s not hard to read the 1s and 0s on these wires and convert them back into data. And nobody assumed that it would be. The TPM may as well be shouting the BitLocker key back to the CPU.
So, all these papers about breaking BitLocker are really about parsing LPC or SPI framed TPM commands. There isn’t, like, cryptography or anything happening here.
So, how can a full-disk encryption product protect itself from sophisticated attackers with access to a Raspberry Pi?
In terms of applied crypto toolboxes and the threat model, we would say that we want the host and the TPM to perform some sort of key establishment and then use that key to protect the secrets that have to traverse the bus.
Since this particular threat model includes a passive interposer who can read the bus but not modify/drop commands/responses, any type of key establishment would help here. Let’s say that we use Key Encapsulation as our key-agreement mechanism.
TPM supports TPM-specific RSA and ECC KEMs, designed to allow use of a restricted decryption key for this use-case, though without using the term “KEM” as that wasn’t popular until NIST’s PQC competition despite being apparently coined in 2001.
using S2 for response parameter encryption host->>host: Decrypt the unsealed key using SK end note left of host: Decrypt disk and boot
- Create a
decryptkey in the TPM during boot (do not use RSA unless you aren’t in a hurry to boot).
- Perform the encapsulation to create an additional encrypt session for the unseal command.
- Decrypt the encrypted response parameter using the key you encapsulated in (2).
Interested in active interposers? Now you’re thinking with interposers. You need some way for the host and the TPM to mutually authenticate. Check out what my colleagues and I are working on: https://www.osfc.io/2022/talks/protecting-tpm-commands-from-active-interposers/