131–140 of 151 posts
Bitlocker is the Windows one, that's essentially known to be compromised, right? Not saying that it's useless, might be fine for certain work environments, but I wouldn't rely on it for anything truly personal.
Earlier quoted context omitted.
I’d say that as soon as Windows fully boots up, you have a much larger attack surface anyway, even if you can’t log in due to the account password. Though I can’t point at anything specific off the top of my head.
Only DMA comes to mind but it requires a non-hardened configuration which isn't that common on recent laptops + OS.
But I still can’t get over the idea where the default configuration of BitLocker is completely useless for basically anything except working around storage devices that will lie to you and not erase things you told them to. I just refuse to accept that’s in any way sane.
This is a non-issue for me, as I use LUKS2 (the recent version of LUKS which is much better). If I need to use Windows, for whatever reason, I jail Windows in a VM typically to use certain software that has no Linux equivalent. I don't trust Bitlocker. Read somewhere Bruce Schneier uses Bitlocker for his daily computing, but I still don't trust it. After all, this is Microsoft we're talking about, who are in cahoots…
I think that it takes significant leaps of logic, yeah even with pervasive F/OSS, that non-US intelligence is somehow weaker or less interested than US-based ones. In fact, your typical Linux supply chain and SBOM is far, far more complex than anything Windows can serve up. There are so many juicy opportunities in there.
> using a fTPM would solve the problem. All TPMs support encrypted sessions to prevent these kind of MITM attacks. You use TPM2_StartAuthSession and specify encryption with each session command. But Bitlocker doesn't use one, which is epic fail. Microsoft need to fix it. Edit: For comparison, systemd uses encrypted sessions when using LUKS disk encryption with the TPM https://github.com/systemd/systemd/commit/acbb504…
I wonder if that oversight is intentional and what would be the reason for it.
This is a non-issue for me, as I use LUKS2 (the recent version of LUKS which is much better). If I need to use Windows, for whatever reason, I jail Windows in a VM typically to use certain software that has no Linux equivalent. I don't trust Bitlocker. Read somewhere Bruce Schneier uses Bitlocker for his daily computing, but I still don't trust it. After all, this is Microsoft we're talking about, who are in cahoots…
Even Fedora (which I think is in the better shape than most) does not set that up by default and the only tutorials I found require you to manually reconfigure TPM on every kernel update.
There's nothing new in this. The default configuration doesn't require a PIN but the Microsoft documentation explains the various attacks and recommends setting a Bitlocker PIN which completely prevents this. The PIN can be quite weak because the TPM prevents brute forcing. See eg https://learn.microsoft.com/en-us/windows/security/operating...
Another write up from 2021 https://arstechnica.com/gadgets/2021/08/how-to-go-from-stole... One aspect of this is that some laptop manufacturers provide a setting to erase the TPM if the laptop is opened. You opened that laptop to see if you can add more RAM? Better hope you can access the bitlocker key or have a good backup.
It’s good practice to have a copy of the recovery key somewhere.
Earlier quoted context omitted.
> The vulnerability also applies to other encryption systems using the TPM, like LUKS disk encryption. No, this is a Bitlocker problem. Systemd LUKS disk encryption uses encryption on the bus by enabling TPM encrypted sessions: https://github.com/systemd/systemd/commit/acbb504eaf1be51572...
I stand corrected, I'm glad systemd finally implemented encrypted TPM communication. I really don't understand why Microsoft is still allowing their keys to be MITM'd. I really should switch from Grub to systemd but the lack of boot time configuration (and, slightly less importantly, theming support) still makes me prefer Grub.
systemd would be vulnerable to MITM, but you don't MITM the SPI bus with some $100 hobbyist tooling.