> Total Memory Encryption (TME) ... uses a single, CPU-generated key for all of memory; users can control the usage of TME in the boot-level firmware. A new standard ... MKTME ... supports different encryption settings ... at the page level, and more keys. Different keys can be used at the same time for different memory regions.
While using multiple keys has legitimate advantages for the user, it's also a step towards unbreakable DRM and other malware. It's easy to think about how a new technology is useful, but it is prudent to also consider how the technology might be used as a weapon.
Memory encryption has obvious niche uses, but seems slightly outside the common threat model for most people (users). The more likely use-case (for the average user) is probably user-hostile: DRM, "Denuvo"-style tamper resistance.
edit: Forgot to mention: the single-key variation (TME) can provide a lot of the user-focused benefits, without the DRM proliferation risk.
> I don’t even see how a future MKTME v2 would be useful for DRM.
Intel already tried that with SGX. (Intel's documentation for SGX was all about creating a "Trusted Computing" environment, using the old Palladium/NGSCB DRM-sense of "trusted".
The difference is that SGX was explicitly designed to protect memory/execution from kernel access, and TME doesn’t have such a facility or any path I can see towards becoming one.
Yep. Full memory encryption formed the basis of the Xbox360's security, and other than one exploit that was patched pretty quickly, it needed a reset glitching attack to add unsigned code execution.
TME doesn't help much against local attackers, the memory controller isn't smart enough for that (yet), especially because the hypervisor still controls the keys.
It does however help to mitigate a number of attacks such as freezing memory to extract encryption keys and similar.
>> In a virtualized environment, if attackers can find a way to read memory from neighbor virtual machines, they can access the data from those machines.
I would not advocate memory encryption as a defense against this kind of attack. It's added complexity to fix a different problem (untrustworthy virtualization). OTOH it is useful to protect against physical access at the hardware level - and that's not really a common concern but is valid is some cases.
Does this mitigate any kind of rowhammer attacks? The kernel will be managing the keys, but if normal programs don't have access to them they would be unable to predict the actual bytes written, which I think is necessary for rowhammer.
I don't think this proposal supports authenticated encryption, but if you're using ECC RAM, you could batch up groups of 8x72bit DDR lines, giving you 64 non-data bits: 10 bits for single error correction on a 576bit batch, and 54 bits for MAC. If your L3 uses 64-byte or larger cache lines, this is mostly free; you could also scale this up or down depending on how many MAC bits you want versus how large youre cache lines are.
Intel TME uses AES-XTS, which is less malleable[1] compared to say AES-CTR, which would provide no protection against rowhammer.
[1] This is a bad kind of security that's very difficult to reason about because it is unsound. This is a matter of "less worse, relatively speaking". The obviously superior and secure approach is to use AEAD, but that would be more difficult to integrate into the system.
Correct me if I got this wrong, but what we are talking about is basically having a hardware encryption processor and tmp-like module within the cpu chip itself, sitting between the memory controller and the cpu. Does that also cover the L caches?
Yeah, it's done at the memory controller level. No the caches won't be encrypted, but it wouldn't make sense to; any threat model that says L* caches can be read by an adversary should also allow the register file itself to be read, and that's going to contain unencrypted data (after all, you have to decrypt the data at _some_ point).
I do wonder, though, whether the memory remains protected against adversaries who can put rogue devices on the PCIe or UPI buses; it seems that these would be able to get decrypted data.
>I do wonder, though, whether the memory remains protected against adversaries who can put rogue devices on the PCIe or UPI buses; it seems that these would be able to get decrypted data.
I don't believe Intel (whose implementation of encryption this targets) have an IOMMU for PCIe. For UPI (or whatever inter-socket protocol is going on), it wouldn't make sense to have an IOMMU since cores need permission to do arbitrary reads anyway.
There are plenty of cheats that are seemingly impossible to detect. I play Team Fortress 2 and there's at least one cheat there that, from what I've read, uses code that's unique to each instance used by a cheater. VAC seems to scan for code signatures so it doesn't detect it.
This hardware cheat makes it even harder to detect since it reads and writes directly to main memory using DMA. No drivers or software needed at all. All you possibly could detect is the PCI-ID(which can be changed) and possibly the DMA if there's an IOMMU.
No, I mean that, if the IOMMU is off or if it allows access to an address, then MKTME will treat that access exactly as though it was a normal access from the CPU. So, if the device selects the right key (the key uses some otherwise unused physical address bits), then the device will access the decrypted data.
Some NICs are able to dump data directly into the (L3) cache (DDIO on Intel), so either the L3 will have to be encrypted or the IOMMU needs to contain the crypto functionality.
Or maybe the kernel would have to except some memory for MMIO from being encrypted. That way the PCIe bus gets access to the memory without needing the keys but also can't read what it shouldn't.
AIUI Intel TME sits in the memory controller, same for MKTME. Therefore memory protection as usual protects access, and any read/write requests made to the IMC will have it use the correct keys for en/decryption. The IMC doesn't care/tell where those requests came from.
I don't really understand the threat model in which this provides a real security benefit. If someone can inspect the contents of memory, can't they also recover the encryption key somehow?
All the discussion ITT so far has been about the concept or hardware implementation of full-memory encryption. I'm wondering if anyone has thoughts about the proposed API.
Apparently not because of what is said above about caches being unencrypted.
Past Intel architecture allows two threads to share a physical core in such a way as the cached data of the first thread may be probed with a timing attack to reveal confidential data.
While using multiple keys has legitimate advantages for the user, it's also a step towards unbreakable DRM and other malware. It's easy to think about how a new technology is useful, but it is prudent to also consider how the technology might be used as a weapon.
Memory encryption has obvious niche uses, but seems slightly outside the common threat model for most people (users). The more likely use-case (for the average user) is probably user-hostile: DRM, "Denuvo"-style tamper resistance.
edit: Forgot to mention: the single-key variation (TME) can provide a lot of the user-focused benefits, without the DRM proliferation risk.