Live data from Hacker News

Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory

mathstodon.xyz

241–247 of 247 posts

Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory

#241
post #225

Earlier quoted context omitted.

> Can I ask one question? Why not use hibernation at that point? Not GP but hibernation is completely disabled for lockdown kernels[1], which is always enabled when booting under secure boot for kernels trusted by the Microsoft secure boot keys (it is considered a requirement to get you shim signed by rhboot[2] as it is believed that Microsoft considers it a hard requirement, as otherwise you could chain-load a patch…

> I must admit I'm a little surprised how many people seem to disable secure boot. To me, secure boot is the setting that I need to remember to turn off before installing the OS, but I would be willing to be convinced otherwise

To be fair the security argument for secure boot is weakened by the fact that everything is signed by the same set of trusted keys when using the default Microsoft trust root, but on paper it does protect against certain kinds of attacks. (In theory, distros could use UEFI setup mode to only trust their own keys but this causes issues with signed firmware and there have been cases of bricked devices.)

Even if you use full disk encryption, without secure boot someone can replace your kernel (or bootloader to inject a bad kernel) with one that is backdoored without you noticing. So someone only needs temporary access to your powered off laptop to gain access to your data once you use it again. I've had my devices taken away from me at airports and I know people who have had their laptops mysteriously missing screws when travelling overseas, so this is not an entirely hypothetical problem.

Of course, the fact that hibernation doesn't work on Linux is a negative from a practical security perspective, and so stuff like luksSuspend on suspend end up being quite important. And trusting the Microsoft keys is a little concerning if you're worried about state actors.

If you use TPM-backed keys with tools like systemd-pcrlock you can get some similar (and arguably nicer) protections but in practice nobody locks to enough PCRs to provide more protection than you would get if you also enabled secure boot.

Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory

#242
post #216

Earlier quoted context omitted.

Of the work, not of the encryption.

we're talking about veracrypt vs. bitlocker in a managed enterprise environment. whether there are backups or whatever else is irrelevant because it would be true in both the veracrypt and the bitlocker scenario.

We are talking about IT policies. I don't know what YOU think we're talking about.

Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory

#243
post #225
post #222

Earlier quoted context omitted.

Thanks for the explanation, I am really not that familiar with `cryptsetup luksSuspend` and it is the first time I ever heard it exists. Like other people in this thread I first got confused "wait, how would this work since if you cleanup the keys from the disk during suspend you couldn't access the disk anymore after resuming", but after reading your thread in Mastodon plus other comments here it eventually became c…

> Can I ask one question? Why not use hibernation at that point? Not GP but hibernation is completely disabled for lockdown kernels[1], which is always enabled when booting under secure boot for kernels trusted by the Microsoft secure boot keys (it is considered a requirement to get you shim signed by rhboot[2] as it is believed that Microsoft considers it a hard requirement, as otherwise you could chain-load a patch…

> Not GP but hibernation is completely disabled for lockdown kernels[1]

The manpage that you linked says that unencrypted hibernation/suspend is disabled, but this seems a bad idea anyway if you're using FDE.

Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory

#244
post #243
post #225

Earlier quoted context omitted.

> Can I ask one question? Why not use hibernation at that point? Not GP but hibernation is completely disabled for lockdown kernels[1], which is always enabled when booting under secure boot for kernels trusted by the Microsoft secure boot keys (it is considered a requirement to get you shim signed by rhboot[2] as it is believed that Microsoft considers it a hard requirement, as otherwise you could chain-load a patch…

> Not GP but hibernation is completely disabled for lockdown kernels[1] The manpage that you linked says that unencrypted hibernation/suspend is disabled, but this seems a bad idea anyway if you're using FDE.

The man page does say that but there is no mechanism to actually make use of that at the moment.

It's not enough for it to be encrypted, it needs to be encrypted with a single-purpose key that is not known by the user. Otherwise the user could replace the hibernation image with a malicious one and chain-load a backdoored version of Windows in secure boot mode, which violates the security model that Windows has and Linux needs to uphold to continue to get signed by Microsoft.

It is my understanding that there is work on generating a non-exportable single-purpose key using the TPM to make this work, but that's still a WIP.

Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory

#245
post #239

Earlier quoted context omitted.

BitLocker with pin is not vulnerable to that (or any other) attack. 10 points deducted. Try again.

> or any other last famous words? :D

I appreciate your desire to shit on Microsoft for everything they’ve ever done, but they got BitLocker with PIN right.

Explain how an exploit can decrypt the drive without the portion of the key that the user must enter. The computer doesn’t know the entire key, and can’t decrypt the drive without it, or the recovery key. This is why BitLocker with PIN hasn’t been defeated yet. I don’t understand how it could ever be defeated without entering the PIN.

Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory

#246
post #244
post #243

Earlier quoted context omitted.

> Not GP but hibernation is completely disabled for lockdown kernels[1] The manpage that you linked says that unencrypted hibernation/suspend is disabled, but this seems a bad idea anyway if you're using FDE.

The man page does say that but there is no mechanism to actually make use of that at the moment. It's not enough for it to be encrypted, it needs to be encrypted with a single-purpose key that is not known by the user. Otherwise the user could replace the hibernation image with a malicious one and chain-load a backdoored version of Windows in secure boot mode, which violates the security model that Windows has and Li…

> which violates the security model that Windows has and Linux needs to uphold to continue to get signed by Microsoft.

Oh ok, thanks for clarifying why this is a thing.

Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory

#247

Earlier quoted context omitted.

It absolutely is and they have most the enterprise market.

Okay, yes, sure. It definitely is the most-used encryption software for Windows. But I would never trust it a second, being proprietary and known for issues. You likely know that, but for the benefit of others: 38C3 - Windows BitLocker: Screwed without a Screwdriver https://media.ccc.de/v/38c3-windows-bitlocker-screwed-withou... https://www.youtube.com/watch?v=5eNtT2p12cM

>But I would never trust it a second, being proprietary and known for issues

While true if you don't trust the proprietary encryption you shouldn't trust the proprietary OS either. I think bitlocker backdoor or bugs should be the least of your concerns when the OS is literally known for covertly exfiltrating data to the cloud.

Post reply on HN