AFAIK it is useless, there is no way the TPM could authenticate the CPU. You could always desolder the TPM chip, send the correct data for updating PCRs and get the sealed key.
"Useless" is grossly incorrect. Bitlocker is not invincible, but it lowers your threat surface by a huge %.
In real terms: if i get your unbitlockered hard drive, i own your shit. It's not a hack you pay crypto for on the dark web, it's a trivial compromise that every person in IT has known for at least a decade. If you google it, you'll find it. Ring 0 access to all nonbitlockered windows installs. Takes like 2 minutes and a usb or cd.
With bitlocker, at least every idiot on the planet can't login to your profile; that's not nothing
Yes, it's the same kind of useless.
Anyways on many modern system the TPM is often just part of the firmware running on a secure part of the CPU and probing the signals in the chip is probably outsider of the budget of TikTok influencers.
At an enormous cost of having to remember and enter a PIN - not practical for corporate IT due to the propensity for forgetting and not practical for offline server use.
> Anyways on many modern system the TPM is often just part of the firmware running on a secure part of the CPU
On AMD this is almost 100% prevalent, yes.
On Intel platforms a physical TPM is still common and PTT (firmware TPM) is usually disabled by default for some reason - a user/manager would usually have to re-select it in the BIOS. On desktop platforms I think PTT runs externally in the PCH, too, which is off-package and connected over DMI (I think on most mobile parts PCH is a separate on-package die). I don't think anyone has done research on how the fTPM part of PCH <-> CPU comms work on modern Intel platforms; this has always seemed like a fun topic for a deep dive and talk to me, but I've never had the time.
I don't think either of these things excuses the lack of encrypted parameter support from BitLocker, though. I'd love to know why Microsoft continue not to use it. The only reason I've ever seen given is "it was deemed too complex / has an attack surface," which is an interesting idea but quite bunk when UEFI is already in the picture IMO.
It would be unusual for any current device to have a discrete TPM, at least in the consumer space given current x86 processors have an fTPM.
The disk PIN on boot is uncommon/harder to do for home users, but it's a common setup in the corpo world. Enforced by AD, or Intune.
The disk password actually encrypts the disk, so you can't just pull the disk out and read it, or boot Linux from a flash drive and read it.
You can do the above attacks when all that's set is a Windows password. In fact, you could even modify the OS at that point so it logs and exfiltrates passwords in the future.
This isn't true for all implementations of TPM, but for AMD/Intel/Qualcomm where BitLocker is relevant, fTPM is used.
Where it states: Module dTPM 2.0 (Discrete Trusted Platform Module)
Same for HP EliteBook and ProBooks: https://h20195.www2.hp.com/v2/GetPDF.aspx/c08049273.pdf
In modern CPUs, the TPM is built directly into the CPU, so you can't do this.