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.
There are two approaches to full disk encryption. The first one is the traditional approach: The encryption is applied independently from the operating system. The key is controlled by the user. The system cannot even boot without the correct key because the underlying hard drive is inaccessible. The disadvantage is the need of entering (very long) keys manually on boot.
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.
> This authentication exploit bypasses the login screen despite BitLocker, so it's technically a BitLocker bypass
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.
Thanks for just saving me a few hours of trying to decrypt an old hard drive with a corrupted Bitlocker that doesn't take the password anymore.
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).
Apple devices (both Mac and iOS) use something in between those two approaches. To oversimplify a bit, they store a record on disk that contains the full-disk encryption key, encrypted with the user account password on macOS, or passcode on iOS. So the password serves as both an OS authentication mechanism and the equivalent of a BitLocker password.
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.
About terminology: in security engineering and cryptography, encryption methods and key management are considered different things[1]. Here in both cases the encryption method is equally secure. But the security of the system depends on of the key management method (or keying, for short).
Encryption is necessary, but not sufficient, to have secure .
[1] And then there's integrity, replay protection, nonreprudiation, forward security.. etc other properties.
Heavy bitlocker user here, and up until now assumed the first approach is what's going on; how do I verify which system is used, and switch to the former in a few words?
Do you need to type a disk encryption password into a Bitlocker-branded screen before Windows boots? Or alternatively are you required to insert a specific USB stick with a key file?
If so, you are using one of the more secure configurations. If not, you are using the less secure (TPM-only) configuration.
> how do I verify which system is used, and switch to the former in a few words?
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.
If you have auto-unlock on your system disk, then by the time you get to the login prompt the key from TPM was already read and used to decrypt your disk. Any sort of auto-unlock is inherently less secure.
Two months ago, Microsoft announced the Pluton security processor and that future AMD, Intel, Qualcomm CPUs will have it. It seems to be for this exact purpose:
> 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.
Agreed, it is wrong to describe this as a Bitlocker bypass. From what I can see it is actually a Windows lock screen bypass and also privilege escalation vulnerability.
Also this bypasses the protection offered by Bitlocker (in the typical ‘keys are stored in the TPM’ setup) as it grants access to the system from the login screen without entering a password.
So if you steal a laptop you can get at the drive contents using this trick.
There's less need to jump through all these hoops if you have physical access to a PC with enabled USB ports. For example: you could boot from the USB device and access the local storage if it's not encrypted.
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.
But this article is about bypassing Bitlocker, so that's not relevant. Also, if a system is unencrypted there are a multitude of ways to easily read the contents. That goes for any device or operating system.
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.