Reading HowTo: Change your LUKS disk encryption password, I thought a bit about password security and so on, and actually the weakest point in full-disk encryption using luks is when your device is suspended (suspend to RAM). I personally suspend my laptop a lot, and only reboot like once a week.
Some distros (debian, arch) have a package called cryptsetup-suspend, which locks the luks volume before suspending to RAM. That makes a lot of sense because retrieving a key from RAM of suspended PC isn’t all that difficult.
Has anyone experimented with cryptsetup luksSuspend ... in Fedora?
me too. I may install debian12 in a VM and try this out.
I think systemd-homed solves this issue by locking your home-dir container, as lennart writes in the issue. Anything I care about is in /home/user, my / has nothing sensitive afaik.
In order to encrypt swap, you would need to either always keep the necessary tools for decrypting in RAM, or have some other read-only system containing it, that is not encrypted.
Oh no that’s not what I’m asking (or remember) The Key would have to go to swap/memory to decrypt the drive waking from suspend. The request would be large since LUKS2 uses argon2idand is like 1GB ? There are technical hurdles here is what I was asking. Memory fails me on this topic, asking for a refresher is all.
Under the link I posted above, they mention this as one of their technical challenges:
Memory management: Memory management is definitely a challenge. Unlocking disks might require a lot of memory (if key derivation function is argon2i) and the swap device most likely is locked at that time. See section All that matters to me is the memories! below for details.
So to summarize what I said above and the info from the link provided,
One of the tricky parts is memory management. Since version 2, LUKS uses argon2i as default key derivation function. Argon2i is a memory-hard hash function and LUKS2 assigns the minimum of half of your systems memory or 1 GB to unlocking your device. While this is usually unproblematic during system boot - there’s not much in the system memory anyway - it can become problematic when suspending.
When cryptsetup tries to unlock a device and wants 1 GB of memory for this, but everything is already occupied by your browser and video player, there’s only two options what to do:
Kill a process to free some memory Move some of the data from memory to swap space
The first option is certainly not what you expect when suspending your system. The second option is impossible, because swap is located on your harddrive which we have locked before. Our current solution is to allocate the memory after freezing the other processes, but before locking the disks. At this time, the system can still move data to swap, but it won’t be accessed anymore. We then release the memory just in time for cryptsetup to claim it again. The implementation of this is still subject to change.
I think it is helpful for readers (such as those reading the referenced HowTo by @boredsquirrel) to understand the different levels of security risks in each specific use case, given that, as @augenauf mentions, there are lots of laptop users (myself included) who often just close the lid (suspend-to-ram) when carrying around the laptop:
you have no real security on one end, when internal storage media is left unencrypted;
you have low security risks on the other end, with full-disk encrpyption, strong password mesures, and system is always shut down;
there are some security risks with encryption measures taken, but system is suspended instead of shut down, and a theft occurs.
So what are those risks with suspended-to-ram[1] systems? I suppose that:
if there is an “opportunity” theft, then your data is probably safe, as the gain is usually in the hardware
if there is a “targeted” theft, the target being your data (a less likely scenario for regular users), then there are chances your data can be accessed. How high are those chances? Does password strength help in such a situation (probably not)?
Coming closer to the topic, I have looked at how other OSes deal with this scenario, and it seems that the hardware component takes a role in providing additional layer of security. Macs have this solved with the so called secure enclave, as described in this external post.
