Hacker News Reader

Comment by jandrese | Hacker News Reader

Fundamentally I don't understand BitLocker's security model. In most installs it seems like you power on the machine by pressing the power button and it boots into Windows.

So if someone steals you machine with an encrypted hard drive they need to...just turn it on? That can't be right, but at the same time I have no idea how this particular attack is defeated. I have to assume the traffic over the SPI bus is encrypted so the key can't just be dumped like that, but it seems like the machine is going to give up the key pretty easily regardless.

With LUKS it at least has a password prompt to unlock the drive.

View on HN

> I have to assume the traffic over the SPI bus is encrypted so the key can't just be dumped like that

It's not. For some reason, Microsoft don't use TPM parameter encryption, even though every year or two some security researcher or another comes up with another stunt TPM-sniffing device to parade around.

> With LUKS it at least has a password prompt to unlock the drive.

Configuration dependent. You can set up Linux to do the same thing as Windows here (I have my home video-security server set up this way, as it needs to reboot silently - I know that I'm vulnerable to warm/coldboot attack and software attack surface, but at least if someone yoinks the drive I'm safe), and Windows can also be configured to prompt for a password or use PIN-authenticated TPM sealed keys.

> Fundamentally I don't understand BitLocker's security model.

Minus the parameter encryption / bus-sniffing issue, it moves the boundary from "anyone can read your drive" to "someone needs to either perform a platform-level attack to access the contents of memory, or hack whatever services are running at the login screen to read your drive." It's a decent security improvement, actually, because it protects very well against stuff like "someone stole our financial data off of a random recycled hard drive."

> It's not. For some reason, Microsoft don't use TPM parameter encryption, even though every year or two some security researcher or another comes up with another stunt TPM-sniffing device to parade around.

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.

It's one of those "useless in theory but extremely meaningful in practicality" things, IMO. Getting the correct PCRs is going to be a whole lot harder than putting a sniffer on the LPC. It takes the attack from something that random TikTok security "influencers" sell devices for to something which requires meaningful effort.

Using Bitlocker with a PIN solves that.

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.

> Using Bitlocker with a PIN solves that.

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.

The Intel PCH is on-package exposed via [DMI] PCIe lane while AMD's fTPM is on-die.

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.

I haven’t used Windows since the XP days. Does Windows not have a login password? Or does something make it require a separate disk PIN and not just encrypt the drive with the login password? macOS does the latter and it seems like an obvious approach.

In this case, they're talking about the Bitlocker disk encryption PIN, which is in _addition_ to the Windows password, or more common now, PIN. You can set them both to the same thing if you choose.

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.

A disk PIN shouldn’t add much extra security, though, unless the login password isn’t actually used to key the encryption.

I'm not aware that Windows uses your login key to encrypt anything on the disk, but maybe Windows 11 does it differently than <=10.

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.

That's the same kind of useless as "I don't have a front door. You could always drive through it with your car and get inside that way", right?

Considering security "researchers" absolutely love to make cataclysmic mountains out of vulnerabilities that require local, physical access as the first step?

Yes, it's the same kind of useless.

TPM is now in firmware and has been for quite a few years on Intel and AMD processors; Intel's on the PCH which is on-package and AMD's on-die.

This isn't true for all implementations of TPM, but for AMD/Intel/Qualcomm where BitLocker is relevant, fTPM is used.

On company laptops this isn't always true, for instance here's the spec sheet of the ThinkPad T14 (this seems to be true for all ThinkPad models): https://www.lenovo.com/fr/fr/p/laptops/thinkpad/thinkpadt/th...

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

> AFAIK it is useless

"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

All modern CPUs now have it on-die, so doing a replay attack against desoldered TPMs is no longer a thing.

> You could always desolder the TPM chip, send the correct data for updating PCRs and get the sealed key.

In modern CPUs, the TPM is built directly into the CPU, so you can't do this.

> So if someone steals you machine with an encrypted hard drive they need to...just turn it on?

That'd bring them to a login screen. Without your password or biometrics, they're not getting past that. They'll have to figure out some kind of workaround (like a RCE exploit, or booting an old, vulnerable Windows bootloader somehow) because they can't do the usual "replace the software keyboard with cmd.exe" workaround as the drive remains locked.

Without Bitlocker, you can plug a Windows drive into your PC and browse all the files. With Bitlocker, you need to faff about with exploits and vulnerable Microsoft software and dumped memory, and even that doesn't always work.

