Intel has full control over SGX
by Jethro Beekman – Oct 13, 2015 . Filed under: English, Technology, Security, SGX.
Intel has full control over what software you can run in SGX. This might seem redundant: Intel makes the processor, so of course they have full control. Yet the truth is slightly more inconvenient. When Intel processors don’t run the instructions in your standard software (whether incorrectly or at all), that is a defect at best and a breach of contract at worst. Yet the SGX instruction set includes in its specification that Intel has the authority to make this go/no-go decision.
Let’s take a closer look at how exactly this is specified, since it is pretty well-hidden. After creating and measuring a secure enclave using ECREATE, EADD, and EEXTEND, the EINIT instruction needs to be executed before execution control can be transferred to the enclave. The EINIT instruction has 2 inputs: SIGSTRUCT and EINITTOKEN. SIGSTRUCT contains information about the enclave including an expected hash of the memory. As the name implies, SIGSTRUCT is also cryptographically signed using some key. EINITTOKEN also contains information about the enclave including the same expected hash of the memory as well as the expected public key for the signature. EINITTOKEN must be MACed using the so-called launch key. Both SIGSTRUCT and EINITTOKEN are checked by EINIT and must be valid for execution to proceed succesfully.
Since the launch key is a symmetric cryptography device, surely this key is not widely distributed and most likely is CPU-specific. But how can one obtain this key? The EGETKEY instruction can be used to obtain SGX keys, including the launch key. But this is a user-mode instruction that can only be executed from inside an enclave. There seems to be a chicken-and-egg problem here: to launch an enclave, we need the launch key. To get the launch key, we need to launch an enclave! Here’s the catch: the EINITTOKEN need not be valid if SIGSTRUCT is signed by an Intel key that is baked into the processor.
Thus, Intel can distribute an Intel-signed “launch enclave” that is able to hand out correctly-MACed EINITTOKENs that can then be used to start other enclaves. But they can include whatever logic they want in the launch enclave so Intel can at its sole discretion choose not to MAC a particular EINITTOKEN.
As most things SGX, this “feature” is severely underdocumented. The terms “launch key” and “launch enclave” are only mentioned a few times in the SGX programming reference and never in the whitepapers or tutorials. At the time of writing, nowhere else on the Internet is there any mention of these keywords, except for one insightful Quora answer that I wish I had read months ago.
What reason could Intel have for this architecture? Along with the fact that SGX is being disabled by default, this looks like Intel is again just setting this security technology up for failure due to the lack of widespread adoption by developers and users alike (cf. TXT, SMX, TPM).