In previous blog posts I’ve touched on what Intel Software Guard Extension is (www.prowesscorp.com/intel-software-guard-extensions-when-secrets-need-extra-protection) and how it secures sensitive data (www.prowesscorp.com/intel-software-guard-extensions-call-functions-reaching-the-nearly-unreachable). But securing data in Intel SGX enclaves is a nebulous concept. Concretely, what can you do with Intel SGX?
There are three fundamental things one can do with this trusted execution environment. Foremost is accessing the secrets within, which I discussed in the previous blog post. Another is sealing the data you might have in your enclaves. Intel SGX enclaves are stateless (they reside in system memory, after all), so sealing data—saving it to disk in an encrypted fashion—is the only way to maintain the state of your enclaves. I’ll discuss that in my next blog post. That leaves a third activity you can use Intel SGX for: attesting services.
Attestations with Intel SGX are more fundamental than they might seem at first, because attestation touches on the matter of getting data into Intel SGX enclaves in the first place.
Strange as it might sound, enclave files themselves are open to inspection. This is because enclaves are first built as a dynamically linked library (DLL) file in Windows environments or shared-object (SO) files in Linux, before they are loaded into enclave memory. This in turn means that any secrets you need to secure in an enclave must not be built directly into the code that is loaded at enclave instantiation—it will be open to the operating system or untrusted applications to inspect.
If building secrets directly into our enclaves is not a tenable option, we need a means of putting secrets into enclaves once instantiated. For some use cases, this means using untrusted channels. For example, an enclave that works with user passwords will necessarily rely upon fundamentally untrustable channels like the computer’s keyboard. But the more untrusted channels we can avoid, the better. This is where attestation comes in.
Intel SGX enables attestation to provide a more secure channel for provisioning secrets into enclaves. Such service-attestation can happen locally, with one Intel SGX enclave talking to another on the same computer, or remotely, with applications securely sharing secrets over a network or the Internet.
The primary reason to have two enclaves on a single computer is to establish trust between two applications running on the same system. These enclaves might or might not be from the same signer (that is, developer). For example, the developer of an Internet browser might store user passwords in a standalone password-vault application. The two applications could then securely share the secret (a user’s password to be entered online) while protecting the secret in enclaves.
There are also cases in which the use of enclaves makes sense for applications from different developers. Think of an Internet browser from one developer who wants to securely share data with a billing or banking application. In that case, the encryption key used to secure the exchange of information between the two enclaves would not be signed by a key unique to the developer, but rather by one unique to that particularly computer (more specifically, the Intel processor on that computer).
Whether the enclaves exchanging secrets on the same computer are from the same or different developers, it still does not solve the problem of securely getting secrets into enclaves in the first place. For that, we need secure means of conveying secrets from a remote source to the destination computer (and its enclaves). Enter remote attestation.
Remote attestation is the means by which Intel SGX applications present verifiable evidence about the machine on which they run to a remote party (not necessarily Intel). It is the gold standard for provisioning secrets into enclaves. It permits the secure sharing of secrets between computers when users on either side might have no control over the other.
Secrets come from a remote source to an enclave on a system via encryption:
- After installation of the Intel® SGX Platform Software (PSW) on the client computer, the PSW notes the absence of an Enhanced Privacy ID (EPID) key on the computer and requests that the Intel SGX provisioning service provide it with one. If the protocol exchange between the Intel SGX PSW and the Intel provisioning service is successful—something that requires a genuine Intel SGX-capable CPU—then the device or server will be provisioned with an EPID key.
- The enclave produces a quote. A quote is simply a signed report of current values of the Platform Configuration Registers (PCRs) on the computer. The processor of the computer running the enclave generates this quote automatically.
- The computer running the enclave then sends the quote to the independent software vendor (ISV) that has a secret that the enclave application needs.
- The ISV in turn sends the quote to Intel for verification.
- Intel verifies the quote for the ISV. However, Intel provides no other information (such as who generated the quote). In this case, Intel is like a notary public: all it can say is that the cryptographically signed quote comes from a valid enclave, but nothing more.
- The ISV is then responsible at this stage for inspecting the quote. For example, the ISV might verify that the key is their own.
- After the ISV is satisfied with the quote, the ISV server and the enclave can now derive an encryption key from the quote. This is a symmetric key between the server and the enclave that uses the Diffie-Hellman algorithm.
One important thing to note is that the symmetric key ultimately derived by the ISV server and the enclave in question is specific to that enclave. Thus, even a man-in-the-middle attack would only see the 128-bit encrypted exchange conducted between the server and the enclave.
So, with remote attestation in Intel SGX, we have a very good means of provisioning secrets into enclaves while avoiding untrusted channels. It’s important to remember, however, that “very good” does not equal perfect; Intel SGX is not a general-purpose security solution. For example, Intel SGX cannot protect applications from buffer-overflow attacks, side-channel attacks, or admitting untrusted inputs into your enclave. To pick just one example, here is a report of how researchers used a side-channel attack to breach Intel SGX enclaves: https://www.theregister.co.uk/2017/03/07/eggheads_slip_a_note_under_intels_door_sgx_can_leak_crypto_keys/. This shouldn’t undermine your confidence in Intel SGX, but it should remind us all that tools like SGX are just one part of what should be an interlocking set of security best practices and tools.
To learn more about other aspects of Intel SGX, see my other posts on the topic: https://www.prowesscorp.com/intel-software-guard-extensions-when-secrets-need-extra-protection/ and https://www.prowesscorp.com/intel-software-guard-extensions-call-functions-reaching-the-nearly-unreachable/. And for more details, read the Intel article on remote attestation: https://software.intel.com/en-us/articles/intel-software-guard-extensions-remote-attestation-end-to-end-example.
 That said, exceptional cases do exist. For example, an encrypted code loader could have a pre-encrypted piece of code built into it and would not be vulnerable to unauthorized inspection the way that other secrets might be.
 It is possible for a single application to use two enclaves. For example, an encryption application might keep the encryption key in a small enclave for an entire session and set up a relatively large second enclave to handle the actual encryption or decryption of individual blocks of memory. However, the same result (conserving enclave resources and reducing attack surface) could be accomplished by sealing the encryption key to storage and unsealing it on an ad-hoc basis as encryption or decryption demands. Such a strategy would better conserve enclave resources and could also enjoy better performance. I’ll discuss sealing enclave data to disk in a future post.