Intel’s Total Memory Encryption, a new x86 extension for full memory encryption
With the introduction of EPYC earlier this year, AMD brought three new security technologies to enterprise customers: Secure Memory Encryption (SME), and its subsets Transparent SME (TSME), and Secure Encrypted Virtualization (SEV).
SME offers per-page memory encryption using a dedicated AES engine. AMD later introduced Transparent SME (TSME) for their Ryzen PRO workstation processors. TSME acts in a similar way to SME but instead of per-page encryption, the entire memory is encrypted without any software intervention, allowing legacy software to run unmodified. SEV further extends SME to AMD-V, allowing guest virtual machines to run under SME using their own private key, creating an isolation layer between the hypervisor/OS and the guest VMs. Keys are managed by AMD’s Secure Processor (AMD-SP), an ARM Cortex-A5 MCU that acts as a dedicated security subsystem.
Total Memory Encryption
Now, Intel has released the first revision of their new memory encryption specification. The specs call for two new x86 extensions:
- Total Memory Encryption (TME) – The base extension which provides full physical memory encryption
- Multi-Key Total Memory Encryption (MKTME) – An extension of TME that adds support for multiple keys
Note that those extensions are very different to Software Guard Extensions (SGX) which allows processes to create enclaves or private memory regions.
The base extension, TME, provides the necessary functionality for full memory encryption. A single 128-bit key, not accessible to software, is generated by the microprocessor at each boot time which is used to encrypt all data sent on the external memory buses. MKTME builds on TME by providing support for multiple keys, allowing for page-granular memory encryption. The extension can also work with various virtualization schemes such as allowing VMs to have their own private memory. The extension is highly flexible and can work with non-volatile memory as well as key provisioning services, including support for over-provisioning.
Different Implementations
As you might expect from Chipzilla, MK/TME are a much more complex extension compared to AMD’s SME. Whereas AMD uses a single C-bit to mark encrypted pages (and SEV extends this to guest page tables), Intel specs call for a whole KeyID to be stored in the physical address, re-purposing some of the physical address bits in the process. Each page is assigned a KeyID which is an index to an internal table maintained by the MKTME engine which stores a 128-bit AES key and its associated mode of operation. This allows for some complex schemes whereby processes can have their own private memory (using their own KeyID) as well as shared encrypted memory (shared KeyIDs) with the other processes/VM. It’s worth noting that even multiple different private pages are possible through the use of multiple KeyIDs.

There is also flexibility as far as modes go. Currently, the specs allow for just one mode, AES-XTS, but reserves additional bits for future algorithms. The initial implementation will focus on DRAM and NVRAM but might extend to other storage devices later on. If you are interested, you can check our in-depth article on Total Memory Encryption for the full rundown.
There is no indication when Intel plans on implementing this extension and the current specs are in very early stages and could change quite a bit by the time things gets finalized.
Specs
Intel Memory Encryption Technologies, External Architecture Specification. Rev Number: 1.0
I actually like their implementation much more than SME. It seems incredibly powerful for doing things such as running a couple VMs and having their own privately encrypted shared memory for totally private communication. Helpful in many producer-consumer models.
I actually ended up finding this post looking for information about which Intel CPUs have TME. turns out Intel still has no implementation. I guess Epyc is the way to go for now.
That is correct. TME will be coming with Ice Lake servers.
this SCREAMS drm. How could anyone want this on their computer, considering it will be at best opt out, and required if you want to watch netflix, and possibly other pseudouseful services 🙁
I guess people can use it for DRM but this FAR more useful for servers and cloud providers. That’s clearly what they are aiming at here. This would provide total isolation between VMs including the provider and hypervisor itself. That’s incredibly useful.