Encrypt disks at suspend to ram

strm · n00b Joined: 26 Dec 2024 Posts: 5

Hello everyone, I have a Gentoo box here with encrypted root and encrypted swap. Suspend to disk ("Hibernate") works and correctly asks for my decryption key on wake up.

However, I'd like to also encrypt the disks when suspending to ram, i. e. when the device wakes up, it should ask for the decryption key.

I know that there exists luksSuspend/luksResume and there are scripts out there like https://github.com/c6fc/ubuntu-lukssuspend.

My question is: Are there any recent solutions to this problem? The content that can be found on the web is rather old and probably needs porting etc.

Would appreciate any hints on this.

[Administrator edit: fixed implicit link. Forum auto-linking considers dots to be part of a URL, but the poster did not intend for a trailing dot to be included in the URL. -Hu]

sublogic

Hu · Administrator Joined: 06 Mar 2007 Posts: 22920

The cryptsetup luksSuspend command that OP referenced is documented to do part of this: freezing access to the device and removing the key from memory. The hard part is that if the suspended device is important (such as /, or /home), then the user program(s) that put the system into suspend need to arrange for themselves to remain functional while the device is frozen, and to get the key back and resume the device without relying on the frozen device. This is theoretically possible, but I wouldn't want to try to have a full working GUI with those limitations. I would switch to a text console, freeze the device, suspend the system, then resume the device and switch back to the graphical environment.

I am not aware of any turnkey solutions that can do what is requested.

eccerr0r · Posted: Thu Jan 02, 2025 2:59 am Post subject:

Are there any windows solutions that do this?
I feel there's a lot of deadlock situations that could occur...imagine needing to pull code from the backing store, whether from swap or disk, in order to present the dialog box for the unlock key. Plus I suspect all apps need to be frozen while the key is being asked so the suspend unfreeze can't occur until after the disk is unlocked else they may try to access the disk and error, and who knows what the behavior of those apps would be if that happens...

The only possibility is if you leave rootfs unencrypted and only work in an encrypted container.

I'm just leaving my suspend as-is for now, if they have to pull the memory and do analysis to retrieve my key then that's what they have to do.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

Hu · Administrator Joined: 06 Mar 2007 Posts: 22920

From the manual:

eccerr0r · Posted: Thu Jan 02, 2025 3:39 am Post subject:

shhh... no more systemd ideas...?
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

strm · n00b Joined: 26 Dec 2024 Posts: 5

Thx for the replies. To clarify: Doing suspend on console is fine with me. As far as I can tell, that is what the script I linked tries to do. I just wanted to make sure I am not reinventing the wheel when I try to make the script working again on a modern system.

sublogic · Posted: Fri Jan 03, 2025 12:30 am Post subject:

The link into github gave me a 404. There is a search box, typing 'lukssuspend' finds it.

Okay, it seems to do what @Hu described, but it is Ubuntu-specific. OP could use as a starting point but will have to modify it for Gentoo. May need to emerge sys-power/acpid and make sure it doesn't conflict with the desktop environment.

But, is it wise? The cryptsetup-lukssuspend man page points out that

Hu · Administrator Joined: 06 Mar 2007 Posts: 22920

Caches could be dropped separately, if that is a concern. Those caches also persist in the more common case where the LUKS device is not suspended, so even if they are allowed to linger, the LUKS-suspended case has stronger security properties than the common case. Whether those security properties are useful is dependent on the threat model.

The GitHub link being dead is because OP included a spurious dot in the URL. I will fix that with an administrative edit.

strm · n00b Joined: 26 Dec 2024 Posts: 5

thx Hu. Also note: I think with an encrypted swap, caches should not be that much of a security issue. Also the security level I try to reach here is "a random notebook thief cannot access the data". It does not need to be NSA proof.

zen_desu · Tux's lil' helper Joined: 25 Oct 2024 Posts: 92

If that's the case, I imagine plain disk encryption and it asking for a user password when it wakes up should be enough.
_________________
µgRD dev
Wiki writer