> On Dec 6, 2018, at 5:55 PM, Huang, Kai <kai.huang@xxxxxxxxx> wrote: > > >> >> TME itself provides a ton of protection -- you can't just barge into >> the datacenter, refrigerate the DIMMs, walk away with them, and read >> off everyone's data. >> >> Am I missing something? > > I think we can make such assumption in most cases, but I think it's better that we don't make any > assumption at all. For example, the admin of data center (or anyone) who has physical access to > servers may do something malicious. I am not expert but there should be other physical attack > methods besides coldboot attack, if the malicious employee can get physical access to server w/o > being detected. > >> >>> >>> But, I think what you're implying is that the security properties of >>> user-supplied keys can only be *worse* than using CPU-generated keys >>> (assuming the CPU does a good job generating it). So, why bother >>> allowing user-specified keys in the first place? >> >> That too :) > > I think one usage of user-specified key is for NVDIMM, since CPU key will be gone after machine > reboot, therefore if NVDIMM is encrypted by CPU key we are not able to retrieve it once > shutdown/reboot, etc. > > There are some other use cases that already require tenant to send key to CSP. For example, the VM > image can be provided by tenant and encrypted by tenant's own key, and tenant needs to send key to > CSP when asking CSP to run that encrypted image. I can imagine a few reasons why one would want to encrypt one’s image. For example, the CSP could issue a public key and state, or even attest, that the key is wrapped and locked to particular PCRs of their TPM or otherwise protected by an enclave that verifies that the key is only used to decrypt the image for the benefit of a hypervisor. I don’t see what MKTME has to do with this. The only remotely plausible way I can see to use MKTME for this is to have the hypervisor load a TPM (or other enclave) protected key into an MKTME user key slot and to load customer-provided ciphertext into the corresponding physical memory (using an MKTME no-encrypt slot). But this has three major problems. First, it's effectively just a fancy way to avoid one AES pass over the data. Second, sensible scheme for this type of VM image protection would use *authenticated* encryption or at least verify a signature, which MKTME can't do. The third problem is the real show-stopper, though: this scheme requires that the ciphertext go into predetermined physical addresses, which would be a giant mess.