With Bitlocker configured in TPM+PIN mode, you can't even do that, as you don't have the password to unlock the TPM. You could also put Bitlocker in password-only mode, but that's much easier to brute-force. Same goes for LUKS, by the way, which also supports TPM and TPM+PIN in most Linux distros these days.

> So if someone steals you machine with an encrypted hard drive they need to...just turn it on? That can't be right, but at the same time I have no idea how this particular attack is defeated.

Yes, but the idea is that from the login screen (winlogon) you really can't do much unless you actually have account credentials on the computer - or are bio-metrically enrolled into the computer* - and if you attempt to reboot to safe mode, or reboot to a different OS (or firmware update utility, etc) you do need to enter the Bitlocker recovery key.

* I'm not sure how it works in terms of "hacking" fingerprint sensors or face recognition webcams.

You also can't look at the encrypted drive's contents if you connect it to a different machine.

No, I expect the encryption key is probably stored in an efivar.

The primary purpose of Bitlocker (when used with a PIN + TPM) is it makes a powered off computer or a drive itself as good as a brick. Assuming the TPM doesn't have any key extraction vulnerabilities.

Keyword is powered off.

With any general purpose drive encryption, the TPM doesn't actually decrypt the bulk of the data as its too slow so the OS eventually ends up with a key that is extractable.

BitLocker volumes can have multiple protectors; you can use a key file, a passphrase, PIN or TPM storage: https://learn.microsoft.com/en-us/windows-server/administrat...

In Pro editions it is also possible to require an interactive step at boot time via group policy (this also works if you have no TPM available), then it will ask for a password on each startup.

While I am aware of bitlocker in general, I don't have a full grasp of it. Just how secure is it from a software of hardware attack?

It was my understanding that veracrypt was considered more tested than bitlocker due to the lack of backdoors or workarounds. Can anoyone point me at some good resources regarding this?

It depends on the mode you're using. If you use the transparent unlock functionality (the default) then it's vulnerable to hardware key extraction. If you use anything else (PIN, password, whatever) then I'm not aware of any weaknesses or workarounds. I'm certainly not aware of any backdoors.

I think with a Microsoft account login on Windows 10/11, BitLocker recovery keys are synced to your Microsoft account and can be viewed from your Microsoft account device settings. They may also be present on Active Directory so there may be some vulnerabilities on any of those avenues which may be easier to circumvent than BitLocker itself.

Syncing keys to OneDrive is optional, at least on the Pro versions of Windows.

> With LUKS it at least has a password prompt to unlock the drive.

BitLocker should ideally be used with a PIN/password too. This means the key isn't decrypted until the correct PIN is entered. No SPI sniffing, UEFI exploits, or memory dump would help the attacker in this preboot state. BitLocker with TPM and PIN is a pretty powerful combination.

But by default, without any second factor, BitLocker is two parts convenience and one part security. Probably the price of user adoption.

The threat model is getting the decrypted data.

If someone steals the device and removes the drive the data is encrypted.

If someone steals the device and powers it on, the os that wrote the encrypted data (and is presumably secured) can enforce login authorization which the thieves presumably cannot bypass.

Both of these are big ifs, but the installed os won’t just divulge the contents of the disk so the trick is locking down the disk so that it’s easy for the installed os to access but becomes useless if the disk is removed from the computer.

All of this depends on the TPM implementation not being trash, which integrated instances help with. Ultimately this is a trade off for convenience. I don’t worry about random thieves probing the buses in my computer to get my tax info, so I don’t use luks’ other stuff.

Auto unlock only happens with a TPM. You couple TPM with encrypted RAM, Secure Boot and tamper-detecting erase. So if they remove the bottom cover, TPM is cleared and you need to enter the recovery key. Encrypted RAM prevents extracting secrets from sleep state. All corporate laptops have these features (and also remote erase / destroy with Intel ME / AMT). A correctly setup system will cover almost all of the attacks in physical nature. Of course they can still find exploits in logon screen. It is good enough security combined with convenience. It is more secure than letting normies (and lazy techies) use 12345678 as the pin.

fwiw, you can enable this on Windows too with a simple command:

https://techdirectarchive.com/2023/10/08/how-to-enable-a-pre...

It isn't enabled by default likely because it makes updates more of a manual process and they decided timely updates were a more important attack surface

BitLocker may also be configured for a password. This attack is very narrow.

Reply on news.ycombinator.com