There are many options for encrypting disks, partitions, and individual documents. In case one device is compromised, there is even a federal key distribution, where access requires the participation of several parties (see Shamir’s secret sharing scheme ). File system encryption options offer a wide range of options that can be considered standard practice for protecting static data.
Another thing is the data in RAM. They are stored in open form and are also openly transferred between the memory and the CPU. In a virtualized environment, if an attacker found a way to read memory from neighboring virtual machines, he could gain access to the data of other VMs on the server. Physical attacks are possible by copying memory chips or intercepting data on the bus. The threat is even more serious in the case of read-only memory, where data is saved even after a power outage.
RAM encryption technologies address some of these attacks. Although there are fears that unexpected “side effects” will appear on personal computers - for example, an unbreakable DRM.
Intel and AMD offer their hardware encryption schemes in memory.
Intel Encryption
At the end of 2017, Intel proposed an extension of the x86 instruction set called Total Memory Encryption (TME) to fully encrypt physical DRAM and NVRAM with a single ephemeral key. In the near future, it is planned to supplement TME with the Multi-Key Total Memory Encryption (MKTME) extension with multi-key support and the possibility of page encryption of memory with different keys and different applications.
To maintain compatibility with current software, the data inside the processor remains open, as well as in the CPU caches. They are encrypted at the memory controller level and are received in DRAM in an encrypted form.
AES-XTS-128 encryption is performed by the AES-XTS engine, which is physically located near the memory bus.
The TME scheme provides for key generation by the processor and full encryption of the entire memory. This encryption is turned on and off in the BIOS, it is transparent to the OS and applications.
MKTME introduces separate keys to encrypt different pages of memory. A special memory addressing scheme using keyID (15 bits of a physical address) has been developed. MKTME still requires TME activation in the BIOS to work, but with MKTME you can disable the encryption of individual memory regions made by TME.
One of the main tasks of separate memory encryption is the more reliable isolation of virtual machines in the data center. Using keyID with a separate key, you can encrypt the memory of each virtual machine in runtime. For different virtual machines, different keyIDs. Encryption keys can now be generated not at the hardware, but at the software level.
Support for MKTME in the Linux kernel
Since Intel plans to implement MKTME in its future processors, the company in September 2018 took care of MKTME support at the Linux kernel level , and a few months later introduced an updated RFC for the MKTME-enabled API. One of the main developers of both patches is the Belarusian hacker Kirill Shutemov , see his comments in the discussion of the patch for the Linux kernel.
New software interfaces support a user interface for configuring encryption and keys, assigning keyIDs to memory areas and key storage in case of a hot-swap CPU.
The patch for the Linux kernel includes examples of using the new API functions :
// Add a 'user' type key:: char \*options_USER = "type=user algorithm=aes-xts-128 key=12345678912345671234567891234567 tweak=12345678912345671234567891234567"; key = add_key("mktme", "name", options_USER, strlen(options_USER), KEY_SPEC_THREAD_KEYRING); // Add a 'cpu' type key:: char \*options_USER = "type=cpu algorithm=aes-xts-128"; key = add_key("mktme", "name", options_CPU, strlen(options_CPU), KEY_SPEC_THREAD_KEYRING); // Update a key to 'Clear' type:: ret = keyctl(KEYCTL_UPDATE, key, "type=clear", strlen(options_CLEAR); // Add a "no-encrypt' type key:: key = add_key("mktme", "name", "no-encrypt", strlen(options_CPU), KEY_SPEC_THREAD_KEYRING);
Several Linux kernel developers have objected to the proposed changes to the API, pointing out problems with cache coherence and the risk of key leaks due to cold storage, which is introduced in case the CPU is replaced.
Someone doubted that MKTME generally helps isolate virtual machines, because the memory controller does not know where each specific memory access request comes from. In fact, if malicious code is executed inside the hypervisor, then MKTME cannot help .
Developers are likely to make changes to this patch before committing to the main branch.
Alternative from AMD
AMD's similar TME memory encryption technology is called Secure Memory Encryption (SME) . Like TME, it must be included in the BIOS, after which the processor generates a single key, which encrypts all memory transparently for any operating system and applications.
The Secure Encrypted Virtualization (SEV) extension provides separate keys for each virtual machine. Each VM indicates which pages of memory to encrypt. Key management is handled by AMD Secure Processor.
The listed components are implemented in AMD EPYC server processors. Judging by the description, SEV technology is very similar to MKTME. Similarly, SEV technology is powerless if malicious code is launched from the hypervisor (see the description of the SEVered attack).
In June 2019, full support for SEV technology was implemented in SUSE Linux Enterprise 15 Service Pack 1 .
Reverse side of encryption
The reverse side of encryption is when we are not protecting the information, but protecting it from us. It is unpleasant if such manipulations are performed by unauthorized persons (copyright holders) on your own computer.
Hardware encryption of data in memory is a little scary for some users. They agree that this is a useful technology for servers with virtual machines, but they see a threat to ordinary people, especially with the appropriate APIs: “Memory encryption has obvious niches for use, but it seems a little outside the general threat model for most people (users) . For the average person, the more likely use case is probably hostile: it is DRM, protection against unauthorized access in the Denuvo style, ” one of the discussion participants writes on HN.
Perhaps these concerns have a rational kernel. Surely copyright holders will see in this technology an option to protect licensed content from copying. Will they succeed or not? Much depends on the specific implementation of the software interfaces.
* PS, reader, the article is over, but we have a proposal that is beneficial for you:
* - We decided not to make an entire advertising post about discounts, but simply left a small banner here :)