I'm reading about Intel's Total Memory Encryption and it's not entirely clear to me what function it serves. I understand drive encryption - someone steals your drive or, depending on how you configured it, the entire chassis, and it doesn't matter.

But while with some liquid nitrogen you could preserve the state of a DIMM and inspect it that seems farfetched. The operating system ostensibly doesn't see the encrypted memory - or it has to be decrypted on the fly. Plus the kernel is already keeping application space separate. Is it protecting an application from dumping another application's memory? If so, how does that work as the processor itself would be told to read the memory and it would ostensibly just decrypt it just as a SED drive is decrypted.

It is unclear to me from what type of attacks TME is protecting the memory.


In addition to the accepted answer I think @user71659's comment does a good job of explaining the commercial incentive for why it is worth protecting from a physical attack:

Physical attacks on the front-side bus to intercept memory traffic have occurred. Specifically, the original Xbox was broken this way, which is actually the origin of the feature. IBM implemented it for the Xbox 360, and AMD had already built SME for the Xbox One/PS4.

  • It sounds like properly configured DMA buffers can be left unencrypted, while a bus master would have no hope of making sense of the rest of memory.
    – Ben Voigt
    Commented Nov 7, 2022 at 16:08
  • "that seems farfetched" - and yet, it was done, yes? Commented Nov 7, 2022 at 23:22
  • The whole premise of this question is that it's "farfetched," yet this video and paper shows recovery of multiple disk encryption keys with nothing more than a can of electronics freeze spray and software.
    – user71659
    Commented Nov 8, 2022 at 8:01
  • @user71659 I think your Xbox explanation below was pretty cool. Working at a vendor myself, I can tell you that my original logic was that if I had come up with this feature and pitched it entirely as a datacenter security feature, I think the response would have been, "By the time someone can walk into your datacenter, open the racks, open a server, freeze the RAM, and then walk out with it, without issue, you have other, much larger, problems." Subsequently, it didn't seem commercially likely it was developed for this purpose alone. The Xbox explanation makes sense though. Commented Nov 8, 2022 at 13:57
  • 1
    @GrantCurell You have no evidence of what the spend is. Encryption in SSDs is basically free, they have to scramble the data anyway to avoid coherent bit patterns (i.e. long strings of 1s and 0s), so they just chose AES and rigged up a key interface. Data scrambling in RAM is already needed to guard against not just Rowhammer, but induced noise and regulatory EMI emissions, so just choose a cryptographic scrambler (AES) and rig up rekeying.
    – user71659
    Commented Nov 8, 2022 at 21:26

2 Answers 2


Memory encryption can protect against physical attacks that exfiltrate data. The CPU and the RAM modules communicate over a bus on the motherboard. Unlike delidding the CPU and attaching probes to nanometer-scale features, tapping into this data bus is comparatively feasible. This would allow the attacker to read memory contents, which may contain secrets such as encryption keys.

|   CPU    |    memory bus       +-----+
| (secure) | <=================> | RAM |
+----------+         ^           +-----+

OS-level protections such as virtual memory spaces are not sufficient for protection. Virtual memory makes it possible to prevent one process from accessing another process's virtual memory space, but it can't prevent access directly to the electric circuits.

While I'm not aware of such physical attacks on the memory bus, similar attacks on the bus between the CPU and an external TPM chip are well documented (Pulse Security, 2019). There has also been (unsubstantiated) concern over the inclusion of spy chips in some motherboards (summary from The Register, 2021).

Interaction of Intel TME with DMA/IOMMU: IO devices such as PCIe cards can access memory “directly”, that is, by bypassing the operating system. However, the MMU is still part of the CPU, so that Intel TME will transparently decrypt the memory for direct memory accesses. The main protection here is that the OS/hypervisor can configure the IOMMU to allow DMA only to specified memory regions.

Interaction of Intel TME with virtualization: by default, there is no interaction – TME works transparently to the operating system/hypervisor. However, Intel also offers a Multi-Key TME variant, where the keys are managed by software. This would allow a VM to encrypt its memory so that the hypervisor cannot read it, assuming that the key could first be deployed securely on the system (this is out of scope for TME-MK).

The most technical description of TME/TME-MK I could find is the Intel® Architecture Memory Encryption Technologies Specification, Revision 1.4, Aug 2022 (permalink).

  • "such attacks on the memory bus".... like Fireware bus masters being abused to access all of memory?
    – Ben Voigt
    Commented Nov 7, 2022 at 16:02
  • I don't know that this makes sense to me or at least I have doubts of the possibility of such an attack. With memory, plus memory interleaving, it isn't sufficient to tap any single point, you would have to tap all memory channels and then reassemble the data. I'm not sure how you would do the reassembly because with interleaving it would be effectively scrambled. Perfectly understandable to the processor/OS, but without the knowledge of where things reside in physical memory you would just see nonsense. It seems unlikely intel would design a feature for this. Commented Nov 7, 2022 at 16:22
  • 2
    @BenVoigt excellent point about DMA attacks. But since Intel TME works transparently, I don't think it prevents Firewire style DMA attacks. The appropriate mitigation against such attacks is disabling DMA in the BIOS or configuring IOMMU. Physical attacks like tapping into the circuits of the memory bus are unrelated, and are also weaker since I'd assume such a tap to only work as a passive attack.
    – amon
    Commented Nov 7, 2022 at 20:26
  • 5
    Physical attacks on the front-side bus to intercept memory traffic have occurred. Specifically, the original Xbox was broken this way, which is actually the origin of the feature. IBM implemented it for the Xbox 360, and AMD had already built SME for the Xbox One/PS4.
    – user71659
    Commented Nov 7, 2022 at 22:09
  • 1
    @GrantCurell While passively sniffing a live bus (at least a bus as high-speed as DDR5 or PCIe) is very difficult, cold boot attacks are practical and are regularly performed. TME protects against that.
    – forest
    Commented Nov 10, 2022 at 3:31

amon's answer tackles monitoring via hardware modifications quite well. However, Cold Boot Attacks have had a legitimate place in threat models, with many historical examples; notably, it is occasionally used by law enforcement specialists to retrieve data from live devices that are login-gated but have live disk-encryption keys or other sensitive data stored directly within memory.

Cold Boot Attacks do not necessarily need anything fancy like using liquid nitrogen to freeze the DRAM sticks and taking them into a lab for analysis. Historically, a field specialist can simply force a device to shut down with the power button held down, then boot into a small, portable system to dump the memory into external storage. Memory is retained at high integrity as the device never powers down for more than a few seconds. Most modern SoCs and/or motherboards do wipe memory on startup, which helps to protect against this kind of attack, but using liquid nitrogen to freeze the chip (allowing DRAM to retain data for several minutes after power off), then plugging it into another device to dump memory, or theoretically modifying the BIOS/EFI firmware on the fly via hardware access to prevent the RAM from wiping on startup is possible too.

Assuming that Intel's SoC TPM is free from any practical side-channel attacks on the SoC TPM of the encryption itself (which would be shown in time like any other widespread cryptographic technology), it should in theory completely shut down any chances of a Cold Boot Attack retrieving usable data without compromising SoC TPM communications at boot time:

Upon activation, all memory (except memory in the TME Exclusion range) attached to the CPU/SoC is encrypted using AES-XTS with a 128- bit or 256-bit ephemeral key (platform key) that is generated by the CPU on every boot.

(From the linked TME Specification PDF)

On boot, the CPU generates a random key and passes it to be stored in the SoC TPM, which it uses to transparent encrypt memory access. I've not been able to find whether the current TME standard loses the key during poweroff or wipes it during startup, but there is no way to read the key without directly manipulating the SoC on a hardware level, which means that data stored on RAM is about as safe as the key stored on the SoC TPM, as long as the OS cannot be compromised during runtime.

  • Memory is retained at high integrity as the device never powers down for more than a few seconds – Actually, the memory doesn't power down at all for most kinds of reboots. When a system resets, most component peripheral to the chipset retain power. In fact, firmware can't even assume that devices will be in a fresh state. PCIe devices, memory, etc. will be in the last state they were in and it's up to the firmware to initialize them. As for as the RAM is concerned, the system state never even changed.
    – forest
    Commented Nov 23, 2022 at 22:27
  • Also, is it actually stored by the integrated TPM? I was under the impression that the key storage and all TME-based cryptographic operations are done by the MCH.
    – forest
    Commented Nov 23, 2022 at 22:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .