6

https://edc.intel.com/content/www/us/en/design/ipla/software-development-platforms/client/platforms/alder-lake-desktop/12th-generation-intel-core-processors-datasheet-volume-1-of-2/002/intel-multi-key-total-memory-encryption/

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.

Update

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.

Grant Curell
  • 163
  • 6
  • 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 Nov 07 '22 at 16:08
  • "that seems farfetched" - and yet, it was done, yes? – user253751 Nov 07 '22 at 23:22
  • The whole premise of this question is that it's "farfetched," yet [this video](https://www.youtube.com/watch?v=XfUlRsE3ymQ) and [paper](https://citp.princeton.edu/our-work/memory/) shows recovery of multiple disk encryption keys with nothing more than a can of electronics freeze spray and software. – user71659 Nov 08 '22 at 08: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. – Grant Curell Nov 08 '22 at 13:57
  • @GrantCurell Yes, some Windows virtualization and containerization came from the Xbox as well. But also, data center holdups is a scenario that [actually happened](https://www.computerworld.com/article/2538534/data-center-robbery-leads-to-new-thinking-on-security.html) – user71659 Nov 08 '22 at 16:32
  • Sorry, again, I think there is a misconception that I think a datacenter attack is impossible - I'll clearly dispel that - I don't and was already aware that it had happened in the past. I've worked with a physical red team and am very familiar with the art of the possible. My original comment was related to commercial viability. When a vendor goes to make a product the idea usually goes to some sort of business/engineering group first for market analysis. What I was pointing out is that Intel would not have likely made this feature targeted at the datacenter market as the demand would not – Grant Curell Nov 08 '22 at 18:50
  • have likely justified the spend. However, your comment about Xbox makes perfect sense. Large market, large profit loss, large differentiator if you have a way to stop it. Makes sense. To my point, your article is from 2008. Have people broken into datacenters and stolen things? Sure. Does it happen with such a frequency as it would have been the catalyst for Intel to build this - all signs point to no. Xbox however, would be the subject to such attacks all the time. – Grant Curell Nov 08 '22 at 18:51
  • 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](https://news.ycombinator.com/item?id=12822171) and regulatory EMI emissions, so just choose a cryptographic scrambler (AES) and rig up rekeying. – user71659 Nov 08 '22 at 21:26
  • Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/140478/discussion-between-grant-curell-and-user71659). – Grant Curell Nov 08 '22 at 23:00
  • Related: [How does full memory encryption in newer processes protect against DMA attacks?](https://security.stackexchange.com/q/189950/106285) – forest Nov 10 '22 at 03:23

2 Answers2

8

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 |
+----------+         ^           +-----+
                     |
                    tap

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).

amon
  • 1,276
  • 8
  • 9
  • "such attacks on the memory bus".... like Fireware bus masters being abused to access all of memory? – Ben Voigt Nov 07 '22 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. – Grant Curell Nov 07 '22 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 Nov 07 '22 at 20:26
  • @GrantCurell Why would interleaved memory be a problem? Per Shannon's Maxim, we can assume that the attacker knows the interleaving scheme. From observing the protocol between the DIMMs and the memory controller, an image of the physical memory layout can be reconstructed. Some memory pages might have structures that allow for more efficient exfiltration. – amon Nov 07 '22 at 20:30
  • Apologies, I did not mean to say it can't be done. It just seems commercially unlikely Intel would design an entire feature around something so impractical and niche. You would have to jump through so many wickets with physical access to the server that by the time you did all of it, it begs the question - why... you had physical access. There's a dozen other, better attacks. I'll have to read through the doc you posted but I strongly suspect that the purpose of this feature is not on the physical attack use case. – Grant Curell Nov 07 '22 at 22:02
  • 5
    Physical attacks on the front-side bus to intercept memory traffic have occurred. Specifically, the original Xbox was [broken this way](https://www.bunniestudios.com/bunnie/proj/anatak/xboxmod.html#ldt), 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 Nov 07 '22 at 22:09
  • @GrantCurell Also consider that Intel has competitors. If AMD provides a security feature, Intel will have to provide a comparable feature in order to remain competitive for the kinds of enterprise customers that have a checklist of requirements. TME-MK is also a partial replacement for SGX enclaves that were broken again and again. – amon Nov 07 '22 at 22:23
  • 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 Nov 10 '22 at 03:31
0

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.

kouwei32
  • 121
  • 1
  • _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 Nov 23 '22 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 Nov 23 '22 at 22:30