Can we reliably "forget" the contents of what's in RAM by powering-off and letting some encryption key somewhere fade from a smaller, more volatile piece of memory? I'm curious what has been done to mitigate cold-boot attacks in RAM. What has changed in hardware? Are the keys to encrypt contents of RAM kept in the TPM or something?
Encrypting what's in RAM would possibly add some additional protection but realistically if things are done right what's left in RAM will probably be only marginally more interesting than what you can see over the wire; at most I'd expect you could see a tiny amount of active request data. That's just a guess, though.
Does this prevent rootkits?
> but realistically if things are done right what's left in RAM will probably be only marginally more interesting
That's the idea. If the OS is immutable, where do you put them?
Bootkits require further mitigation to prevent, but Mullvad has also put effort into that, too, with their secure coreboot bootchain.
Of course as an end-user you still can't really fully validate a machine over the network has not been tampered with, so you're obviously ultimately still trusting Mullvad as you'd expect.
> See: https://en.wikipedia.org/wiki/Cold_boot_attack
Yes, that's what I'm referring to. I don't expect that there would be a significant amount of requests in RAM, probably just remnants of mainly what was active (and some de-allocated but not cleared remnants?) when the machine was reset.
They would be in the PXE image. There was one time I flubbed on this actually. I had to change export options on our PXE servers to fix something and I forgot to change it back adding my poor excuse of multitasking and being lazy. This was in a Dev environment we also used PXE in production believe it or not. A developer sitting across from me said he changed something in the image by mistake and I said, "That's not possi... oh crap." It was cool of them to call it out right away. Attackers probably won't be so kind.
https://mullvad.net/en/blog/2022/1/12/diskless-infrastructur...
secure boot, as painful it is to get right, doesn't help when the vendor runs its own things with elevated privileges, like they are known to do: https://news.ycombinator.com/item?id=34085635
Doubly so, when the said things are not only closed source but vulnerable themselves: https://archive.is/6ClWm
Does coreboot help in mitigating vuln in privilged vendor blobs?
Mitigating the risk of Intel ME is obviously something that is complicated. The "state of the art" so-to-speak is really just rendering it non-functional. This isn't strictly related to Coreboot; that said, Coreboot has a page about ME:
https://www.coreboot.org/Intel_Management_Engine
And in general, when you're running Coreboot, you're running significantly less privileged blackbox blobs (possibly none in some rare cases), and in general, the surface area of Coreboot is going to be dramatically tinier than any typical UEFI system firmware. So it's absolutely worth it in that regard.
There's never going to be a "perfect" option here with how complex things have gotten, but I think that you can at least say that Mullvad has taken almost any reasonable step, and perhaps a few steps that are beyond what many would consider reasonable, towards developing effective mitigation of the risks of rootkits, bootkits and malicious/unwanted vendor code running on their "diskless" architecture.
Of course, you still have to trust Mullvad. Trust is definitely a meaty human-y experience, and the cold rational part of our brain craves some kind of technically-bulletproof way to prove that it's truly safe, secure, and private, but that's just not possible. Best you can do is layer enough assurances on top of each-other in a way that at least some layers are completely independent of others for maintaining your operational security. Far easier said than done, and obviously how rigorously one approaches this will vary on paranoia.
At some point you have to pick your middle-ground I suppose.
Wait why would this be a bad thing?
https://www.amd.com/system/files/documents/amd-memory-guard-...
https://www.amd.com/content/dam/amd/en/documents/epyc-busine...
No. At least not reliably, due to how the keys are stored in RAM as well (e.g. when in standby mode, or when a laptop lid is just closed).
There's even an EFI reboot flag that could fix this and force-clears the RAM on next boot, but it's usually deactivated.
[1] https://en.wikipedia.org/wiki/Cold_boot_attack (works still on Windows, thanks to BitLocker)
[2] https://www.usenix.org/legacy/event/sec08/tech/full_papers/h...
Bitlocker does not store the keys in the CPU, otherwise a coldboot attack while literally transplanting the physical memory rows to a different machine wouldn't work. And it does.
In case you are confusing CPU with a TPM chip, which can optionally store the master volume key but only for activated full disk encryption:
With TPM you can easily bypass that, too, with tools that can read the i2c bus. See here [1]
Any non-ridiculous RAM encryption will keep the key in the CPU. And since the key only needs to last for one boot, it never needs to leave the chip. If there's hardware in the memory controller doing the encryption it can be designed so that key export is impossible.
Game consoles have been using RAM encryption for over a decade. It's one of the reasons consoles are much harder to attack nowadays.
First: Only Ryzen PRO or EPYC models support it, which kind of kicks out all mobile or laptop systems already. Then, only Zen3 CPUs work, because previous generations have a boot freeze bug, which wasn't fixed and upstream linux 5.15 as a result disabled the mem encrypt flag by default.
Second: Before you switch topic to SEV, that's only supported for EPYC models, see here [2]
Regarding attacks: At least AMD had an injection attack problem where SEV in EPYC 7xxx and 3xxx processors was confirmed to be affected without AMD confirming the vulnerability (yet...). It was a master thesis iirc from a guy in luebeck.
There are also known sidechannel attacks which void RAM encryption in practice, like Hertzbleed which used frequency scaling to decrypt ECDSA and PIKE SIDH (which is meanwhile known to be unsecure, at least for PIKE). [3]
Google also did an audit on Intel's TDX where they found bugs in loop boundaries, off by one errors and similar feasible attack methods (which haven't been published as a PoC yet, so I grant you that). [4]
So I would still argue that with these very narrow set of available processors (Intel Pro 13th generation for TME and EPYC 7xxx that have both SME and SEV) is highly limited in its availability and also not available for laptop hardware due to them being server CPUs.
Additionally there's been a lot of attack surfaces that have been proven to have access to SME or SEV stored keys in the CPU and there have been other sidechannel attacks which conceptionally are very unlikely to be fixed anytime soon.
So I would still argue that memory encryption in practice is unreliable.
[1] https://lists.freedesktop.org/archives/amd-gfx/2021-October/...
[2] https://github.com/AMDESE/AMDSEV/issues/1
[3] https://www.hertzbleed.com/
[4] https://services.google.com/fh/files/misc/intel_tdx_-_full_r...
Edit: found the AMD injection attack thesis:
[01] https://www.its.uni-luebeck.de/fileadmin/files/theses/MA_Luc...
Another attack on SEV, which was confirmed by others since the USENIX conference. Both of the techniques rely heavily on pattern matching to find the decryption oracles though, and around 16 bytes for their OpenSSH demonstrations.
[02] https://www.its.uni-luebeck.de/fileadmin/files/theses/MA_Luc...
I'm gonna ignore the game consoles statement because that's a specialized set of CPUs which will never land in any laptop anytime soon. Most of them are AMD, so I'd refer to the same articles anyways.
These are a perfectly good way to back up the first half of your original statement, "No. At least not reliably"
But "due to how the keys are stored in RAM" is not true. And that's the part that got objected to.
You're not being nitpicked on a technicality here. You mixed up the techs you were talking about in a way that makes a significant difference. Bringing in all these references might be useful to people, but you could have just said "oh, I meant disk encryption by that part" instead of getting sassy and doubling down on saying incorrect things with "Did you read any of my referenced links? You cannot state this when the paper and well known attack methods disprove your statement."
If you gonna rip apart my comment into parts without context, at least do it with all parts.
Note that I didn't start the discussion about where the key is stored, someone replied to my initial comment - in the context of BitLocker - saying that the CPU stores the key, which is incorrect.
My initial point was not about how secure enclaves work in practice. Though I argued that most implemented follow-up technologies don't work reliably due to how the OS always interfaces with unpatchable firmware bugs.
While I agree this is the only way to fix the coldboot attack problem I don't see the technology as reliable as of today, and I don't understand why you think I am wrong with that statement?
If you don't agree: show papers with counter measures, and how to prevent the exploits and bypasses.
You did mention bitlocker. But it was unrelated to RAM encryption, and you acted like it was related.
Everything you said about bitlocker was true, but the way you brought up bitlocker was itself the problem.
> someone replied to my initial comment - in the context of BitLocker
No they did not. Your answer did not make a new separate context for just bitlocker. You muddled bitlocker and RAM encryption. They replied in the original context, because you said that RAM encryption stores the key in RAM during standby.
Whether you intended to say that or not, it's what you said. Go back and read the original comments. You directly said that line about RAM encryption, not just disk encryption.
"> > As a naive outsider: Does RAM in 2023 encrypt all its contents?"
"> No. At least not reliably, due to how the keys are stored in RAM as well (e.g. when in standby mode, or when a laptop lid is just closed)."
> I don't see the technology as reliable as of today, and I don't understand why you think I am wrong with that statement?
I never said you were wrong about that.
Granted, I should have formulated it probably differently and specifically differed between secure enclaves, memory encryption and full disk encryption problems to be more clear about it.
https://www.intel.com/content/www/us/en/developer/articles/n...
Looks like AMD has an equivalent:
https://www.tomshardware.com/news/intel-mktme-amd-memory-enc...
I wish there were a sort of checklist that prints out in dmesg saying "Your RAM is encrypted: (check) Your machine has these mitigations against cold-boot attacks: ...some list here... (check, check, check)"
In some contexts, I love how far we've come with secure boot, attestation, speculative execution mitigations, etc. but it's very difficult for the average Linux user to understand what they should expect for hardware security, and then work toward enabling all of it.
I love what Gnome did in the last year in Settings -> Device Security:
https://www.phoronix.com/news/Ubuntu-No-GNOME-Device-Securit...
There's a detailed list here of what it's looking for:
https://forums.debian.net/viewtopic.php?t=152705
Not a fan of all the bound-to-Intel technologies. I wish the concept of what's being secured were identified, then made available in dmesg or through some /sys or /proc interface.
Intel is only now catching up.
[ 0.338594] Memory Encryption Features active: AMD SME