alt Hacker NewsI 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.
Replies
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.
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.