Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

You can emulate an enclave, but, if you do, the emulated enclave doesn't get access to its seal key, etc. The idea is that you provision secrets accessible only with access to the key and then write an enclave to access those secrets.

An enclave can verify itself to another enclave on the same machine, and Intel supplies a mechanism by which licencees (sigh) can verify their enclaves remotely.



I think the question is, is there any way to verify—from the userland of a cloud VM instance, where the enclave is talked to via hypercalls—that you're "installing" an enclave and its key into the processor itself (where it would be protected from access by rogue datacenter ops staff) rather than just into a hypervisor-emulated processor that is actually fully accessible to the machine owner?

The sibling post mentions that the processor signs its enclaves' outputs with an Intel private key, which would help a bit—but if that key is static, that'd be pretty easily thwarted by decapping a single processor to get the key, just like extracting the DRM keys from set-top boxes or game consoles. (TPMs are supposed to "self destruct" when you try to decap them, but that's only scary for the individualized keys in a TPM; if you're willing to sacrifice 1000 chips to reconstruct one key common to them all, it becomes just a matter of persistence.)


This is, indeed, a problem. I'm not aware of any mechanism to protect against it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: