5 ms·

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

> 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.
    - cookiengineer 3y ago
      See my sibling comment.
  - Cody-99 3y ago
    Bitlocker is disk encryption not ram. Ram encryption like AMD's Secure Memory Encryption (SME), transparent secure memory encryption, and Intel's Total Memory Encryption (TME) all store the encryption key used to encrypt the RAM inside the CPU. The encryption key never leaves the CPU so it can't be read from RAM via cold boot attack. As far as I know no attacks have been shown to expose this key (which is changed on every reboot). Game consoles have been using RAM encryption for over a decade. It's one of the reasons consoles are much harder to attack nowadays.
    - cookiengineer 3y ago
      Okay, if we are narrowing the topic now to AMD's SME/SEV and Intel's TME/TDX, I'll bite, too. 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/069868.html https://lists.freedesktop.org/archives/amd-gfx/2021-October/... [2] https://github.com/AMDESE/AMDSEV/issues/1 https://github.com/AMDESE/AMDSEV/issues/1 [3] https://www.hertzbleed.com/ https://www.hertzbleed.com/ [4] https://services.google.com/fh/files/misc/intel_tdx_-_full_report_041423.pdf 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_LucaWilke_InjectionAttacksOnSEV.pdf 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_LucaWilke_InjectionAttacksOnSEV.pdf 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.

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.
  - cookiengineer 3y ago
    See my sibling comment.
- Cody-99 3y ago
  Bitlocker is disk encryption not ram. Ram encryption like AMD's Secure Memory Encryption (SME), transparent secure memory encryption, and Intel's Total Memory Encryption (TME) all store the encryption key used to encrypt the RAM inside the CPU. The encryption key never leaves the CPU so it can't be read from RAM via cold boot attack. As far as I know no attacks have been shown to expose this key (which is changed on every reboot). Game consoles have been using RAM encryption for over a decade. It's one of the reasons consoles are much harder to attack nowadays.
  - cookiengineer 3y ago
    Okay, if we are narrowing the topic now to AMD's SME/SEV and Intel's TME/TDX, I'll bite, too. 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/069868.html https://lists.freedesktop.org/archives/amd-gfx/2021-October/... [2] https://github.com/AMDESE/AMDSEV/issues/1 https://github.com/AMDESE/AMDSEV/issues/1 [3] https://www.hertzbleed.com/ https://www.hertzbleed.com/ [4] https://services.google.com/fh/files/misc/intel_tdx_-_full_report_041423.pdf 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_LucaWilke_InjectionAttacksOnSEV.pdf 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_LucaWilke_InjectionAttacksOnSEV.pdf 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.