Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

mathstodon.xyz

Post reply on HN
Print view View original

131–140 of 247 posts

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

#131

Post by kube-system »

xnickb wrote: post #129
noinsight wrote: post #86

Earlier quoted context omitted.

If you’re at all serious about security and not user convenience, you deploy BitLocker with a PIN instead of TPM only. And then a whole class of vulnerabilities goes away.

If you are at all serious about security you don't consider Windows. Depending on how serious you are you also don't consider MacOS. And then you kinda have a couple of things to chose from but ultimately you need to build your own security depending on your attack/threat model

And then depending on how "serious" you are you also don't consider Linux.

But also, threat models and the best way to mitigate them aren't really a linear scale of being to , but a complex consideration of a particular situation.

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

#132

Post by fpoling »

IngoBlechschmid wrote: post #80
fpoling wrote: post #64

On my laptop with Fedora I just configured Linux to hibernate to disk after 15 minutes of suspend. Powering memory off ensures that bugs like this Debian-specific would not matter. Plus what Debian extension to Linux tooling does although nice in theory, but in practice if one really worries about cold-boot attacks, then all keys and important documents has to be wiped out from memory, not only LUKS keys. So hibernat…

> So hibernating is really the only proper way to protect against cold boot. I agree; or resurrecting FridgeLock: https://www.sec.in.tum.de/i20/publications/fridgelock-preven...

Interesting idea. On the other hand on the latest SSD with hardware encryption the raw disk speed under Linux can be over 5 GB/s so on my laptop with 64 GB of RAM the full restoration from disk takes like 45 seconds. With LUKS it is like 2 times slower. Which is not a problem at all. So I do not see much value in memory encryption in suspend.

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

#133

Post by NooneAtAll3 »

kokada wrote: post #44

While it is certainly an interesting bug, I kinda feel that the title is click bait? Because this `cryptsetup luksSuspend` from what I understood is not really officially supported but an extension done in Debian, so if anything this regression only affected Debian? I am not sure if you can blame the kernel for something that is not supported or even widely tested. I still find this impressive, and it is nice that we…

what debian version first shipped 6.9?

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

#134

Post by Groxx »

IngoBlechschmid wrote: post #14
bitbasher wrote: post #9

I don't see any other way? When you sleep (suspend to RAM), everything is stored in RAM and is encrypted but the master key is present in kernel memory (if I recall correctly). However, if you hibernate (suspend to disk) the entire contents of RAM (including the master key) is written/encrypted to disk and the RAM is cleared. When you wake the machine up you have to re-enter the passphrase to decrypt the master key t…

Yes, if you simply suspend your laptop on most stock Linux distributions, then everything including the master key is still kept in memory. But Debian pioneered the (optional) cryptsetup-suspend addon. This issues a luksSuspend command which is supposed to wipe the key from memory, and on resume asks you to resupply your passphrase. Up to kernel 6.8, this worked as described; starting with kernel 6.9, it silently did…

I've been wondering why hibernate didn't work with encryption, because this seems like the extremely obvious way to handle it, but I have struggled to find anything about it for years - glad to hear it does exist!

But yeah, also rather obviously it's inherently a bit leak-prone. Though it seems probably pretty simple to test, just hibernate and scan all stored data. They could probably even do it on shutdown, as a hash of the key data would be sufficient to detect the key.

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

#135

Post by Groxx »

veeti wrote: post #116
bri3d wrote: post #84

Earlier quoted context omitted.

The issues you linked with BitLocker are obvious properties of BitLocker-with-SecureBoot-only architecture. If you configure Linux that way, you get similar issues (for example, it's pretty easy to mis-configure TPM sealed disk encryption on Linux to still allow a recovery shell, which will run with the disk unsealed). BitLocker with a password (the equivalent of the LUKS configuration in question) does not share the…

Bitlocker with a password has always felt like a second class citizen to me. You have to dig into a bunch of group policies to use it. Maybe most people don't even realize it exists.

Yah, it seems blatantly hostile how much they hide it.

I can understand the default being TPM-only + online key backup, huge amounts of the population forget their login passwords (which can be involuntary, e.g. head injury) and huge amounts of them still want some backup way to access their data rather than losing it forever.

But for anyone who cares just a little more, or would prefer to lose data in those situations, it's such an abnormal and hidden path that it's clearly blocking tons of people from choosing it.

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

#136

Post by Groxx »

andrewpiroli wrote: post #38
nacs wrote: post #32

Earlier quoted context omitted.

Reminder that by using Bitlocker, you're using a closed source encryption for which Microsoft will happily hand out your recovery key on request. https://www.forbes.com/sites/thomasbrewster/2026/01/22/micro...

Only if you store your key with Microsoft, which is not required or the default if you're using a local account which I assume most privacy sensitive people are.

Agreed it's optional (I've seen and used that option), but are local accounts even a thing any more? Or are you just referring to "not MDM controlled" accounts?

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

#137

Post by GordonS »

noinsight wrote: post #86
IngoBlechschmid wrote: post #34

Earlier quoted context omitted.

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

If you’re at all serious about security and not user convenience, you deploy BitLocker with a PIN instead of TPM only. And then a whole class of vulnerabilities goes away.

If you're really serious, you use a strong password, not a PIN.

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

#138

Post by bri3d »

veeti wrote: post #116
bri3d wrote: post #84

Earlier quoted context omitted.

The issues you linked with BitLocker are obvious properties of BitLocker-with-SecureBoot-only architecture. If you configure Linux that way, you get similar issues (for example, it's pretty easy to mis-configure TPM sealed disk encryption on Linux to still allow a recovery shell, which will run with the disk unsealed). BitLocker with a password (the equivalent of the LUKS configuration in question) does not share the…

Bitlocker with a password has always felt like a second class citizen to me. You have to dig into a bunch of group policies to use it. Maybe most people don't even realize it exists.

For the system drive they seem to really strongly prefer PIN, which also doesn't have the problems linked above. I was going to use PIN as my example but didn't want to explain another set of recent BitLocker conspiracy theories yet again; maybe I should have.

It is annoying that they hate password for system drive _so_ much; the reason is actually pretty obvious when you think about how their "happy path" AD-driven enterprise deployment with stupid password rotation requirements works (and FileVault is a nightmare in this scenario), but I wish they'd make it easier for individual power users.

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

#139

Post by deepsun »

hugo1789 wrote: post #130
deepsun wrote: post #110

Earlier quoted context omitted.

"Million eyeballs" argument was always kinda meh.

Maybe but still a little better than closed source like Windows. Everytime whem someone asked me if I could hack my way into his Windows PC I always told "After all it's Windows, how bad can it be?" Doing that since 25 years still waiting for a Windows machine that doesn't open... On the other hand I failed to open about 50% of Apple Devices I was asked to open and about 10% of Linux machines. (Not because Linux is i…

Of course, I'm not saying closed source is better. I'm saying that just because it's open it doesn't mean people really care to read it thoroughly.

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

#140

Post by Terr_ »

solenoid0937 wrote: post #128
noinsight wrote: post #86

Earlier quoted context omitted.

If you’re at all serious about security and not user convenience, you deploy BitLocker with a PIN instead of TPM only. And then a whole class of vulnerabilities goes away.

It's probably all security theater. There's only so much trust you can put into some shitty vendor's TPM implementation

"Disk must be in expected hardware environment" versus "Same environment plus PIN" makes a huge difference if a thief simply steals a whole computer.
Post reply on HN