Comment by aiscoming
12 hours ago
its pretty obvious you have no idea how bitlocker works, and its various modes - TPM only, TPM+PIN, PIN only
12 hours ago
its pretty obvious you have no idea how bitlocker works, and its various modes - TPM only, TPM+PIN, PIN only
> its pretty obvious you have no idea how bitlocker works, and its various modes - TPM only, TPM+PIN, PIN only
How could anybody besides a Microsoft employee, given the appearance of this bypass technique?
Linux can decrypt BitLocker-encrypted drives. The cryptography is known and solid. The issue is that, as 'aiscoming says, its surroundings in Windows make the quality of the cryptography irrelevant.
In the default BitLocker configuration, Windows puts all the key material in the TPM, locked behind the usual trusted-boot stuff: known-good BIOS hashes the bootloader and tells the TPM, bootloader hashes the kernel and tells the TPM, kernel hashes the initial process and tells the TPM, (I’m not sure how far it goes in this specific application,) and at the end of it the TPM won’t release the keys unless the entire chain was correct. This process does (modulo TPM flaws) ensure the disk will only be decryptable when in the original computer running the original OS. It does not ensure that the original OS will not subsequently give a root shell to anyone who walks up to the keyboard and types in a cheat code, and that’s essentially what’s happening here.
Celebrite et al. take a similar approach: after your Android phone boots and you first enter your PIN (which, unlike with BitLocker defaults, is required to unlock the TPM, thus the distinguished status of “before first unlock” aka BFU vs “after first unlock” aka AFU), the key material is already in RAM and breaking dm-crypt is not necessary; all that’s needed is find a USB stack vulnerability or a Bluetooth stack vulnerability or whatnot that can be leveraged into a root shell.
Note that Microsoft did take the “Linux can decrypt drives in TPM-only” scenario into account. If any UEFI settings are changed related to stuff like boot order, the computer is supposed to see that the settings have changed and require the recovery password to unlock the volume. Knowing the quality of vendor firmware implementation, I’m not sure how well this works in practice.
Agreed that the default Bitlocker config is much less secure than having a PIN at boot time due to the amount of code that gets run.