Revision History

Intel TXT is the hardware basis for mechanisms that validate platform trustworthiness during boot and launch, which enables reliable evaluation of the computing platform and its protection level. Intel TXT is compact and difficult to defeat or subvert, and it allows for flexibility and extensibility to verify the integrity of platform components during boot and launch, including BIOS, operating system loader, and hypervisor. Because of the escalating sophistication of malicious threats, mainstream organizations must employ ever-more stringent security requirements and scrutinize every aspect of the execution environment.

Intel TXT reduces the overall attack surface for both individual systems and compute pools. The technology provides a signature that represents the state of an intact system’s launch environment. The corresponding signature at the time of future launches can then be compared against that known-good state to verify a trusted software launch, to execute system software, and to ensure that cloud infrastructure as a service (IaaS) has not been tampered with. Security policies based on a trusted platform or pool status can then be set to restrict (or allow) the deployment or redeployment of virtual machines (VMs) and data to trusted platforms with known security profiles. Rather than relying on the detection of malware, Intel TXT builds trust into a known software environment and thus ensures that the software being executed hasn’t been compromised. This advances security to address key stealth attack mechanisms used to gain access to parts of the data center in order to access or compromise information. Intel TXT works with Intel® Virtualization Technology (Intel® VT) to create a trusted, isolated environment for VMs.

Figure 1 is a simplified diagram of Intel TXT stages and components. Later sections of this document describe the hardware and software requirements associated with Intel TXT in greater detail.

Figure 1. Simplified Intel® TXT component diagram.

Intel TXT must be enabled at multiple levels, including hardware, BIOS, OS, and hypervisor. Attestation and cloud-management software work with those components to enable management and reporting for the trusted system environment.

2 Hardware and Software Prerequisites

To create a trusted environment and enable the management layer within it, certain hardware and software requirements must be met. The following discussion summarizes, at a high level, the components that must be present and properly configured before management can be fully realized for a trusted platform, a trusted VM, or a group of trusted VMs. Figure 2 illustrates these requirements.

2.1 Hardware-Layer Requirements

2.1.1 Processor

Server platforms in the measured launch environment must be based on the Intel® Xeon® processor, with support for Intel TXT and Intel VT-x (VMX and SMX). These features were introduced with the Intel Xeon processor 5600 series.

2.1.2 Chipset

A Trusted Platform Module (TPM) must be integrated with the chipset. The chipset and the TPM work together to ensure that the measurements and security properties of the system are not spoofed by untrusted components. TPMs are devices manufactured by various third-party silicon providers that attach to the chipset via the Low Pin Count (LPC) bus or Serial Peripheral Interface (SPI), and they provide a number of security functions. TPM capabilities and requirements are defined by the Trusted Computing Group (TCG)[2], an industry initiative “formed to develop, define and promote open, vendor-neutral, industry standards for trusted computing building blocks and software interfaces across multiple platforms.” TPM Details can be found in the main TPM specification[3].

An Intel chipset with Intel VT must be present to provide the isolation capabilities for the MLE (based on Intel VT-d and Intel VT-x).

2.1.3 BIOS

Intel TXT and the TPM must enabled within BIOS.

Authenticated Code Modules (ACMs) created and signed by Intel must be present inside the BIOS. The ACM contains platform-specific code which is authenticated to the chipset and executed in an isolated environment within the processor and the trusted environment (authenticated code mode), enabling the ACM to perform secure tasks.

2.2 Software-Layer Requirements

2.2.1 Operating System and Hypervisor

An MLE provides a software-verification process to attest that all of the critical components of the pre-OS launch environment have been verified against a known good source, ensuring a secure chain of custody from the moment a system is powered on until the system kernel or hypervisor takes control. An Intel TXT-aware hypervisor provides isolation for host OSs and applications. To identify operating environments and hypervisors that support Intel TXT, please refer to the Intel® Trusted Execution Technology Server Platform Availability Matrix[4].

3 Measured Launch Environment and Trusted Launch Sequence

3.1 Measuring and Validating the Environment

The primary goal of using Intel TXT is to validate that there have been no unauthorized changes to critical parts of the code that provides the secure environment. This check is performed each time the environment launches, whether it is a cold boot, warm boot, or exiting one hypervisor and launching a new one.

3.2 Measured Launch Environment (MLE)

The MLE includes the following components:

ACM, which performs the measured launch, starting the dynamic chain of trust

