Hacker News Reader

Comment by tchebb | Hacker News Reader

Surely Windows keeps the FVEK in RAM regardless of whether the TPM requires a PIN to initially obtain it. Otherwise, wouldn't you need to enter your PIN every time a block from the disk needs decrypting? Not to mention the performance impact of calling the TPM on every disk operation.

This attack reads the key from RAM, so I don't see how a TPM PIN would mitigate it.

View on HN

The point is that the TPM PIN prevents the attack if the system is powered off when the attacker obtains it.

If the TPM doesn't have a PIN, this attack works even if the attacker obtains the system when it's powered off. They can start the computer, proceed to the Windows logon screen (that they can't get past and that hence prevents them from exfiltrating data from the running system), then just reset the computer and perform this attack to obtain the encryption key. This obviously doesn't work if the PIN prevents Windows from ever even starting.

I know this is besides the point, but still kinda relevant:

Even on Win11 it's still possible to do the old utilman (or other suitable module) replacement hack from Windows repair (trigger by interrupting boot), from there you can change account passwords at will.

You can't change something on an encrypted volume without knowing the encryption key

I think Windows repair prompts for an admin login and the bitlocker key before allowing you to proceed. Assuming the windows install is intact enough to read the security sam.

> the old utilman (or other suitable module) replacement hack from Windows repair (trigger by interrupting boot),

Can you elaborate on this?

Correct, unless you're using a self-encrypting drive the FVEK sits in RAM once it's been released by the TPM during boot. The TPM is only a root of trust; for fast crypto operations without keeping the key in kernel memory you would need something like Intel SGX or ARM TrustZone.

BitLocker no longer leverages SED by default due to vulnerabilities in drive manufactures firmware as of Sept 2019.

> Changes the default setting for BitLocker when encrypting a self-encrypting hard drive. Now, the default is to use software encryption for newly encrypted drives. For existing drives, the type of encryption will not change.

https://support.microsoft.com/en-us/topic/september-24-2019-...

https://nvd.nist.gov/vuln/detail/CVE-2018-12037

Holy crap.

https://threadreaderapp.com/thread/1059435094421712896.html

This is amazing.

> The encrypted SSD has a master password that’s set to “”

HN discussion here: https://news.ycombinator.com/item?id=18382975

Original paper here: https://cs.ru.nl/~cmeijer/publications/Self_Encrypting_Decep...

If you can short the reset pins while the computer is running and make it restart without losing power, then yes, I agree. But if you have to shut down to make your modifications, then you won't get past the PIN prompt.

Why? It means you'll only get one shot at the attack, but nothing here is intrinsically prevented by using a TPM PIN (or even a non-TPM password, the attack doesn't depend on TPM-based Bitlocker in any way other than if the target machine is powered off or your first attempt fails)

I wouldn't underestimate that a PIN prevents this attack on machines that are powered off.

You can then go further up the chain with a UEFI settings password and no usb booting. If the password is hard to decrypt, then that's a pretty good approach.

Then there's custom Secure Boot certificates that replaces the ones from MS. It'll work for Linux, not sure about BitLocker. But my Surface tablet doesn't even support custom sb certs.

It might make it super hard to do an a laptop where you can't usually force reset easily from the power button.

Having said that a number of laptops can still be opened without being powered-off if you do it carefully.

Reply on news.ycombinator.com