3 ms·

Bitlocker is disk encryption not ram. Ram encryption like AMD's Secure Memory Encryption (SME), transparent secure memory encryption, and Intel's Total Memory E

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.
- Dylan16807 3y ago
  Limited platforms? Code exploits? 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."
  - cookiengineer 3y ago
    In my first comment I literally mentioned BitLocker, which, as I pointed out correctly, stores its keys either in RAM or on the TPM chip. 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.
    - Dylan16807 3y ago
      > In my first comment I literally mentioned BitLocker, 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.

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.

Dylan16807 3y ago
Limited platforms? Code exploits? 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."
- cookiengineer 3y ago
  In my first comment I literally mentioned BitLocker, which, as I pointed out correctly, stores its keys either in RAM or on the TPM chip. 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.
  - Dylan16807 3y ago
    > In my first comment I literally mentioned BitLocker, 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.