> This still won't prevent yoinking the entire RAM modules and dumping them offline.
Theoretically no, but realistically I doubt even intel agencies can pull this off.
> Ideally, the keys should just remain inside the SRAM cache on the CPU, never even going outside of the CPU die.
The real solution is putting the keys somewhere with a guarantee they will be gone prior to possibly executing untrusted code. In my mind the only real solution is UEFI APIs to support this (or wiping the ram as shown here). But then you have to trust the UEFI vendors which don't exactly have stellar track records.
> In my mind the only real solution is UEFI APIs to support this (or wiping the ram as shown here). But then you have to trust the UEFI vendors which don't exactly have stellar track records.
This already exists: it's the MOR bit and it's supposed to be in play here.
I actually think that having a CPU scratchpad key area which is guaranteed to be wiped across any reset action is a much better idea than trusting any dumpster fire UEFI implementation of anything, ever. At least you're trusting a few CPU vendors with something you can audit that way, rather than a million different cobbled-together junky firmware blobs.
> I actually think that having a CPU scratchpad key area which is guaranteed to be wiped across any reset action is a much better idea than trusting any dumpster fire UEFI implementation of anything, ever. At least you're trusting a few CPU vendors with something you can audit that way, rather than a million different cobbled-together junky firmware blobs.
True. Given that the CPU is what's resetting and running the UEFI code, you better hope it could recognize and clear a scratchpad reliably.
The issue is that any memory readable by a software directly has some kind of risks, including SRAM. Here is something something you might find interesting: https://forte-research.com/UnTrustZone/ There is no absolute security, but keeping secure memory away from software provides much better solution.
TrustZone is not a great solution here, the decryption needs to be fast, and this really means that the key should be directly accessible to the kernel.
Having it only inside the cache SRAM mitigates all the offline attacks. SRAM immediately loses content on power disruption (its state is encoded in the current path, not in a capacitor charge). And it's trivial to completely and unconditionally erase on boot.
Ideally, the keys should just remain inside the SRAM cache on the CPU, never even going outside of the CPU die.