[IngoBlechschmid]

Exactly. Cryptsetup wouldn't know about the extra copy of the volume key in kernel memory. Which is why, dramatically, it appeared secure ("surely I wouldn't be asked to resupply the passphrase if the volume key is still in memory, right?").

[pedrocr]

It was still more secure than the default if I understand this correctly. On resume from suspend the laptop would still be locked by the encryption key and without access to the disk even if you can somehow circumvent the lock. The only insecurity was that somewhere in the kernel memory the key still exists so if you can somehow extract that from the live system you can unlock it.

[IngoBlechschmid]

Yes, you are right: LUKS encryption protests your data at rest. An attacker which steals your disk can only gain little, like the information that you have used LUKS (unless you put your LUKS headers elsewhere, separated from the disk) and perhaps disk and disk sector usage statistics.

[Guvante]

You need to get quite specific on actual attacks to call this insecure to be clear.

Having access to the raw RAM of a machine suspended but demanding the key to resume is certainly possible but the number of attacks where you don't need this bug is "almost all of them" given at that point if the machine ever unlocks you won in this hypothetical attack even with a bug fix.

[comex]

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 user data in RAM. But it’s not quite as bad as having the disk key, which gives the attacker all the data plus the future ability to decrypt or modify user data given only the physical disk. (Still, a better solution would be encrypting the hibernation image, preventing this attack entirely.)

2 is fully bad, but in many plausible scenarios (e.g. seized device) the attacker cannot just return the device to the user without them knowing something happened. Or even if they can, the method of RAM access may be one where reads are much more practical than writes, such as cold boot attacks involving physically swapping out the RAM.

[XorNot]

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 remote access, a core problem is you can't quickly wipe a Yubikey in your possession - and while they're fragile in daily use, they're also surprisingly hard to intentionally destroy quickly.

[ethbr1]

> "pull pin to destroy"

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

[Guvante]

You need to only have the ability to execute code after the hibernation not before and the machine needs to be permanently unavailable to the user after.

As I said quite rare situations.

If you can read this kind of data you have the ability to run code which means you already owned the entire operating system making capturing the key next entry beyond trivial.

You don't need to spoof anything, we assume here you can read the key from RAM remember.

If you could execute code before hibernation you similarly already had the key.

[bawolff]

I mean, isn't the threat model here that the attacker has stolen your device? That is about the only thing full disk encryption is good for.

[Terr_]

It also prevents the addition of content onto the disk, providing tamper-protection in addition to secrecy.

For example, spyware/remote-control software would open new routes to penetrate your employer's systems, or steal money from your bank account, bypassing other security measures like an additional layer of encryption on your password mode, or 2FA.

Even a relatively unsophisticated foe could connect your hard drive, dump incriminating data on it to frame you, put it back, and then call the authorities with a tip.

[Guvante]

You are generally guarding against the device being shutdown.

Anything assuming the OS is running is already into "well that is easy" territory since if the OS is running those keys are in the same place as this attack leverages.