First what is BitLocker
BitLocker is a logical volume encryption feature included with Microsoft Windows (Pro and Enterprise/Education versions) starting with Windows Vista. It is designed to protect data by providing encryption for entire volumes. On older versions of windows like vista and 7 this feature can only work with a TPM-Chip.
So Why not BitLocker
First and foremost, BitLocker is proprietary software that was never publicly audited created by a company that falls under US law hence has to obey National security letters, see the Lavabit case for an example how that can play out.
Encryption software of any kind should there for be always open source, that is not a guarantee for it being secure, as with the cases of Heartbleed and Apples GotoFail, but being open source is a necessary precondition for it to be able to be considered secure at all.
BitLocker does not really care for security
As shown by the cases below Microsoft in the past did not show the necessary due diligence when developing BitLocker, leaving users to be easily compromised. BitLocker is clearly a product for enterprises designed to be easily manageable at the expense of security. It provides a commercially accepted solution to delegate the responsibility for customer data protection to “someone else”. It is not suitable to protect sensitive personal data, or confidential trade secrets, from a skilled or resourceful adversary.
Case #1 - Self-encrypting deception
Starting with windows 8 (and server 2012) BitLocker got a feature, which is enabled by default, that allows the cryptographic operations of BitLocker encryption to be offloaded to the storage device\'s hardware.
However, Microsoft did not care to audit the various Self-Encrypting Drives (SEDs) hence leaving millions of its users with practically no security what’s o ever. As at the CCC in December of 2018 during the talk Self-encrypting deception independent security researchers have demonstrated live on stage how to bypass the hardware encryption of many SSD models using a ~20€ µC programmer/debugger. Demonstrating that for the past 6 years users of BitLocker and such drives were entirely compromised and did not even knew it. To alleviate this issue the user would have to know about it and use a Groupe Policy to disable this feature. It took Microsoft until late 2019 to change the preset and by default no longer trust SEDs.
Case #2 - TPMs can’t be trusted
By default, Microsoft BitLocker is using the Trusted Platform Module (TPM), to manage the keys, if one is present. Sound’s good until you realize that you can sniff the LPC bus and extract the volume master key, now isn’t that handy.
The issue with TPM’s gets a bit more complicated, modern PC’s often no longer come with a dedicated hardware TPM, instead this feature is being provided by the chipset. So, no exposed LPC bus to connect the sniffer to, one my think, but the reality strikes again. The TPM functionality is nowadays implemented as a firmware module in the Intel Management Engine (ME) or the AMD Platform Security Processor respectively.
And the Intel ME already showed in the past gaping security holes, there is a nice talk about that at the 33c3 and HITBSecConf2017 and of cause 36c3. There is also a Proof Of Concept on Git Hub: https://github.com/ptresearch/IntelTXE-PoC
The issue here is, like before, Microsoft putting blind trust in the hardware vendors, and is not telling it to the user. The correct approached would be to present all the options to the user and provide information about the potential risks.
Given that hardware implementations of encryption are typically yet another black box you can blindly trust, but should not, a reasonable argument is to be made that software-based implementations should by default be preferred.
Case #3 - For your expedience BitLocker can be temporarily suspend
BitLocker in Windows 10 can be configured to store the encryption keys in “the clear” this allows you among other things “Restarting the computer for maintenance without requiring user input”, “Turning off (disabling) or clearing the TPM…”, “Moving a BitLocker-protected drive to another computer…”, etc… so what this feature does is to store a encryption key in plaintext on the drive itself.
Yes, a secret key that is supposed to ensure your security is write in plaintext i.e. unencrypted to the very same disk drive it is supposed to protect, all for your expedience.
Modern SSD’s use something called wear leveling to prolong the life of your SSD, what it does is when writing to the drive the SSD intelligently remaps sectors in the background to spread the wear and tear more equally among all of them. The operating system is not aware of this operation hence on an SSD you can never definitely overwrite a sector, as your write attempt can be redirected to a less used one transparently. Not even the overwriting of the entire SSD can guarantee data to be overwritten as modern SSD’s use overprovisioning to improve performance. The overprovisioned sectors can be accessed by an attacker eider by a firmware hack or by removing the flash chips and reading them out one by one using appropriate hardware.
Now this feature is not only an option for users that don’t care, but in fact used by windows during automatically installed Feature Upgrades.
BitLocker uploades your recovery keys to the cloud without asking
If you are using windows 10 with a Microsoft account windows will “save” your BitLocker recovery keys in your Microsoft account. This is done automatically and without an option to opt out, as described here now granted if you care about your privacy you shouldn’t use a Microsoft account at all, but the mere existence of this option is a huge red flag and a threat in itself.
Who guarantees that windows wont “miss interpreted” an unconfigured policy or setting, or just the absence of a configured account and trigger the cloud backup of your most precious secret key “accidently”?
Microsoft is already maintaining some sort of “shadow accounts” for machines which are not using a Microsoft account linked to the activation data and maintaining the app history as reported on by the borncity blog.
But what about windows
One may ask: If I don’t trust MSFT with making BitLocker secure or even assume they may have added a backdoor, isn’t everything lost anyways for every tool that runs under MSFT Windows anyways?
Windows itself could indeed just extract any cryptographic keys from 3rd party tools from Memory and send it to Redmond, but this is highly unlikely to be implemented. A backdoor by a large company must be implemented such that it being intentional can always be plausibly denied, it must look like a programming error.
Therefor an obvious backdoor in Windows, like intentionally sending keys from a 3rd party encryption tool to MSFT, is highly unlikely as this could be found out, especially if it happens on every windows system and, could not be plausibly denied by MSFT.
One deniable channel of attack could be to intentionally crash the system with an update, grab the kernel crash dump and arrange things for it to likely include the sought for keys. But than if you value your privacy you should have disabled error reporting and probably system crash dump creation altogether anyways. Also, MSFT is not in the business of crashing their user’s PC’s on purpose it is extremely unlikely that would role something like that out to all their users. And if you are interesting enough for a targeted effort, you should indeed switch to a self-compiled Linux ASAP.