Initial system software code (referred to as MLE code) that sets up the platform to protect the OS/hypervisor kernel code

A successful measured launch requires that the ACM is valid, the server platform (as measured by the BIOS) has passed the launch control policy, and the MLE code measurement has passed the launch control policy.

These components are measured by creating an SHA-1 hash of the component and validating that hash against a set of securely stored values. Adding launch control policy assures that OS/hypervisor execution is allowed to continue if and only if the policy is satisfied. Policy consists of the platform owner specifying the minimum version of ACM, platform configuration as measured by Platform Configuration Registers (PCRs) 0-7 in the TPM containing known good values, and the MLE measurement being a known good value.

3.2.1 Measured Launch Phases

To better understand the role of the OS/hypervisor and the corresponding role of the developer, consider the platform phases associated with measured launch, which are illustrated in Figure 3.

Figure 3. Measured launch timeline.

The phases are as follows:

Pre-boot phase is performed by the system firmware (BIOS/UEFI). One of the goals of an Intel TXT-enabled BIOS is to initialize the platform to a state that will support a “measured launch.” To do so, the firmware measures the Static Root of Trust and other platform components into PCRs 0 through 7. It also protects Intel TXT resources and locks the platform configuration.

IPL represents the normal boot process up until the time that the process would normally load and execute the kernel. The first module executed should now be the Trusted Boot (tBoot) module.

TBOOT Pre-Launch is the part of tBoot that determines whether a measured launch is possible and sets up the platform to perform the measured launch.

TBOOT Launch is the part of tBoot that starts the measured launch process by executing the GETSEC [SENTER] instruction. This execution starts the dynamic chain of trust measurements, extending the root of trust measurement into PCR 17 and measures tBoot Post Code into PCR 18.

TBOOT Post Launch is the code that executes as a result of the measured launch. Its purpose is to securely bring the platform to a protected, usable state. This is the first system code to be measured, and it starts the chain of measurements.

OS/VMM Post Launch includes the kernel and any other modules that need to be loaded. The kernel is responsible for measuring other modules before they are executed if they have not already been measured by the tBoot code.

Regular Operation commences after successful launch, when the OS/hypervisor performs its primary functionality (i.e., the same functionality as would occur in an environment without Intel TXT). However, there are some additional capabilities available to the OS/hypervisor, which must protect Intel TXT resources.

MLE Shutdown occurs before turning off or resetting the platform; there are certain steps the OS/hypervisor is required to take to exit the secure environment. While this phase could be followed by another measured launch, it is typically followed by a platform reset or power cycle.

3.2.2 Platform Configuration Registers (PCRs)

PCRs are registers dedicated to the TPM , which capture measured information about the platform during the boot sequence. Descriptions of the types of content stored in each PCR are summarized in Table 1.

Table 1. Contents stored in various PCRs.

PCR Numbers

Description of Contents

0-7

Information associated with the BIOS

Example: the value of PCR 6 would change as a result of an S3 shutdown/resume

8-14

Information associated with OSs

17-21, 23

Information associated with a Dynamic Operating System

Example: PCRs 19-21 define VMware-specific information

22

Geo-tagging index, enabling any Dynamic Operating System to define the geographic location of a platform; an extension/dynamic PCR that can be written to by the Dynamic OS

4.1 Hardware Deployment Process (BIOS)

Before the rest of the implementation can be accomplished, the TPM and Intel TXT must both be enabled in BIOS. Typically, the TPM must be enabled before enabling Intel TXT, and the entire process often requires a few reboots to accomplish, as illustrated in the following example:

Boot to the BIOS level; enable TPM; save; reboot

Intel TXT option will now be available; enable Intel TXT; reboot

The following blog posts give specific examples on Dell and IBM servers:

Verify that the PCRs are populating and that Intel TXT measured launch equals true.

4.2.2 SUSE, Red Hat, Ubuntu*, and Xen

SUSE, Red Hat, and Ubuntu Linux distributions provide tBoot installation packages, which include detailed installation instructions with the readme file. Note that the steps are similar to the open source solution steps given above. Supported versions include the following:

SUSE Linux Enterprise Server (starting with version 11 with SP2 and kernel 2.6.33)

5 Trusted versus Untrusted Systems

It is beneficial to be able to identify and manage the trusted systems protected by Intel TXT within your environment. Insight into which systems are trusted and which are untrusted can be used to set up trusted lists or trusted pools. Those systems that are trusted can be assigned tasks that require higher security; this capability is particularly valuable in virtualized and cloud-based implementations.

