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.

KeyID is part of the physical address bits in order to communicate the KeyID to the encryption engines

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