Hacker News Reader

> 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.

[1] https://support.apple.com/guide/security/data-protection-cla...

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.

> The disadvantage is the need of entering (very long) keys manually on boot.

Shameless plug: Mandos solves this problem on Debian (and derivatives): https://www.recompile.se/mandos

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?

Thanks for the heads-up!

> 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.

[0] https://docs.microsoft.com/en-us/windows/security/informatio...

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.

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.

> Nevertheless, if you can put a security coprocessor into the CPU itself

M1 powered Macs do this too. Does Intel or AMD make any chips with a TPM built in?

Isn’t that what Intel PTT is? Basically TPM baked in? Not entirely sure myself but I think PTT did away with the need for a discrete TPM coprocessor.

Ah, sounds like it. Thanks, I wasn’t aware of PTT.

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.

https://www.microsoft.com/security/blog/2020/11/17/meet-the-...