What does this have to do with Bitlocker?
EDIT: i get it now, it plays a small part in the exploit chain because it doesn't correctly verify what it sets permissions on when automounting usb drives.
EDIT: i get it now, it plays a small part in the exploit chain because it doesn't correctly verify what it sets permissions on when automounting usb drives.
The second approach, which is popular on phones and tablets, is to use disk encryption transparently, usually with hardware assistance. On boot, the key is automatically filled in by hardware (TPM for BitLocker) when some conditions are met, no passphrase is asked. In this case, the disk encryption employed is not really a "true" encryption [0], instead, it's an extension of operating system's authentication mechanism. BitLocker's sole purpose is to prevent anyone from bypassing the login screen by pulling out the hard drive, rewriting the password, and putting the hard drive back in. It's also why smartphones can be reasonably secure even with a 4-digit PIN.
This authentication exploit bypasses the login screen despite BitLocker, so it's technically a BitLocker bypass, although it doesn't break any crypto.
BitLocker can be configured to use either the first approach or the second approach. The second approach is used on many systems by default. As the exploit has shown, if you have serious security requirements, using the first approach is more secure (but do remember to shut down the computer often).
[0] For example, in case of TPM, the BitLocker key can also be physically extracted on boot using a logic analyzer to monitor the communication between the host and TPM... Nevertheless, if you can put a security coprocessor into the CPU itself, it can be reasonably secure since key extraction is really difficult, some smartphone's encryption (e.g. iPhone) uses this method.
Thanks for the heads-up!
Check whether you are using pre-boot authentication. BitLocker offers true encryption only if pre-boot authentication is used. Here's a tutorial: https://www.howtogeek.com/262720/how-to-enable-a-pre-boot-bi... More information on BitLocker's implementation details and its threat model can be found in Microsoft's documentation [0].
> On computers with a compatible TPM, operating system drives that are BitLocker-protected can be unlocked in four ways:
> TPM-only. Using TPM-only validation does not require any interaction with the user to unlock and provide access to the drive. If the TPM validation succeeds, the user sign in experience is the same as a standard logon.
> TPM with startup key. In addition to the protection that the TPM-only provides, part of the encryption key is stored on a USB flash drive, referred to as a startup key. Data on the encrypted volume cannot be accessed without the startup key.
> TPM with PIN. In addition to the protection that the TPM provides, BitLocker requires that the user enter a PIN. Data on the encrypted volume cannot be accessed without entering the PIN.
> TPM with startup key and PIN. In addition to the core component protection that the TPM-only provides, part of the encryption key is stored on a USB flash drive, and a PIN is required to authenticate the user to the TPM.
TPM-only is the default option, it's better than no security, but arguably insecure (depending on your threat model). TPM with PIN or startup key offers true encryption, they are not vulnerable to this category of attacks. But clearly, using a user-supplied key or PIN has its own disadvantage (which is why TPM-only mode was invented in the first place).
> On the other hand, Pre-boot authentication prompts can be inconvenient to users. In addition, users who forget their PIN or lose their startup key are denied access to their data until they can contact their organization’s support team to obtain a recovery key. Pre-boot authentication can also make it more difficult to update unattended desktops and remotely administered servers because a PIN needs to be entered when a computer reboots or resumes from hibernation.
[0] https://docs.microsoft.com/en-us/windows/security/informatio...
If so, you are using one of the more secure configurations. If not, you are using the less secure (TPM-only) configuration.
Encryption is necessary, but not sufficient, to have secure .
[1] And then there's integrity, replay protection, nonreprudiation, forward security.. etc other properties.
No. No, it is not. Let me give a similar example: lets say the drive requires a PIN and i ask the user to enter the PIN, then i still get to the starting conditions of this article.
Technically i could argue it now includes a social engineering variant of a bitlocker bypass, but it should be very obvious there is no actual bypass, only an "assume it is open" precondition. The article has an "assume the device is configured in a way that i can walk right past bitlocker to the lockscreen" and then calls it "Bypassing BitLocker in 6 easy steps". No, just no. Not technically, not theoretically, just no.
Not to be unfair to the author, the lockscreen bypass is clever and teaches a lot about defensive coding. It is a good finding. But the article gets dragged down by the sensationalist title, because the content is not what it says it is.
The title indeed reads like it can break/bypass Bitlocker encryption, but it actually doesn't do that at all.
As far as I know Bitlocker encryption can still not be cracked/hacked/decrypted/bypassed without the proper credentials (password/PIN/USB key/48-digit recovery key).
M1 powered Macs do this too. Does Intel or AMD make any chips with a TPM built in?
> These sophisticated attack techniques target the communication channel between the CPU and TPM, which is typically a bus interface. (...) The Pluton design removes the potential for that communication channel to be attacked by building security directly into the CPU.
https://www.microsoft.com/security/blog/2020/11/17/meet-the-...
Shameless plug: Mandos solves this problem on Debian (and derivatives): https://www.recompile.se/mandos
As a result, it's not vulnerable to this type of attack: even if you get code execution on the login screen, you can't decrypt the user's data without their password. (If there are multiple users, any user's password will work.)
Traditionally, this meant that if you enabled FileVault on Mac, the first login screen you'd see when booting was actually part of the EFI firmware rather than the OS itself. It couldn't boot the OS until it knew some user's password in order to decrypt the main partition. On iOS, and on macOS as of Big Sur, the immutable OS is separated from user data, so the login screen is part of the OS proper.
Caveats:
- On macOS, this only protects the first login screen. Once you log in, the key stays in memory until the system shuts down, even if you log out or change users. On iOS, some files are like that, but other files are encrypted under a different key which is thrown away whenever the device is locked. [1] Hopefully that comes to macOS in the future.
- If you're using a weak password, such as the default six-digit passcodes on iOS (there's an option to use a stronger password), it would be trivial to brute force the password, so security effectively degrades to what you call the second approach. The security coprocessor will limit the maximum number of attempts, so attacks like this one won't work, but if you compromise the coprocessor then it's game over. And people have.
[1] https://support.apple.com/guide/security/data-protection-cla...
So if you steal a laptop you can get at the drive contents using this trick.
EDIT: I meant to say "if you have physical access without Bitlocker enabled". Bitlocker is protecting the contents of the storage, if you can bypass the lockscreen on a Bitlocker protected computer you've evaded this protection.