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

And what about when a notebook is encrypted?

Posted Sep 17, 2018 14:20 UTC (Mon) by cesarb (subscriber, #6266)
In reply to: And what about when a notebook is encrypted? by mageta
Parent article: Fedora reawakens the hibernation debate

> 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.

to post comments

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.)