2 ms·
This seems pretty trivial to fix (or at least work around) by adding an enclave generation number to the key initialization inputs. (They mention that the key i
by addaon 1y ago
This seems pretty trivial to fix (or at least work around) by adding an enclave generation number to the key initialization inputs. (They mention that the key is only based on the physical address, but surely it has to include CPUID or something similar as well?) Understood that this is likely hardware key generation so won’t be fixed without a change, and that persistent generation counters are a bit of a pain… but what else am I missing?
- Veliladon 1y agoNeed to go Apple style where the AES engine is on die. Only the AES engine and the Secure Enclave know the decryption keys. The CPU doesn't know the decryption key. Nothing is sent in clear text over the bus.
- mike_hearn 1y agoThat's how it works already. The memory is encrypted. However, the SGX/SEV model is a very powerful and flexible one - different entities who don't trust one another can share the same hardware simultaneously. If you encrypt all of RAM under a single key, then you can start up a malicious enclave, do some writes - which the CPU will encrypt - capture those writes and redirect them to the memory of a different enclave, and now you can overwrite the memory of that other enclave with your own cleartext. That such attacks are possible was known from the start. What they're doing here is exploiting the fact that Intel (knowingly!) enabled some hardware attacks on SGX in order to allow enclaves to scale up to much larger amounts of RAM consumed.