For example, virtual environments allow migration of running VMs among physical hosts. Trusted systems can be grouped into trusted compute pools, to which policy can be applied to ensure that VMs are only migrated to trusted systems within the cloud. Figure 4 shows how VM migration can be controlled across resource pools, using trust as control instrumentation for migration policy. This approach enables IT managers to restrict confidential data or sensitive workloads to platforms that are well controlled and have had their configurations thoroughly evaluated with the aid of Intel TXT.

6 Management of Trusted Systems with Use Cases

Software cloud-management solutions are available for various use cases, including policy and compliance enforcement, automation, auditing, reporting, workload migration, etc. Trusted compute pools can be combined with these solutions to enhance security.

This section discusses ecosystem solutions that address various use cases for trusted compute pools; the use cases themselves are discussed at greater length later in this document.

Figure 5 illustrates, at a high level, potential interactions between different management solutions and a trusted system or trusted VM.

6.1 Policy Management

Security policy management software can set policies that dictate how trusted compute pools will be used. Examples include restricting or allowing VMs, sensitive workloads, or data migration based on platform security or trust profiles. A simplified approach for policy enforcement could include using the scheduler with an OpenStack solution, or even labeling sensitive workloads in a virtual cloud infrastructure. Third-party policy engines also specialize in the compliance requirements for specific business verticals with built-in policy templates to assist in implementation.

The following use cases illustrate a few ways that a policy management solution can interact with Intel TXT-enabled systems.

6.1.1 Confidential Data and Sensitive Workloads

As already mentioned in this document, the ability to assign sensitive workloads or ensure that confidential data is only executed on trusted platforms or trusted VMs can have substantial benefits. Consider the case where a patient wants to access his or her detailed medical history. A web hosting server with a trusted status could display the information to the end user once they have logged on, but if the web hosting server was found to be on a non-trusted host, the policy engine could reduce functionality and prevent logins.

For an example of how to set up a filter using Open Attestation that can be used to schedule workloads on trusted compute pools, see Openstack Nova Scheduler[18]. This code sample will provide insight for those who wish to use an open source approach for this particular use case.

6.1.2 Integrity Checks

The first level of integrity checking occurs upon cold boot of a server with Intel TXT at the hardware layer and moves to the software layer. The MLE helps to insure the integrity of the server.

An additional layer of integrity checking can be implemented using Intel TXT; for example, one could periodically check for compromised hypervisors without interruption to business applications. This capability could enable faster detection of compromises, helping to contain the spread of malware and reduce the need to rebuild hypervisors if a compromise is detected.

Some of the advantages with this use case include the following:

Proactively detect compromised hypervisors more quickly

Reduce or eliminate application downtime

Help contain the spread of malware

Reduce the need to rebuild hypervisors in a cluster if compromise is detected

The use case shown in Figure 6 employs live migration to move all VMs off each server within a cluster in turn, allowing the server to be restarted and an integrity check to be conducted without application downtime. This use case assumes that the servers in the cluster are Intel TXT-capable and enable a hypervisor to be launched securely.

Live migrate all VMs running on the server to other servers in the cluster.

Restart the server, with an Intel TXT-enabled integrity check to verify that the hypervisor has not been compromised.

If the hypervisor code is verified as good, live-migrate the VMs from other servers back to the server. If the hypervisor code is bad, take corrective action immediately on all servers, hypervisors, and VMs involved in this specific series of VM migrations.

Repeat the preceding steps for each server in the cluster.

The use case should be a policy-driven, automated activity that can be scheduled to run at night or at other times of low activity. In a large cluster, several servers could execute the use case concurrently. With the appropriate ecosystem enabling for Intel TXT, this use case could significantly enhance security in a virtualized environment.

In cloud computing environments, workloads are migrated to available compute resources. In a secure cloud system, when workloads land on a single trusted server, they are segregated to avoid interfering with each other, gaining access to each other’s sensitive data, or otherwise compromising security or privacy. These properties can help make it more difficult to subvert multitenant environments. Strong security safeguards are imperative for cloud service providers that wish to attract new customers and workloads.

6.2 Security Information Event Management (SIEM)

SIEM software creates a general security control point that aggregates the real-time alerts, event information, and reports from various security applications and activities into a database that can be queried, including the status of trusted compute pools.

