I did not know that BitLocker relies on hardware encryption if the SSD has support for it. That seems like an extremely dangerous default to have, especially as the implementation is closed source in most (all?) cases.
But bitlocker itself is closed source. Why do you trust microsoft more than the disk vendor? Further, if I were going to choose an opaque blob to trust I would choose the one that has the smaller attack surface.
Whether or not Microsoft can be trusted is not relevant. It's just very surprising to me that Microsoft itself blindly trusts disk vendors, instead of using their own encryption layer on top.
Ahh. I would guess that they aren't blindly trusting them. Given Microsoft's historical relationships with hardware vendors I would bet they have at least partially audited the firmware.
Yeah, I can imagine they'd conduct audits for firmware on the hardware they ship with their own products. I doubt they look at much beyond that though.
Because Windows due to its attack surface is much better researched and understood, Microsoft actually has a decent track record of investing in security and it can be patched.
The attack surface of windows is many orders of magnitude larger and also includes the attack surface of the CPU itself. It is _much_ easier to do a good job securing simple firmware.
You are looking it wrong, when the computer is on the attack surface of hardware or software encryption is the same, if the OS is compromised or any other major part like your CPU the hacker has everything.
When the computer is off the software has zero attack surface so your only attack surface is a cold boot attack against the computer in which case it doesn't really matter if it's HW or SW encryption as long as the keys are in the TPM or an offline attack.
With an offline attack the attack surface of a HW encryption that might also store a copy of the key encrypted or not is now greater.
Also the attack surface alone is only a small part of the risk metric, how easy it is to fix it is just if not more important than how likely it is to have a vulnerability and a firmware not to mention controller level flaws in the cheapest SoC with AES encryption the SSD vendor could find is a much much harder thing to fix than a software solution.
TLDR; if someone would compromise your OS then your data is compromised anyhow, for what FDE supposed to protect against that is unauthorized access when the device is out of your control and off then the software stack does not pose a greater attack surface.
Literally the only case in which the "software" solution might be more vulnerable is when your device is suspended with the key in memory which means that you can attempt memory extraction through physical means (e.g. freezing it and transferring it to a reader before the charge fades), in which case there is no guarantee that the HDD solution would be any better, nor is there any guarantee that you don't hold the copy of the key in memory regardless of what mode is used.
If the device is simply locked then the HDD is in an unlocked mode anyhow if they can unlock your OS through some sort of an exploit then HW or SW they still get your data.
Because historically, hardware vendors have had pretty bad security, and are usually not getting reviewed. There's also many of them, which makes any specific one less likely to undergo review.
Meanwhile, BitLocker has received at least some level of review, it is the most common disk encryption product for Windows, and Microsoft can be reasonably expected, based on past experience, to put somewhat competent people on it.
Additionally, at least for parts of BitLocker, there is at least high-level documentation how it is supposed to behave (e.g. https://docs.microsoft.com/en-us/windows/security/informatio..., there may be more detailed documentation elsewhere), plus there is likely reverse-engineered research available confirming the basic functionality.
It's a very difficult process to turn on and isn't something that happens automatically. You must flip the bit using the SSD manufacturer's tool, reinstall Windows, and then enable BitLocker. Even then, it only works with a handful of SATA SSDs and maybe 2 NVMe SSDs with 1 or 2 motherboards.
I knew something was fishy when I enabled Bitlocker on an OPAL compliant SSD and it took a few minutes to encrypt it. OPAL drives are supposed to be encrypted by default, and I expected Bitlocker to use that, but it didn't. If only one specific set of hardware is needed, why bother?
In case it hasn't been obvious by now, BitLocker has been designed to be compatible with law enforcement requests. That means for one that the vast majority of Windows users will never see it work by default on their machines, as you can see encryption on Android and iOS devices. And second, most of those that do enable it, will be relegated to the broken and/or backdoored encryption of the OEMs.
Thirdly, BitLocker itself may have a backdoor, or at the very least Microsoft continues to design it in such a way that they (and law enforcement have or can get your private key for it, when needed). I remember a while ago people were complaining that BitLocker keys are automatically saved to their OneDrive account, where Microsoft of course can see it.
Also, GFD, there's yet another policy that has to be set to force things to be configured correctly since it literally doesn't ask (or even warn me that it's defaulting to assuming hardware encryption is desired)...
Bitlocker probably uses hardware encryption if the CPU supports it, or maybe (unlikely) an encryption card. The implementation is closed-source and I don’t know if it is documented but there also is an open-source implementation:
reply