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

221–230 of 247 posts

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

#221

Post by naikrovek »

LtWorf wrote: post #191
naikrovek wrote: post #158

Earlier quoted context omitted.

If you think for one single second that businesses and governments who rely on a lost disk being secure don’t trust bitlocker, I have oceanfront property in Missouri to sell you. Bitlocker + PIN is as secure as anything. A vulnerability can’t leak your key if the TPM doesn’t know the entire key and relies on the user to supply the missing parts of the key in the form of a PIN.

https://www.techspot.com/news/112410-security-researcher-mic...

BitLocker with pin is not vulnerable to that (or any other) attack.

10 points deducted. Try again.

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

#222

Post by kokada »

IngoBlechschmid wrote: post #67
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…

Sorry, aimed for a technically precise title and didn't want to bait clicks. Yes, this does not affect people on stock configurations for the plain reason that they wouldn't expect the volume key to be safe during suspend anyway. Debian's solution was ported to several (most?) other distributions and I guess quite a few people maintained private ports. The thread-keyring(7) manpage promises: "A thread keyring is dest…

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 clear that this is a special case that you need both the correct patches plus the correct setup to use `cryptsetup luksSuspend` in place of the normal suspend.

Can I ask one question? Why not use hibernation at that point? The reason I generally suspend to RAM is exactly because my password is long and annoying to type enough that if I know I am going to use the device soon I prefer to suspend instead of hibernation. Yes, technically resuming from suspend is faster, but it is also less secure (there are other interesting things in memory besides the LUKS keys) and also it uses more power.

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

#223

Post by cyphar »

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…

I'm confused why you're saying this is a Debian-specific thing -- luksSuspend is upstream and was added back in 2009[1] in release v1.1.0[2]. I've used it (though somewhat sparingly) on Arch and openSUSE in the past and it definitely exists on non-Debian distributions. Maybe you're thinking of the automatic integration with system suspend? If so, that's kind of besides the point -- luksSuspend documents itself as clearing the keys from system memory, which stopped happening in Linux 6.9 due to the referenced refactor patch.

Though it should be noted that it seems that this is actually a bug in cryptsetup in that it was depending on very specific lifetime behaviour of kernel keyring keys, when it arguably should've been more explicitly cleared by userspace[3].

[1]: https://gitlab.com/cryptsetup/cryptsetup/-/commit/3cea5dcc7b... [2]: https://gitlab.com/cryptsetup/cryptsetup/-/blob/main/docs/v1... [3]: https://gitlab.com/cryptsetup/cryptsetup/-/merge_requests/93...

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

#224

Post by reirob »

Groxx wrote: post #134
IngoBlechschmid wrote: post #14

Earlier quoted context omitted.

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 ha…

For me it works and I use it all the time. I hibernate with:

sudo systemctl hibernate -i

And when waking up it requests the LUKS passowrd. Using NixOS, worked since 2019 or so.

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

#225

Post by cyphar »

kokada wrote: post #222
IngoBlechschmid wrote: post #67

Earlier quoted context omitted.

Sorry, aimed for a technically precise title and didn't want to bait clicks. Yes, this does not affect people on stock configurations for the plain reason that they wouldn't expect the volume key to be safe during suspend anyway. Debian's solution was ported to several (most?) other distributions and I guess quite a few people maintained private ports. The thread-keyring(7) manpage promises: "A thread keyring is dest…

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 patched version of Windows under secure boot).

This doesn't matter for custom kernels but most official distro kernels are built this way to be signed, as otherwise they won't Just Work (TM) on modern laptops. If you disable secure boot then hibernation works again, though I must admit I'm a little surprised how many people seem to disable secure boot.

[1]: https://www.man7.org/linux/man-pages/man7/kernel_lockdown.7.... [2]: https://github.com/rhboot/shim-review#how-does-your-signed-k...

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

#226

Post by john_strinlai »

dijit wrote: post #219
john_strinlai wrote: post #91

Earlier quoted context omitted.

> If you use your key every day you tend not to forget it. hoping users don’t forget their password is a very weak policy. specifically, the policy and admin points you brought up above, how does veracrypt solve them?

We're sort of talking about two things and conflating them. I'm sort of talking about my user experience of the system, and I'm getting it in the neck from helpdesk. Enterprise rollouts are different from anything I actually deliver, despite pushing out thousands of windows servers: I have complete control over those. Same as my local PC. But as a user on a PC I'd buy from a store, I'm not going to forget my password…

>We're sort of talking about two things and conflating them. [...] But as a user on a PC I'd buy from a store

i said multiple times that i was talking about a managed fleet in an enterprise environment, and even specifically said that i dont typically recommend bitlocker for personal use, so i am not really sure what to say here. i was really clear.

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

#227

Post by assbuttbuttass »

cyphar wrote: post #225
kokada wrote: 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…

> 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

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

#228

Post by ethbr1 »

XorNot wrote: post #188
comex wrote: post #171

Earlier quoted context omitted.

I don’t know about “almost all”. If the key has been purged but you can read RAM, then you can do two things: 1. You can extract whatever user data happens to be in RAM. 2. If you can either write RAM or reboot into your own OS, and then return the device to the unsuspecting user who will put in their password, then you can run a fake password dialog and get everything. 1 is bad, since there may be quite a lot of use…

The seized device scenario is starting to get very specific though: in the actual cases it's relevant like the Silk Road take down the device was intercepted while open. It's of some frustration to me that more security devices don't have a "pull pin to destroy" function available in them for this reason if you have any type of threat model where this applies: e.g. when I thought about using a Yubikey to secure remot…

> "pull pin to destroy"

Insert old joke about folks rigging a packet of thermite with an igniter over their hard drive.

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

#229

Post by john_strinlai »

LtWorf wrote: post #216
john_strinlai wrote: post #202

Earlier quoted context omitted.

veracrypt does not include a remote backup system

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.

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

#230

Post by IngoBlechschmid »

kokada wrote: post #222
IngoBlechschmid wrote: post #67

Earlier quoted context omitted.

Sorry, aimed for a technically precise title and didn't want to bait clicks. Yes, this does not affect people on stock configurations for the plain reason that they wouldn't expect the volume key to be safe during suspend anyway. Debian's solution was ported to several (most?) other distributions and I guess quite a few people maintained private ports. The thread-keyring(7) manpage promises: "A thread keyring is dest…

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?

The sibling post by cyphar gives a good reason; while UEFI Secure Boot has its own share of issues, it can be a valuable ingredient in defending against evil maid attacks.

But another reason is... convenience. Resuming from RAM is faster than resuming from disk, especially so if your "disk" is actually just a USB flash drive. I know that it might be a bit weird to ask for convenience when the motivation is security. But I argue that there are use cases where the tradeoff is sound.

With hibernation, all your data is safe but the inconvenience might seduce you not to use it.

With suspend to RAM and your distro's version of cryptsetup-suspend (and the kernel patch or alternatively the cryptsetup workaround), only your volume key (and hence the bulk of your data, potentially terabytes worth of sensitive information) is safe, but sensitive data in memory (recent files, recent chat messages, session cookies, ...) is not. But on the other hand it's quick.

Some people use a combination: suspend to RAM for short breaks, where they expect to remain physically able to fully switch off the laptop when something happens; and suspend to disk for longer breaks.

It all depends on your threat model.

Post reply on HN