Christopherson, Sean J <sean.j.christopherson@xxxxxxxxx> wrote: > Andy Lutomirski <luto@xxxxxxxxxx> wrote: > > On Thu, May 11, 2017 at 9:56 PM, Huang, Kai <kai.huang@xxxxxxxxxxxxxxx> > > >> [1] Guests that steal sealed data from each other or from the host can > > >> manipulate that data without compromising the hypervisor by simply > > >> loading the same enclave that its rightful owner would use. If you're > > >> trying to use SGX to protect your crypto credentials so that, if > > >> stolen, they can't be used outside the guest, I would consider this to > > >> be a major flaw. It breaks the security model in a multi-tenant cloud > > >> situation. I've complained about it before. > > >> > > > > > > Looks potentially only guest's IA32_SGXLEPUBKEYHASHn may be leaked? In > > > this case even it is leaked looks we cannot dig anything out just the > > > hash value? > > > > Not sure what you mean. Are you asking about the lack of guest > > personalization? > > > > Concretely, imagine I write an enclave that seals my TLS client > > certificate's private key and offers an API to sign TLS certificate > > requests with it. This way, if my system is compromised, an attacker > > can use the certificate only so long as they have access to my > > machine. If I kick them out or if they merely get the ability to read > > the sealed data but not to execute code, the private key should still > > be safe. But, if this system is a VM guest, the attacker could run > > the exact same enclave on another guest on the same physical CPU and > > sign using my key. Whoops! > > I know this issue has been raised internally as well, but I don't know > the status of the situation. I'll follow up and provide any information > I can. So, the key players are well aware of the value added by per-VM keys, but, ultimately, shipping this feature is dependent on having strong requests from customers.