SIEM can assist with generating reports that can help automate gathering data used for compliance purposes, identifying patterns in event data and assisting with automated analysis of alerts and correlated events.

Intel does not endorse any particular software vendor (nor is this a comprehensive list), but software vendors that have SIEM solutions that work with Intel TXT-enabled systems include Hytrust[21], EMC[22], McAfee[23], and Trapezoid[24].

For example, a company can verify at any given moment that medical data containing patient records is only accessible from systems within a trusted compute pool to help ensure compliance.

6.3 Governance, Risk, and Compliance (GRC)

GRC software produces specific audit and compliance reports, often utilizing the information gathered by an SIEM solution. Administrators can use this information to create new policies or to refine existing ones for use by the policy engine. The GRC software may also query the infrastructure to make sure policies are in place and active. Various solutions may specialize in the compliance requirements for specific business verticals, perhaps providing with built-in policy templates to help implementation.

A GRC platform combined with trusted compute pools can enable auditing information on a trusted platform or a trusted compute pool. This capability can help provide real-time or historical metrics, verifying that platforms are trusted as expected and that workload controls for trust and location are enforced.

6.4 Geolocation / Asset Tagging

The MLE provides the ability to assign a secure geolocation tag to a non-volatile index in the TPM on the trusted server during the provisioning process. An Intel TXT-enabled hypervisor has the capability to insert or extend the contents of the tag into one of the PCRs in the TPM. Attestation or restful APIs can provide an interface to the geolocation tag information, including geolocation tag lookup and user-readable/presentable strings and descriptions that can be used for asset tagging. The benefits of utilizing this tag for geolocation or asset tagging are discussed in greater detail below.

6.4.1 Geolocation

Geolocation can help address security and regulatory compliance issues with workloads migrating within the cloud between servers in two different countries. Each country may have its own set of laws for data security, privacy, and other considerations. Because the requirements of these laws may conflict with an organization’s policies, it may be necessary to ensure that workloads use only cloud servers physically located in specific countries. This process involves determining the server’s location, which is known as geolocation.

A platform that is not trustworthy places the workload at risk of compromise and cannot provide assurance that the claimed geolocation of the cloud server is accurate. Geo-located platforms in which there is a hardware root of trust are aggregated into trusted compute pools, segregating them from untrusted resources and enabling trusted geolocation. This capability allows for enforcement of geolocation restrictions and auditing.

Some examples of regulatory compliance requirements that geolocation can help with include the following:

REST APIs can be used to retrieve information from the TPM, including geolocation information. Additional examples of REST APIs are available from virtualization vendors and the OpenStack: Open Attestation SDK[40].

An example of a JSON-based request for attestation and its response is shown in Figure 7. Geolocation enables IT to build a policy that avoids placement of workloads on systems outside approved locations. For more information on attestation, please see the “Attestation” section of this document.

Figure 7. Example of JSON-based request/response for attestation.

For use case implementation examples, please see the following resources:

Using an Intel TXT-enabled hypervisor to assign descriptive information into the contents of the geolocation tag that has been extended into one of the PCRs of the TPM provides an opportunity for asset tagging. Asset tagging can help with multi-tenant segregation or segregation of confidential data or sensitive workloads, as described elsewhere in this document. It can also assist with meeting regulatory compliance requirements, including PCI DSS[43] and HIPAA[44].

7 Attestation

7.1 Attestation

Building on the security provided by Intel TXT attestation provides assurance that the protected environment is correctly invoked and measures the integrity of software running in the protected environment. The information exchanged during this process, which is known as the “attestation identity key credential,” is used to establish mutual trust between parties. Attestation is a foundational component for building trusted compute pools. Deploying attestation within your network requires at a minimum, an attestation server and an attestation client whose hardware and software provide protection within an MLE.

OpenAttestation is an open-source, Linux-based attestation solution that provides the ability to more readily identify MLE-protected systems.

Intel’s offering, the Intel Trust Attestation Solution (Enterprise Edition), uses APIs to provide ease of access to attestation. Additional benefits include auditing capabilities, automation for ease of deployment, integration with OpenStack, and productivity tools. Intel Trust Attestation Solution (Enterprise Edition) provides an off-the-shelf solution that integrates with OpenAttestation, making it easier for the end user to deploy Intel TXT expediently.

The OpenAttestation SDK[46] supports web APIs for third-party software to integrate and access web-based attestation appraisals, in support of cloud usage models. The OpenAttestation SDK is intended to be merged, modified, and distributed as part of third-party software vendors’ cloud management stacks. Key features include the following:

