And what about when a notebook is encrypted? [LWN.net]

And what about when a notebook is encrypted?

Posted Sep 17, 2018 13:11 UTC (Mon) by pbryan (guest, #3438)
Parent article: Fedora reawakens the hibernation debate

When using encryption (incl. swap encryption), I wonder what happens. Writing the entire contents of memory (including volume encryption keys for currently mounted volumes) is not a good idea.

to post comments

And what about when a notebook is encrypted?

Posted Sep 17, 2018 13:44 UTC (Mon) by mageta (subscriber, #89696) [Link] (14 responses)

Encrypt swap as well (on a laptop, something like: one boot-partition (unencrypted) and on big crypt-partition that contains a LVM PV, which contains multiple LVs, of which one is the swap; so you only have to enter one key). You'll need some form of InitRD to handle the decryption of swap (dracut can do this), before the kernel can use it to load the old memory-image, but that actually works reasonable well; tested it myself on my laptop.

And what about when a notebook is encrypted?

Posted Sep 17, 2018 14:20 UTC (Mon) by cesarb (subscriber, #6266) [Link] (8 responses)

> so you only have to enter one key

But you have to enter one key, potentially in public. With suspend-to-RAM you can enter the key once at home and suspend, it won't ask for the key again until it's turned off.

And what about when a notebook is encrypted?

Posted Sep 17, 2018 22:21 UTC (Mon) by ThinkRob (guest, #64513) [Link] (7 responses)

One man's feature is another's bug. At least with suspend to disk you still have to know one key. Suspend-to-RAM makes DMA-enabled attacks trivial (provided you can actually access a DMA-capable port with the machine intact, naturally.)

And what about when a notebook is encrypted?

Posted Sep 18, 2018 12:10 UTC (Tue) by farnz (subscriber, #17727) [Link] (6 responses)

You don't necessarily need the machine to be intact - cold boot attacks work against machines that you've disassembled, as long as the RAM has not lost power for "too long" since the key was last known to be present.

Thus, the truly paranoid disable suspend to RAM - they shut down and power off RAM themselves before letting the machine out of their sight.

And what about when a notebook is encrypted?

Posted Sep 18, 2018 17:53 UTC (Tue) by drag (guest, #31333) [Link] (5 responses)

Well they just run 'shutdown -h now' when they are finished and are going to use their device in a situation were they could lose physical control of it. They only would disable it if they think they could forget about it and want their system to shut off by default to avoid mistakes.

But because of all of this the whole 'having to type key in public situation' is a bit of a red herring. Encrypted drives are only really useful as a security measure when those drives are offline.

And what about when a notebook is encrypted?

Posted Sep 19, 2018 11:26 UTC (Wed) by nix (subscriber, #2304) [Link] (4 responses)

Quite. I'm still wondering about ways to make my encrypted backup drives invulnerable to an untargetted attacker who just decides to blat zeroes over every accessible block device. Is there some way to turn the USB port off, then on again? (It's connected to a hub, and I don't want to turn off the whole hub, so this gets a bit trickier... some way to make the blockdev vanish. I guess a simple rm or mv-out-of-sight-to-somewhere-not-in-/dev and then mknod or mv-back later on would do it, but that feels really disgusting.)

And what about when a notebook is encrypted?

Posted Sep 19, 2018 16:22 UTC (Wed) by zlynx (guest, #2285) [Link] (1 responses)

I was feeling paranoid about ransomware so I created a maze of automount directories with 999h timeouts for device UUIDs that don't exist.

It wouldn't help against direct block access though. Just scripts doing blind directory traversal.

And what about when a notebook is encrypted?

Posted Sep 19, 2018 18:00 UTC (Wed) by nix (subscriber, #2304) [Link]

I defended against *that* by mounting the backups in a separate filesystem namespace in which the backup server-side program (and bup-fsck etc) runs :)

And what about when a notebook is encrypted?

Posted Sep 22, 2018 14:20 UTC (Sat) by wtanksleyjr (subscriber, #74601) [Link] (1 responses)

This kind of attack is what Qubes-OS was designed to mitigate. It's not worth installing if that's the _only_ attack you're worried about, but then I doubt that's the case.

And what about when a notebook is encrypted?

Posted Sep 23, 2018 18:29 UTC (Sun) by nix (subscriber, #2304) [Link]

My impression of Qubes is that it's more or less designed for high-end desktops. Servers that run heaps of virtual machines and also run the backups and do network file storage are... probably not really something Qubes would be good at for other reasons entirely. (Not that I've ever had a machine capable of *running* Qubes.)

And what about when a notebook is encrypted?

Posted Sep 18, 2018 18:40 UTC (Tue) by derobert (subscriber, #89569) [Link] (4 responses)

You don't even need an unencrypted /boot; just Grub. Grub gets updated a lot less frequently than the kernel, so if you need to do something special (e.g., sign it so you can use secure boot with your own keys), much less work.

So you can have:

/dev/sda1 EFI system partition / BIOS boot area (depending on if using EFI boot)
/dev/sda2 LUKS → LVM → /boot, /, swap, etc.

and Grub knows how to ask for the LUKS passphrase, decrypt it, find the LV for / or /boot and load the kernel and initramfs from that. It then boots the initramfs, which can have a keyscript or file on it (since, remember, the initramfs is encrypted) which lets the initramfs open the LUKS volume, set up LVM and (at least on Debian) resume from hibernate to that encrypted swap. This setup does require a little bit of config file editing; Debian-Installer will not set it up for you (mainly, it doesn't know the set the flag in the Grub config to enable LUKS) — other than that, it leaves you with an enter-passphrase-twice setup, then you set up a keyscript or file to fix that.

My experience with hibernation is it just works, though that's on Debian. Which, as noted, uses a different initramfs system.

And what about when a notebook is encrypted?

Posted Sep 23, 2018 22:27 UTC (Sun) by rra (subscriber, #99804) [Link] (3 responses)

> My experience with hibernation is it just works, though that's on Debian. Which, as noted, uses a different initramfs system.

Yeah, same here. I was very surprised by the assertion in the article that hibernate is largely unsupported and unreliable, since it just works for me and has for years on various different laptops. But this is with Debian.

That said, it's good to know that the kernel upstream is focusing primarily on suspend, since I was only using hibernate on a mild general principle of not using up power that I didn't need to use up. Maybe I'll experiment with using suspend instead for a while.

And what about when a notebook is encrypted?

Posted Sep 24, 2018 16:45 UTC (Mon) by cavok (subscriber, #33216) [Link]

I am a very happy user of s2both, provided by swsusp if I'm not wrong. It writes the state to ram and disk. It even warns if you pickup the wrong kernel after a power interruption while suspended-hibernates. It resists to corruption/loss even in case of "different machine" (my Debian 9 lives/suspends/hibernates on an external usb3 ssd).

And what about when a notebook is encrypted?

Posted Sep 24, 2018 22:42 UTC (Mon) by mstone_ (subscriber, #66309) [Link] (1 responses)

it's basically luck of the hardware. it's been years since I successfully hibernated a debian system.

And what about when a notebook is encrypted?

Posted Nov 22, 2018 12:36 UTC (Thu) by m_a_s (guest, #128777) [Link]

Same here. I eventually migrated to Fedora because of this.

And what about when a notebook is encrypted?

Posted Sep 17, 2018 22:27 UTC (Mon) by ThinkRob (guest, #64513) [Link] (3 responses)

For the paranoid (properly, or otherwise) among us, the idea of RAM being written out in whole to disk is a scary one even if it is -- in theory -- done safely. You're only one configuration bug or one non-public exploit away from someone getting a complete memory image.

Plus it -- again in theory -- opens you up to known-plaintext attacks. If you know a box is running $OS_VERSION then you know the contents of a ton of stuff that's going to be in memory. Shared libs alone would give you hundreds of megs of known plaintext on your standard Fedora/GNOME install. And while AES-256 in XTS mode isn't vulnerable to known plaintext attacks at the moment (as far as I know), I would venture a guess that some folks might not want to tempt fate.

Personally the security angle doesn't bother me much, provided Fedora implements it right. My only main concern is that it's bloody useless for me, hence I hope it's made (and stays!) configurable. My laptop loses ≤ 1% of battery when left off overnight, and with some 75+Wh of charge available, this is solving a non-issue... at the cost of a rather annoying wait time when I do want to start using my laptop. So here's hoping that it can be turned off!

And what about when a notebook is encrypted?

Posted Sep 18, 2018 16:01 UTC (Tue) by epa (subscriber, #39769) [Link] (2 responses)

Presumably a known-plaintext attack could be mitigated a bit if you compress the memory dump before writing it to disk. A sliding-window compressor could be seeded with a fairly random initial window, or some small nondeterminism could be added to the construction of frequency tables for Huffman coding. Or do these ideas fall under the category of "please don't roll your own crypto"?

And what about when a notebook is encrypted?

Posted Sep 18, 2018 16:32 UTC (Tue) by hkario (subscriber, #94864) [Link]

CRIME showed that compression is not a workaround for leaky encryption

And what about when a notebook is encrypted?

Posted Sep 21, 2018 16:50 UTC (Fri) by ThinkRob (guest, #64513) [Link]

Or do these ideas fall under the category of "please don't roll your own crypto"?

I'd say so.

There probably are ways to defend against this though. Plus, AFAIK there aren't any significant known plaintext attacks against AES256 in XTS mode. And since this isn't a long-term storage situation but rather a short term one it's not like we have to worry about an exploit twenty years from now putting our data at risk.