Very interesting video. For those who can't watch, he creates a PCB with a RPi Pico and some data pins which can sniff the BitLocker key as it's sent from the TPM chip back to the CPU. I was surprised to see that this was sent in plaintext, so although his board probably will only work for that particular motherboard, the method would be sound for other computers as well.
I'll leave the comments about MS requiring TPM chips for Win11 to others.
It's a bit of a chicken-egg problem when the TPM is the root of trust for the entire system. Sure you can encrypt the data on the bus, but where do you store that key?
You use a Diffie-Hellman key exchange, signed by a cert stored in the CPU on one side and verified by the TPM on the other. CPUs already have such secret certs inside of them, for example for Intels' SGX.
But as you can read in the article linked by /u/osy, the TPM ecosystem is a victim of design by committee where such things as a threat model are not a thing. They were focused on building a "generic security solution" or some other nonsense, instead of making a threat model, then a protocol, then a verification of the protocol under the threat model - like people did for example with TLS 1.3.
Exactly. An attacker that has full access to the device can get past encrypted TPM parameters, it would just slow them down. The best method is pre-boot auth where the TPM itself requires a PIN to release the keys. Windows doesn't use that by default, but it can be enabled.
It could be burned into the CPU die by blowing fuses, or stored in a tiny bit of on-die flash, or stored encrypted in SPI flash, encrypted with a factory secret key burned into the CPU at manufacture.
But more generally, you don’t need a long term key to prevent sniffing attacks like this; Diffie-Hellman is a thing. Doing an unauthenticated DH would make this attack harder and slower (active MitM probably requires removing the TPM chip from
the board) but would not prevent it.
Maybe it would be more practical MITMing near the CPU. Some plastic "extender" routing the relevant pins through an external device but still allowing for cooling?
But could the communication be authenticated? Like in CPU having a public cert, self signed. TPM then can authenticate the CPU that generates the key and later sends it only over an authenticated TLS session to the same CPU.
No big deal here. This attack looks like it's using a crusty old TPM 1.2 laptop, so encrypted parameters to the TPM aren't supported. Even with Win11 and TPM2.0 (required for Win11), encrypted parameters to the TPM would just slow down an attacker.
You need to use pre-boot auth, like a PIN. Obviously, the TPM needs to have some kind of authentication to release the key, not just the default mode where Windows just needs to request it. This is all outlined in MS documentation: https://learn.microsoft.com/en-us/windows/security/operating...
I agree. It seems Microsoft wants to get the accolades of solving a hard key exchange problem without actually solving that hard key exchange problem. We see this a LOT in companies that "make it easy" to do cryptography.
You're forgetting the other convenience value of the TPM in Windows, which is that it allows you to use a PIN/bio instead of your (hopefully) long and complex account password.
I think that's a bit of an overstatement. You already enter a password to sign in (or not, if you use biometrics). This is just another password that you enter once at boot. Doesn't seem all that bad of a tradeoff for data security.
There is nothing that is safe against physical attacks practically. You can always find a point where you can do a MITM attack as the communication channels between the TPM and anything else is almost always insecure.
>There is nothing that is safe against physical attacks practically.
This! If security is your prime directive in your line of work(government, highly sensitive data, etc), then as long as your device has been outside your physical possession and in the hands of an untrusted third party, then it's automatically considered compromised and gets wiped or discarded by your IT department.
Because no amount of marketing security fluff from Microsoft, Apple, Google can stand against targeted attacks of state actors or knowledgeable motivated well funded actors with freshly acquired zero days.
The security they provide is only good enough against the average thief off the street, which I guess covers 98% of Average Joe's threats.
Even CC security certifications never judge a device whether it's hackable or not, but only on how long it takes for it to be hacked by an accredited lab, because nothing with outside physical access is ever unbackable. With enough time and six figure equipment off the publicly available commercial market, everything reveals its secrets eventually. And that's without zero days off the black market.
> only good enough against the average thief off the street,
Even there, only Apple has effective protection against street-thieves. Nearly all other models of phones/laptops can have their anti-theft features reset by a guy in a dark alley with a flash programmer...
So far, most thieves aren't interested in your info, they just want to reset the hardware and give it a new serial number.
Most other makes of phones and laptops aren't as valuable as Apple's to be big targets of theft. And Samsung has KNOX and Pixels have Google's Titan security.
Also, physical security is sometimes the best thing because it maps well to all of our human intuitions and senses for enforcing it and detecting when it was violated.
Consider how different a wireless hacking attack is from one where somebody has to sneak up and stab your device with an RJ-45 plug.
I use to work in Microsoft DRM. I used to say: the key is on the machine! This is like leaving your house key under a rock in the garden. It just puts up a barrier of a certain level which puts off most villains.
Sure, but there are many shades of gray. Directly leaking the entire key on an external bus is very different than needing to find and somehow bond to individual traces (likely below the top metal layer) on the die itself.
Only a sith deals in absolutes (jk). Even with physical access, you can define restrictions that introduce some level of difficulty for a threat actor with limited capability. For example, you can just kick in most house doors to get past locks, but people still lock their doors. Cars are a better example, most car theft happens when people leave their doors unlocked.
Having a non-zero attack surface doesn't mean your security system provides "zero practical security". This is at best equally as hyperbolic as the vendors' own marketing claims that you are arguing against.
Not really? Encrypted sessions block the trivial attack of just watching the secret go across the bus. Pushing people to MITM attacks is already an improvement, and while generating initial trust in the TPM for that purpose isn't straightforward, it's not impossible. The almost universal implementation of TPM-backed secret management isn't secure against physical attack, but that's very different to "insecure by design". All the primitives to make this work reasonably are there, OS and firmware vendors just aren't using them.
Yes really. The lack of any working implementation in production systems is an issue (D-RTM + encrypted sessions), something that Apple has done in an equivalent threat model since the iPhone 11. You can argue that "insecure by design" doesn't apply because there is a secure design in the abstract but the fact that nobody has adopted it in 20 years says something about the design itself.
It's _also_ insecure by design because in every deployed implementation (including with PIN), it is S-RTM meaning that _any_ UEFI driver vuln will compromise your TPM key. Yes, any UEFI vulnerability in its countless vendor drivers, USB stack, network stack, etc.
>All the primitives to make this work reasonably are there, OS and firmware vendors just aren't using them.
To be precise, both Windows (according to the article) and Linux+systemd (since systemd v251) support letting the user specify a TPM PIN and then use parameter encryption. But yes, both make it optional.
It's not actually used for DRM, that's part of Intel ME and why AMD PSP is closed source. Both of those are involved in setting up "protected media path" which is all about setting up encrypted channel between display and media player to prevent sniffing.
TPM could be used for DRM in the sense that DRM software could refuse to run on system that isn't approved, but it's not going to stop you from enjoying a DRM free system - in fact it can help by explicitly supporting clearing of TPM state by owner.
Nothing new. This attack is demonstrated here many times and the Microsoft docs discuss a similar attack using self encrypting drives. The counter measure is to use a virtual TPM built into the CPU or to use TPM+PIN (which is standard practice for security).
Yes, it does, as does using any other CPU or chipset based TPM (Intel PTT, the AMD PSP-based TPM, running in Trustzone on ARM). The non-Pluton approaches potentially have greater overall attack surface, so Pluton is probably the best choice if available.
This is particularly interesting considering that TrueCrypt recommended migration to BitLocker as the main option for Windows: https://truecrypt.sourceforge.net/
IIRC Apple's version of TPM (Secure Enclave) should be immune to such attacks (since it's on the SoC, but I'm not sure whether the communication is encrypted or not), and the main data encryption method for GNU/Linux (LUKS) does not utilize TPM by default (might depend on distro though).
EDIT: I believe that the method in the video only works for volumes that aren't password/PIN-protected.
If you worry about someone sniffing your hardware buses, you should also worry about them intercepting your keyboard connection when you type the TrueCrypt password.
TPM 2.0 supports encrypted sessions, which block this kind of attack (TPM 2.0 is wholly different beast than TPM 1.x series).
I do not recall if cryptsetup's TPM2 support sets up encrypted session, but for BitLocker just setting it to require PIN breaks this attack (the PIN is used as part of TPM policy preventing automatic decryption).
Additionally, some laptops at the very least attempt to erase TPM on case open.
I think the "on case open" bypass was shown quite well in this video (the picture of the Surface device with a hole drilled in the back).
Such measures should protect against backdooring attempts (by the visible physical damage to the case) but they won't prevent an attacker from reading the secret key.
Didn't know! After TC vanished with recommendation to use BL I had kept few files in direct Windows storage protected by BL. The more sensitive ones I still kept in Vera. Here my natural scepticism protected me lol.
Note: there's also Bitlocker for non-boot drives, aka Bitlocker to Go. It functions more like TV/VC in that you can encrypt a drive/partition/removable storage with a password. You probably don't want it to auto-unlock in that case.
I predict that this will necessitate an upgrade to TPM 3.0 with a key exchange handshake mitigation along with it being a requirement to upgrade to Windows 12. That’s fine though because it will help with economic growth and all the relevant companies’ bottom lines.
I think TPM-only encryption is still good enough for cases where a thief may try to swipe the hard drive out to steal the information on it later.
Plus, in a business where laptops may get reused, it could be a method to make an old Windows install inaccessible by wiping the backup key from the cloud and clearing the TPM on the device without any formatting. You may want to do a quick format to be sure (you never know if someone kept their private files in the EFI partition) but it'll protect you against data recovery risks from reassigned sectors without having to force everyone to enter a password twice every time they boot their laptop.
These kinds of attacks aside, the intent is that you need to turn on the PC and then actually boot to the intended operating system, which is then protected with a login screen
The "big deal" is just seeing it demonstrated this quickly. TPM-Sniffing is an old hat [1], but I always thought it would take at least hours of painstaking fiddling with a soldering iron. I find this video impressive and eye opening.
Modern systems don't have a dedicated TPM, so it's a lot harder to read the settings off the chip, as it is part of the CPU.
Then I believe modern TPM communication is encrypted.
On too of that you want your laptop to support physical tampering resistance, which prevents both this (outdated) chip attack and freezing the RAM. When you then boot the laptop the master password is required. I would prefer it to throw off the PCR but hey, it works too.
I do wonder if you have 8GB of soldered RAM and 8GB on a stick, Windows keeps the key in the soldered part to increase difficulty stealing?
Opposite - the TPM is hardware TPM and that's why it was easier to sniff the communication between it and the CPU over LPC. fTPM resides inside the CPU so sniffing is not as easy.
That's compelling. I understand fTPM is less resistant to system level attacks because of the virtualization nature of it. Seems like a conundrum of tradeoffs.
I'll leave the comments about MS requiring TPM chips for Win11 to others.