This article describes the Intel® Software Guard Extension (SGX) attestation process, the challenges it presents, and how Fortanix Enclave Manager helps to overcome them.
Intel® Software Guard Extensions (SGX) is a technology that allows software developers to encrypt their applications’ data at run time. It achieves this by allowing applications to launch specially protected software containers, also known as enclaves. These enclaves can be used for protecting applications’ data from adversaries who could have root privileges or even physically tap the memory bus.
Just running an application (or its sensitive parts) within an enclave is not sufficient. To utilize the security guarantees of SGX fully, the user must also verify that the application which they have built is running unmodified inside a secure enclave. Intel provides a way for users to achieve this using remote attestation.
When it comes to cloud deployments at scale, the remote attestation scheme provides some usability challenges (refer to the section “Challenges for Deployments at Scale Posed by Attestation”), which the Fortanix Enclave Manager helps to overcome. Additionally, the Enclave Manager’s user interface provides unified monitoring for all user enclaves that use Fortanix Runtime Encryption® technology.
The SGX attestation process helps an enclave to cryptographically prove that:
- The code as-built and signed by the user is running unmodified in a genuine SGX enclave.
- The hardware in which it is running is a secure SGX platform with all the necessary microcode updates applied at boot time.
- The hardware and software configurations needed for SGX are correctly applied.
SGX Attestation Process - High-Level Steps
Below is the high-level list of the steps that an enclave has to perform in order to obtain remote attestation from IAS (Intel Attestation Service):
- The enclave should do local attestation with Intel Quoting Enclave to generate a Quote.
- The Quote should be sent to IAS, and the signed quote response (remote attestation) from IAS should be verified and interpreted.
- Enclaves that communicate with each other should verify attestations to ensure that sensitive information does not leak outside the SGX boundary.
- Similarly, any external client or a User exchanging sensitive information with an application running within an enclave should also verify the attestation.
Challenges for Deployment at Scale Posed by Attestation
- Every time an instance of a microservice is either deployed or migrated, the remote attestation flow must be repeated which has an external call to an IAS service.
- Most microservices use TLS for exchanging sensitive information. For the security guarantees of SGX, the TLS stack should verify SGX attestations too.
- For any changes to the IAS API, all application enclaves need to be upgraded.
- A monitoring/controlling service also needs to verify SGX attestation.
- IAS will attest any securely deployed enclave signed by a registered User, and, if the user wants to have policies around whether an enclave should be allowed to join their cluster of services or not, additional instrumentation is needed.
Fortanix Enclave Manager helps to overcome all the challenges presented in the previous section for Users to deploy an enclave application.
In order to avoid multiple calls to IAS, the Fortanix Enclave Manager does IAS remote attestation on each of the nodes once and then uses its attested enclave to locally attest other enclaves (User's applications) on the same node. Also, its backend server verifies the local attestation and issues a TLS certificate to the requesting applications. As TLS using X.509 certificates is a widely used protocol, the microservices can use the backbend's certificate as the root of trust and secure inter-enclave communications without having to change their crypto stack. This ensures that only enclaves running in a secure SGX environment get the required TLS certificates.
Enclave Manager also requires that the enclave measurements must be whitelisted prior to certificate issuance ensuring that only enclaves that the User intends to be deployed are issued TLS certificates. Since it removes IAS dependencies from the application's binary, for any changes to the IAS API, upgrading Enclave Manager should be enough. Additionally, it provides a UI allowing Users to monitor running enclaves, see the configured applications, audit the issued certificates, and so on.