Supports major Linux host OSs

PCR-based report schema and policy rules

RESTful based Query API

Reference web portal/GUI implementation

Historical PCRs data tracking/comparison

White list management

Flexible access control to attestation server

Supports Tomcat two-way SSL/TLS for Query APIs

Hook for ISVs to implement custom access control

7.2.1 Supported Software

OpenAttestation has currently been validated on Ubuntu 12.10 and Fedora 19.

7.2.2 General OAT Deployment Guidelines

Deploying OAT in a network environment requires a server running the OAT service, as well as MLE-protected systems running the OAT service.

Enable TPM and Intel TXT in BIOS on each of the hosts (please see the section of this document, “Hardware Deployment Process (BIOS)” for examples.

Install attestation agent on hosts, which is required to enter into a trust relationship with the attestation server.

These steps enable easier identification of the trustworthiness of hosts within the network environment using OAT. The OAT SDK is expected to be enhanced with security features and integrated into third-party cloud-management software, and then to be distributed by independent software vendors to cloud service providers.

The OpenAttestation SDK[50] can be used to grow your own management solution from the ground up. Having the ability to communicate with trusted systems or trusted virtual machines via APIs or through a trust agent can be used for basic policy enforcement. Table 2 shows example service APIs, from the OpenAttestation SDK documentation.

Table 2. OpenAttestation service APIs.

API Type

Method

Method Name

Description

Provisioning

POST

/hosts

Adds/registers a new host

PUT

/hosts

Updates the configuration of an existing host

DELETE

/hosts?Hostname

Deletes the specified configured host

GET

/hosts?searchCriteria

Retrieves the list of all hosts matching the search criteria; if the search criteria is empty, all the hosts registered are retrieved

Query

POST

/PollHosts

Gets the current trust status of all the hosts requested

The following sample query from the OpenAttestation SDK uses an API to retrieve a list of the hosts registered with OpenAttestation (OAT), based on the search criteria specified. If no search criteria are given, then either all the hosts are retrieved, or else only the specific hosts whose names match the criteria are retrieved.

For an example of how to set up a filter on Open Attestation that can be used to schedule workloads on trusted compute pools, see Openstack Nova Scheduler[52]. This could be used for use cases where confidential or sensitive workloads need to be isolated to a trusted compute pool.

7.3 Intel Trust Attestation Solution (Enterprise Edition)

The Intel Trust Attestation Solution (Enterprise Edition), code-named “Mount Wilson, is a multi-hypervisor, multi-device, Trust Attestation/Verification Solution, for servers, clients, network/storage, and embedded devices. It can be used by cloud resource schedulers, SIEMs, policy engines, and GRC tools for trust verification, remediation, reporting, and compliance. It can also be used by a trust broker for secure access to trusted services from trusted clients. For additional information on Intel Trust Attestation Solution (Enterprise Edition), contact your Intel Field Applications Engineer (FAE) or submit a request for more information[53].

7.3.1 Supported Software

The Intel Trust Attestation Solution (Enterprise Edition) assists the end user with PCR and module-based attestation/verification, starting with the following versions of software:

Create/update MLE and white list definition. Subsequent provisioning is only needed when there is a change to the OS/BIOS/hypervisor versioning (for example, by means of software patches).

Register all hosts with Intel Trust Attestation Solution (Enterprise Edition). This step works in conjunction with the white list to add more details for each registered system, such as BIOS info, OS-VMM info, etc. Intel Trust Attestation Solution (Enterprise Edition) server provides an option for automation of host registration.

The ability to do a bulk refresh; this allows the trust attestation of multiple hosts to be refreshed concurrently (as opposed to individually clicking the “Refresh” button for each host on the main page)

Detailed reports of the host MLE information, trust status, and the date of the last trust status refresh

Management of the hosts, including the ability to add, edit, import, or view hosts

Management of the white list, including the ability to import from a trusted host and edit MLE, OS, or OEM information

About the Author

David Mulnix is a software engineer and has been with Intel Corporation for over 15 years. His areas of focus have included software automation, server power and performance analysis, and cloud security.

Comments (2)

I would suggest contacting ASUS support to see if they can assist you, if you can not find it in the BIOS sometimes upgrading the BIOS to a newer version can overcome issues like the one you are experiencing. In other cases it may already be there but perhaps it is not obvious without some assistance from the manufacturer.