5 ms·

As a naive outsider: Does RAM in 2023 encrypt all its contents? Can we reliably "forget" the contents of what's in RAM by powering-off and letting some encrypt

As a naive outsider: Does RAM in 2023 encrypt all its contents? 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?

josephcsible 3y ago
Isn't that what Intel TME does?
- throwaway914 3y ago
  That does look like it: https://www.intel.com/content/www/us/en/developer/articles/news/runtime-encryption-of-memory-with-intel-tme-mk.html 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-encryption,39467.html 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-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 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.
  - adrian_b 3y ago
    AMD Epyc servers have offered encrypted memory for many years. Intel is only now catching up.
  - matja 3y ago
    I have an AMD CPU and I get in my kernel logs during boot: [ 0.338594] Memory Encryption Features active: AMD SME
    - throwaway914 3y ago
      I mean like a checklist of security capabilities that are enabled/disabled, all grouped together in dmesg. That is cool though, it does help
jchw 3y ago
In this case I think the point of running from RAM is that there isn't non-volatile storage. Of course, someone who has physically compromised the server could do potentially bad things, but this makes it harder to e.g. persistently compromise a server, since it doesn't have storage to store malware on persistently, or e.g. accidentally or intentionally log data, since there is no local storage to log it on. 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.
- ignoramous 3y ago
  > since it doesn't have storage to store malware on persistently, or e.g. accidentally or intentionally log data, since there is no local storage to log it on. Does this prevent rootkits? > but realistically if things are done right what's left in RAM will probably be only marginally more interesting See: https://en.wikipedia.org/wiki/Cold_boot_attack https://en.wikipedia.org/wiki/Cold_boot_attack
  - jchw 3y ago
    > Does this prevet rootkits? 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 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.
    - LinuxBender 3y ago
      That's the idea. If the OS is immutable, where do you put them? 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.
cookiengineer 3y ago
> 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). 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 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/halderman/halderman.pdf https://www.usenix.org/legacy/event/sec08/tech/full_papers/h...
- rwmj 3y ago
  This isn't correct - the key is stored inside the CPU.
  - cookiengineer 3y ago
    Did you read any of my referenced links? You cannot state this when the paper and well known attack methods disprove your statement. 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] [1] https://blog.scrt.ch/2021/11/15/tpm-sniffing/ https://blog.scrt.ch/2021/11/15/tpm-sniffing/
    - Dylan16807 3y ago
      Bitlocker isn't RAM encryption, so I don't see how that proves your point. Those are attack methods for typical disk encryption when no RAM encryption is involved. 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.
tredre3 3y ago
AMD offers RAM encryption on their threadripper server CPUs and also in their Ryzen PRO on workstation/laptops (you have to enable it in the bios). https://www.amd.com/system/files/documents/amd-memory-guard-white-paper.pdf https://www.amd.com/system/files/documents/amd-memory-guard-... https://www.amd.com/content/dam/amd/en/documents/epyc-business-docs/white-papers/memory-encryption-white-paper.pdf https://www.amd.com/content/dam/amd/en/documents/epyc-busine...
- latchkey 3y ago
  Years ago, I went to AMD and saw this demonstrated live by engineers there. They spun up a VM with it turned off and you could basically grep a string out of ram. Turning it on, grep returned nothing. It was pretty cool. Developed by a bunch of true grey beards over the course of many years.
- Cody-99 3y ago
  On consumer Ryzen chips you can enable it too if your motherboard supports it. Like error correction code (ECC) support on consumer chips it isn't "officially" supported but it works. I know MSI and ASUS (IIRC) have the option in bios for transparent memory encryption.

josephcsible 3y ago

Isn't that what Intel TME does?

throwaway914 3y ago
That does look like it: https://www.intel.com/content/www/us/en/developer/articles/news/runtime-encryption-of-memory-with-intel-tme-mk.html 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-encryption,39467.html 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-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 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.
- adrian_b 3y ago
  AMD Epyc servers have offered encrypted memory for many years. Intel is only now catching up.
- matja 3y ago
  I have an AMD CPU and I get in my kernel logs during boot: [ 0.338594] Memory Encryption Features active: AMD SME
  - throwaway914 3y ago
    I mean like a checklist of security capabilities that are enabled/disabled, all grouped together in dmesg. That is cool though, it does help

jchw 3y ago

In this case I think the point of running from RAM is that there isn't non-volatile storage. Of course, someone who has physically compromised the server could do potentially bad things, but this makes it harder to e.g. persistently compromise a server, since it doesn't have storage to store malware on persistently, or e.g. accidentally or intentionally log data, since there is no local storage to log it on. 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.

ignoramous 3y ago
> since it doesn't have storage to store malware on persistently, or e.g. accidentally or intentionally log data, since there is no local storage to log it on. Does this prevent rootkits? > but realistically if things are done right what's left in RAM will probably be only marginally more interesting See: https://en.wikipedia.org/wiki/Cold_boot_attack https://en.wikipedia.org/wiki/Cold_boot_attack
- jchw 3y ago
  > Does this prevet rootkits? 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 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.
  - LinuxBender 3y ago
    That's the idea. If the OS is immutable, where do you put them? 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.

cookiengineer 3y ago

> 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). 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 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/halderman/halderman.pdf https://www.usenix.org/legacy/event/sec08/tech/full_papers/h...

rwmj 3y ago
This isn't correct - the key is stored inside the CPU.
- cookiengineer 3y ago
  Did you read any of my referenced links? You cannot state this when the paper and well known attack methods disprove your statement. 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] [1] https://blog.scrt.ch/2021/11/15/tpm-sniffing/ https://blog.scrt.ch/2021/11/15/tpm-sniffing/
  - Dylan16807 3y ago
    Bitlocker isn't RAM encryption, so I don't see how that proves your point. Those are attack methods for typical disk encryption when no RAM encryption is involved. 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.

tredre3 3y ago

AMD offers RAM encryption on their threadripper server CPUs and also in their Ryzen PRO on workstation/laptops (you have to enable it in the bios). https://www.amd.com/system/files/documents/amd-memory-guard-white-paper.pdf https://www.amd.com/system/files/documents/amd-memory-guard-... https://www.amd.com/content/dam/amd/en/documents/epyc-business-docs/white-papers/memory-encryption-white-paper.pdf https://www.amd.com/content/dam/amd/en/documents/epyc-busine...

latchkey 3y ago
Years ago, I went to AMD and saw this demonstrated live by engineers there. They spun up a VM with it turned off and you could basically grep a string out of ram. Turning it on, grep returned nothing. It was pretty cool. Developed by a bunch of true grey beards over the course of many years.
Cody-99 3y ago
On consumer Ryzen chips you can enable it too if your motherboard supports it. Like error correction code (ECC) support on consumer chips it isn't "officially" supported but it works. I know MSI and ASUS (IIRC) have the option in bios for transparent memory encryption.