Trust Management in Intel SGX Enclaves

This Blog is co-authored with Eliad Tsfadia and Danny Harnik as part of our work at IBM Research — Haifa.

Intel SGX (Software Guard Extension) technology, available in Skylake and later processors, allows to create secure memory regions (enclaves) protected with hardware encryption in the SoC (system on chip). The data is in cleartext only inside the processor. It is encrypted in the SoC before leaving to the main memory, and decrypted in SoC upon fetching from the main memory. Paging is done on encrypted data.

This is a powerful security tool, but it is highly challenging for usage in practical systems. One of the main challenges is a complex trust establishment mechanism required to verify the CPU and the application binary running in the enclave. Without verification, the user can not send secrets (such as data encryption keys) to the enclave, because the CPU can be substituted by a fake processor that leaks the secrets to a malicious party, and the application binary could be replaced by malicious code that leaks the data even in a genuine SGX CPU.

Intel specifies a procedure for such verification, called “remote attestation” and provides example code for using it. Unfortunately, the SGX toolkit doesn’t have an end-to-end mechanism that implements this procedure. Instead, the SGX SDK contains a collection of API calls that can be utilized by an expert developer to create such mechanism. In practice, it is a highly challenging task even for experienced hands-on developers who find it hard to understand the concepts and security model behind the remote attestation, making the implementation not only complex, but also prone to trust breach flaws. Note that besides implementation, the procedure requires registration with Intel for use of its attestation service (IAS).

Our team at IBM Research has designed and implemented a framework for trust management in SGX enclaves that addresses the challenges described above — an easy-to-use verification of computation enclaves, and passing of secret to the enclaves. The trust management framework (or TruCE for short — “Trust in Cloud Enclaves”) handles all aspects of remote attestation and secret delivery process. It enables application developers to focus on the application code, performing attestation by a simple API call.

The remote attestation is followed by sending data encryption keys, or other secret information, to the enclave. We have implemented an easy-to-use mechanism for sending such secrets from clients to enclaves, and opening the secrets inside enclaves — all performed by simple API calls.

The Trust Management Framework has two main components:

• TruCE server: A standalone process that registers with Intel Attestation Service and assists in the remote attestation of cloud enclaves.
• TruCE SDK: A toolkit for application development. It has API and libraries for the trusted (enclave) part of the cloud application, the untrusted part of the cloud application, and the off-cloud client code that interacts with the cloud application.

TruCE is a service model that can have different implementations underneath, yet exposes the same interface to applications. Currently, we have two implementations, one based on an Intel prototype sample code, and the other developed by IBM as part of the RestAssured project. Our framework is flexible and we will be able to replace our implementation with new attestation code, for example, if a new version is released by Intel in the future (i.e., based on the RA-TLS proof-of-concept).

Remote attestation has the following goals:

1. Verify that the attestation report was indeed created in a genuine Intel SGX hardware.
2. Verify that the code being executed by the enclave has not been tampered with.
3. Create a secure channel between an external client and the enclave and pass a secret to the enclave using this secure channel.

The example implementation from Intel does all of the above as a single process. The verifier piggybacks on the verification phase to generate the secure channel and pass secrets to the enclave. But if another party needs to verify the enclave and send a secret to it, the entire process has to be repeated (including interaction with the Intel Attestation Service, IAS).

Our implementation breaks this down into two distinct parts:

a. Preparing a full attestation report and verifying it with the IAS. This satisfies items 1 and 2 above. The report also contains the enclave’s unique public key, generated by TruCE, as a means for connecting and communicating with the enclave. The corresponding private key is kept hidden inside enclave memory.

b. Off-line verification of the attestation report and forming a secure channel with the corresponding enclave. This step can be repeated by many clients without a need to reconnect to the IAS.

The attestation report is signed by Intel keys. Therefore, it can be kept in a public storage, reducing the trust requirements placed on TruCE server. The application clients can verify an enclave report by using the Intel attestation public key, retrieve the enclave public key and use it for the encryption of secrets (such as data keys) to be sent to the enclave for subsequent decryption and processing of sensitive data.

We leverage the SGX “sealing” feature for the safe storage of the enclave private key in a local file. If activated, the TruCE sealing allows performing remote attestation once only, upon a first execution of the enclave code. The generated private key is then “sealed” — encrypted with a symmetric key derived from enclave binary hash, and stored in local file, specified in the TruCE configuration. Starting from the second execution, the enclave private key is unsealed from that file. Since the unsealing can be successfully performed only by an enclave with the original binary hash running on the original SGX CPU, the repeated attestation becomes unnecessary. This saves a considerable overhead of interaction with Intel Attestation Service (IAS) and TruCE service upon each restart of the enclave code.

We have released the trust management framework and toolkit as an open source project at

https://github.com/IBM/sgx-trust-management

with an Apache 2.0 license. Feel free to download and use it, report issues or send pull requests with bug fixes and new features.