Trusted Cloud computing with Intel TXT: The challenge
In today’s connected environments, attacks on compute infrastructure are ubiquitous. Major players have been compromised by hackers and malware, with damages inflicted both to their reputation and their business. Protecting the infrastructure from external and internal threats is an important part of operating production grade cloud environments.
Interested in hearing more about this topic? Vote for Christian's talk, Securing OpenStack with Intel Trusted Computing.
Approaches to meeting this challenge range from hoping it will not hit one’s own environment to fully locking down the environment with heavy gatekeepers and restrictive policies.
What is Intel TXT?
Intel Trusted Execution Technology (TXT) is a combination of hardware and software aimed at securing the execution of sensitive workloads.
In contrast to solutions that protect the Operating System, Intel TXT builds a chain of trust from the system firmware all the way to the server or hypervisor to prevent attacks on system firmware or BIOS, MBR, boot loader, OS and hypervisor.
Every component in this chain is verified against known good states and, depending on the result, marked either trusted or untrusted.
This approach allows detection of not only threats to the OS itself, such as viruses, but also attacks on the configuration and even manipulation of the server’s boot firmware and hardware. When a breach is detected, workloads that require secure execution can not be executed on this server.
How does this approach meet the challenge?
An entity attacking a cloud environment can choose many different paths, but unless the workload itself is attacked, the attack will leave traces in one or more of the Platform Control Registers (PCR). A changed value in a PCR results in a break in the chain of trust, which is then detected by TXT and leads to the resource being marked as untrusted. This happens both during boot and while the platform is running.
When a workload is scheduled, the trust status of the potential compute resources is verified by the scheduler. New workloads are only scheduled on compute resources that are still trusted.
Components to an Intel TXT environment
Servers used in Intel TXT contain a number of components to allow calculation of the required fingerprints and enable a trusted environment.
- The Processor and server chipset must support Intel TXT extensions.
- A TPM module (usually third party silicon) allows storing vendor and owner policies for ‘known good’ state.
- The TPM also allows signing of PCR values that are transmitted to the attestation service.
- BIOS and OS must contain Authenticated Code Modules (ACM) to build a complete chain of trust for TXT support.
- A Launch Control Policy (LCP) allowing comparison of Platform Control Registers (PCR) with known good values.
During system boot and operation, the PCRs get populated with values that can then be compared locally with values in the TPM and remotely with known good values on the Attestation Server.
The OpenAttestation Server is a service that can be run on a separate compute resource, or if desired, on a virtual machine. It confirms or denies the Trusted status of a system based on PCR values submitted to it.
Integration with OpenStack
OpenStack Grizzly and newer versions provide a Trusted Filter for Filter Scheduler that uses Intel TXT to schedule workloads requiring trusted execution only to trusted compute resources. Clusters can have both trusted and untrusted compute resources.
Workloads not requiring trusted execution can be scheduled on any node, depending on utilization, while workloads with a trusted execution requirement will be scheduled only to trusted nodes.
An overview of the flow of information on a trusted compute request can be found in the OpenStack documentation:
Fig. 1: Trusted computing attestation process. (Source: http://docs.openstack.org/grizzly/openstack-compute/admin/content/trusted-compute-pools.html, License: Apache 2.0)
In this graph the OpenAttestation Server is communicating with all compute nodes to determine a pool of trusted resources [1]. An API request is received with trust_lvl set to trusted [2]. The scheduler reaches out to the OpenAttestation Server to determine a trusted resource [3] via a RESTful API call. Upon receiving a pool of trusted resources, the scheduler schedules the workload on a machine inside the trusted compute pool [4].
Implementation example of an OpenStack cluster with Intel TXT support
Intel TXT support can be added to an existing cluster, provided the hardware is TXT capable. In this case, an existing cluster was modified.
An OpenAttestation Server was set up first. It is possible to use a VM inside the cluster to deploy OpenAttestation, but for security and maintainability reasons, the decision was made to use an external host for this environment. At the moment OpenAttestation 1.6, 2.0 and 2.1 are available, but Intel recommended using 1.6 for this project.
Interested in hearing more about this topic? Vote for Christian's talk The TPM hardware and Intel TXT were enabled in the BIOS of all compute nodes that were to be designated to be trusted. OpenAttestation Clients were installed on the controllers and all trusted compute nodes. Initial values of the PCMs were then added to the OpenAttestation Server.
The OpenStack configuration was modified to use TrustedScheduler instead of the default scheduler.
A trusted flavor was created to allow distinction between workloads that require trusted execution and workloads that don’t. To achieve this, the trust:trusted_host flag must be set in the newly created instance. Alternatively one or more existing flavors can be designated as trusted.
It was demonstrated that workloads scheduled with the trusted flavor would only be scheduled onto the trusted compute nodes, whereas workloads that were launched with a non-trusted flavor would be scheduled to any host.
Further security considerations
Attacks to an application that do not leave traces on the system level (e.g. SQL injection) will not trip the Trusted status of a compute node in Intel TXT. This is correct and expected behavior, because in this case the application, not the platform, is compromised. Applications requiring a high trust level must be secured separately with a combination of secure design, development best practices and thorough testing.
Finally, operations security with monitoring, security tests and audits is necessary to spot threats before they develop into breaches.
Conclusion
Platform security with Intel TXT is a big step in the direction of securing OpenStack cloud platforms with a chain of trust spanning hardware, firmware and operating system. Integration into OpenStack is available and has proven reliable. Being able to run a cluster with both trusted and untrusted hosts strikes a balance between administration effort and security requirements.
However, Intel TXT is not a monolithic security solution, but in conjunction with application level security, monitoring and security audits is a cornerstone of a successful cloud security concept.
