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 which allows software developers to encrypt their applications’ data at run time. It achieves this by allowing applications to launch special 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, 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 micro code updates applied at boot time.
- The hardware and software configurations needed for SGX are correctly applied.
SGX Attestation Process - High Level Steps
Below are 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 micro service is either deployed or migrated, the remote attestation flow must be repeated which has an external call to an IAS service.
- Most micro services 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 micro services can use the backbend's certificate as 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 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.
Enclave Manager Usage Workflow
A high-level flow of Enclave Manager usage is described below:
- The user deploys Enclave Manager.
- Upon deployment, the backend enclaves obtain IAS attestation and use that to securely establish a highly available service cluster (in case of multi node backend deployment).
- The backend issues an X.509 certificate to each instance of the node agent if it can obtain a valid IAS attestation for the node. This flow is called node provisioning and happens only once for the lifecycle of node agent process.
- Node provisioning will happen automatically post deployment.
- The user now whitelists their enclaves (either from the UI or using the Enclave Manager APIs) and then deploys them.
- The application enclave communicates with the node agent to obtain a local attestation which the backend service verifies before issuing a TLS certificate. For enclaves deployed using EnclaveOS, this flow is automated and triggered using certificate-related manifest options.
- The application enclave can also choose to provide periodic heart beats signed from within the enclave for secure enclave monitoring. For EnclaveOS applications, this is triggered using the heartbeat-related options in application manifest.
Fortanix Enclave Manager™ manages the containers secured by Intel SGX, tracks their enclave lifecycle and provides features such attestation-based TLS certificates, enclave whitelisting, geolocation enforcement, DRM, secret injections, and so on. The platform integrates well with the existing container orchestration technologies, such as Kubernetes, Docker Swarm, or, OpenStack.