10 ms·
A proposed API for full-memory encryption
- belorn 8y agoCorrect 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?
- dooglius 8y agoYeah, 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.
- Gladdyu 8y agoSome 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.
- zaarn 8y agoOr 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.
- monocasa 8y agoThat's the way the 360 did it, total memory encryption, but practically DMA buffers were unencrypted.
- blattimwind 8y agoAIUI 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.
- gruez 8y ago>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. is that an issue when you have IOMMU?
- dooglius 8y agoI 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.
- amluto 8y agoIntel has an IOMMU for PCIe. And DMA sees cleartext with (MK)TME.
- Flow 8y agoThere are hardware based cheats for CSGO. It’s a PCI card with some custom CPU/FPGA on it that scans and changes values inside the memory of the game. When I read the title I hoped it would protect against that too, but no such luck then, I guess?
- blattimwind 8y agoTBH if you have to resort to bus-based cheating in a game then I'd say it counts as a win for the anti-cheat software.
- Flow 8y agoThere 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. https://blog.esea.net/esea-hardware-cheats/ https://blog.esea.net/esea-hardware-cheats/
- ape4 8y agoI guess this would help with Meltdown/Spectre type bugs.
- SlipperySlope 8y agoApparently 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.
- pdkl95 8y ago> 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.
- amluto 8y ago> While using multiple keys has legitimate advantages for the user, it's also a step towards unbreakable DRM and other malware. No it’s not. With MKTME, the kernel can read all memory, ptrace still works, etc. I don’t even see how a future MKTME v2 would be useful for DRM.
- pdkl95 8y ago> the kernel can read all memory That's great, iff you have root-level access. > 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".
- johncolanduoni 8y agoThe 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.
- amluto 8y ago
- phkahler 8y ago>> 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.
- xyzzyz 8y ago> It's added complexity to fix a different problem (untrustworthy virtualization). How do you fix the "untrustworthy virtualization" problem then?
- tedunangst 8y agoOh, that's easy. Just fix all the bugs.
- yjftsjthsd-h 8y agoIncluding bugs in the hardware itself, of course:) (There's a reason why Spectre and Meltdown were a horror show for virtualization.)
- xyzzyz 8y agoRight, but do you have any actionable solutions for mere mortals?
- infogulch 8y agoDoes 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.
- cobbzilla 8y agoI would venture that it does. It’s much, much more likely that forced bit-flips via RH would break decryption vs cause some malicious code execution.
- nemo1618 8y agoIf the encryption has no authentication, an attacker could still conceivably flip individual bits, much like they can when attacking a stream cipher. Does the spec say that the encryption be authenticated? If so, where are the MACs stored?
- blattimwind 8y agoIntel 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.
- a1369209993 8y agoI 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.
- zatempat80 8y agoWhat is the encryption algorithm Intel is planning to implement? I can’t seem to find any references to it.
- the_arun 8y agoWhat are the performance implications with memory encryption?
- smitherfield 8y agoAll 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.
- swordswinger12 8y agoI 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?