Attestation: Proving Trustability
In the last few chapters we have looked at the first stages in a process toward establishing trust between systems. First, the establishment of roots of trust and the measured boot components; and second, the collection of evidence throughout the measurement process. We reviewed the different roots of trust in a compute platform—namely, the RTM, RTS, and RTR—and how the measured boot process (S-RTM and D-RTM) uses the RTM to measure and store the evidence in the RTS. The next stage in this process is the presentation of this evidence through attestation protocols and appraisal of the evidence that asserts the integrity of a platform. This stage is referred to as attestation and verification in this book, and it is our objective for this chapter.
We introduce the concept of attestation in this chapter, along with an attestation framework that defines a logical view of the assertion layers leading to attestation of specific target entities or components. The attestation provides evidence of trust and can include any device or target system participating in the trust chain. Additionally, the chapter covers one commercial implementation of the attestation solution authored by Intel and security management independent software vendors, code-named Mt. Wilson. We provide details about the solution architecture, attestation application programming interfaces (APIs), integration of these APIs into a security management function, and workload orchestration tools for decision making. We hope application developers and security specialists will gain a solid understanding of the inner workings of attestation solutions to the level of being able to carry out integration projects and even extend the paradigm.
Attestation
Attestation is a critical component for trusted computing environments, providing an essential proof of trustability and the means for conducting audits for target computing devices. That is, attestation allows a program or platform to authenticate itself. Remote attestation is a means for a system to make reliable statements about the pre-launch and launch components in a distributed system. A remote party can then make authorization decisions based on that information. The concept of attestation is still evolving, and hence the research community has not reached a common understanding of what it means. However, here is a practical definition for the purpose of working with trusted clouds. The Trusted Computing Group (TCG) defines attestation as:
The process of vouching for the accuracy of information. External entities can attest to shielded locations, protected capabilities, and Roots of Trust. A platform can attest to its description of platform characteristics that affect the integrity (trustworthiness) of a platform. Both forms of attestation require reliable evidence of the attesting entity.
There are two properties that have to be addressed to assert this trust.
These two properties help us classify the remote attestation techniques. Most of the existing remote attestation techniques can be categorized into one of the two types.
Both static and dynamic remote attestation are relevant to virtualization and cloud computing. As described in the previous chapters, the trusted compute pool uses models that begin with the boot integrity of the platform, asserted with the static attestation techniques. Meanwhile, asserting run-time integrity needs dynamic attestation techniques. Static attestation techniques are beginning to be adopted in practical cloud computing deployments. The static techniques provide a good foundation toward reaching a trusted infrastructure. Dynamic remote attestation is complementary and brings significant value by enforcing security; hence, we can expect a strong drive for adoption. However, in order to achieve the vision and goals of a trusted infrastructure, it is an imperative to have a dynamic remote attestation facility in working order.
For context, we provide a brief overview in this chapter of remote attestation techniques discussed in the research community, including reference implementations where available. Please note that, other than Integrity Measurement Architecture, none of the schemes has seen wide adoption, if any at all.
Integrity Measurement Architecture
Integrity Measurement Architecture (IMA) is a classic static remote attestation model developed by IBM1 for measurement and reporting of the integrity of Linux-based systems. It takes a hash of the binaries of the software code that run on any system, and compares them against known-good hashes to assert that the system is high integrity. IMA extends the trusted boot process of the TCG beyond the bootstrapping of the Linux loader, to the chain of trust from the TPM, to applications running on the system. Through extensions to the kernel of the Linux system, IMA measures the code that’s loaded into memory for execution by taking a SHA-1 hash of the code prior to that execution. A measurement archive is maintained for measurements previously taken.
Integrity Measurement Architecture was the first practical implementation of a TCG-based remote attestation technique. It allows a challenger to verify a platform status by measuring the executables running on that platform. IMA forms the basis for many remote attestation techniques that followed the original implementation. The requirement for using IMA is to download a kernel patch from IBM. The prototype of IMA was implemented as a Linux Security Module on RedHat 9.0 Linux distribution and kernel version 2.6.5.
Policy Reduced Integrity Measurement Architecture
Policy Reduced Integrity Measurement Architecture (PRIMA) is a variation of IMA. According to the authors of this architecture,2 the static code and load-time measurement cannot be used to assess the run-time behavior. This architecture introduces the concept of measured security context or label of the subject, in addition to static code. The code/data digest also includes a role field so that additional identification of subjects and objects can be done. This approach allows remote attestation to be made on the basis of secure information-flow models. The approach is rather low level and cannot be used for distributed services in an organization or the information flows that occur within the organization and in outside world. There are no known implementations in a commonly available operating system environment.
Semantic Remote Attestation
Semantic Remote Attestation is an attempt at creating a platform-independent remote attestation technique.3 The core idea is that of a trusted virtual machine (TVM) capable of enforcing the requirements for those applications running within this virtual machine. The model establishes trust on the TVM and uses this trust to enforce security requirements. It attempts to measure the behavior of the code running inside a trusted virtual machine. The architecture is an incremental improvement over the original remote attestation techniques and is more flexible compared with binary attestation techniques with regard to expressiveness. This model of attestation has not been implemented, or at least published, owing to the complexity of defining and analyzing the notion of trust.
The Attestation Process
Given the discussion in the above section about the state and maturity of attestation techniques, let’s look at the details of the static attestation protocol and the overall integrity measurement flow.
The integrity measurement flow describes the steps required to measure the platform integrity measurements. It includes:
Figure 4-1 illustrates the attestation protocol providing the means for conveying measurements to the challenger. The endpoint attesting device must have a means of measuring the BIOS firmware, low-level device drivers, operating system, virtual machine monitor components, and be able to forward those measurements to the attestation authority. The attesting device must do this while protecting the integrity, authenticity, nonrepudiation, and some cases, the confidentiality of those measurements.
Figure 4-1. Remote attestation protocol
Let’s walk through the steps of the remote attestation protocol:
This protocol is highly resistant to replay attacks, tampering, and masquerading.
How does this remote attestation protocol get implemented and manifested in an IT environment? Figure 4-2 illustrates a sample IT architecture supporting the generation, forwarding, and analysis of platform boot integrity measurements, as well as assertion of the trustability of the attestation at each decision point via a trust assertion authority, or TAA. These solutions come from a set of compatible components available from a variety of suppliers.
Figure 4-2. Trust attestation authority
Flow for Integrity Measurement
In assessing the measurements, the TAA references a set of properties. These properties represent attributes and measurements for the BIOS and the operating system and virtual machine monitors. These measurements are referred to as golden measurements or whitelists, and are:
The process for carrying out the integrity measurement and verification is as follows:
A First Commercial Attestation Implementation: The Intel Trust Attestation Platform
To provide a path toward broad use of trusted compute pools and to exemplify the vision of trusted infrastructure and cloud computing, Intel developed a remote attestation solution capable of working across a broad range of hardware and operating system and virtual machine monitor platforms: the Intel Trust Attestation Platform (TAP). The goals of the Intel Trust Attestation Platform are threefold:
Figure 4-3 captures the high-level architecture of the Intel Trust Attestation Platform. Consistent with the cloud approach, the Intel Trust Attestation Platform features a loosely coupled architecture with a flexible software backplane and fabric with core capabilities and services, including a set of slots to plug in various attestation blades for different types of attestation provided by Intel and third-party independent software vendors. Here are the key aspects of the architecture:
Figure 4-3. Intel Trust Attestation Platform
Mt. Wilson is the code name for the Intel Trust Attestation platform that has the TPM-based boot attestation functionality. It is the first attestation blade that was released as part of the attestation platform. Mt. Wilson provides a secure mechanism for customers and data center operators to attest the integrity of Intel-based systems enabled with Intel’s Trusted Execution Technology (TXT) for RTM, along with third-party trusted platform modules (TPMs). The TPM stores and reports the platform measurements, including BIOS firmware and hypervisor software on servers. The architecture of the blade, described in more detail later in this chapter, is applicable to any TPM-based integrity measurement and reporting architecture.
We have assembled proof of existence working prototypes of a boot integrity attestation blade with Microsoft Windows 8, and corresponding TPM using a BIOS boot block as the RTM. We also have constructed a proof point with Citrix XenClient XT using Intel TXT on the client. A subset of the Mt. Wilson functionality has been shared with the open-source community under the name Open Attestation (OAT).
Mt. Wilson is a fast-evolving platform with new features and capabilities developed and released as the community gains experience with the technology. Here is a snapshot of key capabilities in the current Mt. Wilson solution.
Table 4-1. Mt. Wilson Key Capabilities
Attestation Support |
PCR and module-based attestation and verification for VMware ESXi 5.1 and above, and for Xen, KVM with RHEL, SuSE, and Ubuntu Linux |
APIs |
REST interfaces for query, reporting, management, and provisioning functions; REST interfaces for whitelist definition and management |
Security |
Digest-style API authentication and validation using RSA keys (<signed http authorization header >) SAML-based API responses with signed SAML assertions SSL communication and mutual authentication of communication endpoints |
Auditability |
Secure logging of requests, responses, transactions for auditability, forensics including logging APIs, and support for CEF format for consumption into SIEM tools |
Deployability |
Automated installation of host trust agents and all Mt.Wilson components Solution validation with Hewlett Packard, Dell, Cisco hardware, etc. |
Availability |
Deployed as Xen/KVM/VMW, virtual machines including high availability and fault tolerance for key components for VMware |
Automation and Productivity Tools |
API client: utility wrapper code for API invocation and response processing Reference integration with OpenStack extensions to flavors, dashboard, scheduler Reference trust dashboard with API integration with Mt. Wilson |
The rest of this chapter will provide a comprehensive view of this attestation blade, starting with the architecture and design components to support server operating systems and virtual machine monitors, followed by the core attestation related API definitions and security considerations. Sample source code examples are provided in the last section of this chapter to show how to:
Mt. Wilson, as shown in Figure 4-4, has two main components: the trust agent (TA) and the trust attestation authority (TAA.)
Figure 4-4. Mt. Wilson architecture
The trust agent runs on the device or host that is attesting with the trust attestation authority. The trust agent is the collector, and securely uploads the integrity measurements (fetched using the TPMQuote command) and the integrity event log from the TPM. The trust agent is not required in a VMWare environment, since vCenter provides specific APIs (called TrustAttestationReport) and capabilities that provide the functionality. More specifically, vCenter Agent and VMWare vCenter Server enable the necessary handshake, verification of the platform certificates, and invocation of the TPM commands, in response to any entity invoking the TrustAttestationReport web services API.
The trust attestation authority is the core attestation and assessor with a number of key services:
In the next section, we drill into the attestation server and understand the functions and the attestation process flows.
The Mt. Wilson Attestation Process
Figure 4-5 illustrates the attestation architecture in Mt. Wilson, with a drilldown of the attestation server component described in the previous session and depicted in Figure 4-4. The Mt. Wilson attestation process comprises three flows:
Figure 4-5. The Mt. Wilson attestation architecture
Attestation Identity Key Provisioning
The attestation identity key provisioning process is done in four steps.
Host Registration and Attestation Identity Key Certificate Provisioning
Figure 4-6 depicts the sequence diagram showing the steps for host registration and the management of attestation identity key certificates. As mentioned earlier, these steps are applicable only for hosts running on Xen or KVM.
Figure 4-6. Flow of authority identity key certificate provisioning
This is the invocation of the trust APIs by an entity requesting trust information. The API request is authenticated and the input parameters are validated and then handed to the appraiser component of the attestation server. The appraiser follows the remote attestation protocol to challenge the platform for the integrity measurements. Once the verification is done, Mt. Wilson summarizes all these steps by generating a SAML assertion of the platform compliance with its trust policy. Details of the SAML assertion and the security and integrity of the exchange are covered later in this chapter.
Security of Mt. Wilson
Security is integral to the Mt. Wilson platform. The ultimate objective of an adversary of Mt. Wilson would be to subvert and control the outcome of the attestation by:
Figure 4-7 shows the threat model considered during the design of Mt. Wilson, with articulation of the consequences when the adversary accomplishes the attack and possible mitigations implemented. We summarize the mitigating actions against the threats listed above.
Figure 4-7. Mt. Wilson threat analysis
Mt. Wilson Trust, Whitelisting, and Management APIs
Mt. Wilson provides a rich set of APIs for all interactions with it. In fact, the primary communication with the Mt. Wilson attestation authority is via authenticated APIs. There are five categories of APIs:
Calls to the API must be sent over SSL TLS. All APIs are REST-based. Mt. Wilson APIs use a client-server model without third-party intervention to provide authentication. The authentication model is very similar to OAuth 1.0 and HTTP Digest, and it provides a stateless scheme for use with clusters and load balancers. However, it does not work with URL-rewriting proxies because the URL is covered by the client’s signature. Every API client—that is, any entity invoking the APIs, such as portals, schedulers, other subsystems or policy engines—needs two RSA keys, as follows:
Figures 4-8 and 4-9 show the core APIs for the Mt. Wilson provisioning and trust query API and the management and whitelisting API.
Figure 4-8. Provisioning and trust query API
Figure 4-9. Management and whitelisting API
To facilitate interoperability, consistency, and seamless integration, we expect the industry to converge toward a standardized set of APIs related to attestation. We offer these as a starting point for the industry to help drive interoperability across different attestation solution implementations.
All API calls are http requests with one required header: “Authorization: X509 <authentication-info>”. Any unauthorized request is challenged with a standard header: “WWW-Authenticate: X509 <challenge-info>”.
Each API request includes the following parameters:
Figure 4-10 is an example of a sample API request using authentication.
Figure 4-10. API request including authentication
API Response
Mt. Wilson asserts all API responses. Responses are signed SAML assertions. Assertions are signed with the Mt.Wilson RSA SAML signing key. There is one SAML signing key for each installation of Mt.Wilson. An API client validates the signature with the SAML public key and uses the trust information. Here is an example of an API invocation with a SAML assertion. This Java example uses the Apache HttpClient library to obtain the SAML assertion for “192.168.1.121” by sending a GET request to Mt. Wilson:
ApiClient api = KeystoreUtil.clientForUserInDirectory(directory, username, password, server);
String samlForHost = api.getSamlForHost(new Hostname("192.168.1.121"));
Here’s how to interpret the SAML response:
TrustAssertion trustAssertion = api.verifyTrustAssertion(samlForHost);
if( trustAssertion.isValid() )
for(String attr : trustAssertion.getAttributeNames())
System.out.println("Attr: "+attr+":"+trustAssertion.getStringAttribute(attr));
Attributes for subject’s trust status in the SAML response are:
Attributes for subject’s measured launch environment in the SAML response are:
BIOS_Name, BIOS_Version, BIOS_OEM, VMM_Name, VMM_Version, VMM_OSName, VMM_OSVersion
There are two options for the requesters of attestation information to call into Mt. Wilson APIs. A direct invocation of the REST APIs is the most basic approach to use and integrate with Mt. Wilson. The user is required to implement the complete API request specifications. This would mean pre-processing the creation and handling of keys and authentication, and post-processing of information for a successful API invocation, and the correct processing of the responses. An API toolkit (called API Client Library) is available to simplify the invocation of the APIs, with bindings for different languages like Java, C#, and Python. This toolkit encapsulates multiple API calls, creation and handling of RSA keys and certificates, and authentication and processing of API responses (which are SAML signed assertions). Using this toolkit, the users can make Java (or C# or Python) function calls to communicate with the system. The sample code and examples that are used in this chapter use the Java binding of the API toolkit.
There are three different options for the .jar file:
Deploying Mt. Wilson
There are multiple models for deploying attestation components in a data center. Ideally, attestation is transparent to applications, carrying its function quietly in the background. In practice, it’s far from that. How unobtrusive attestation technology is depends upon the deployment method. Some of the possible models include:
Mt. Wilson is delivered today as a virtual appliance, and it is being integrated into security software applications such as HyTrust’s Cloud Control, as well as cloud management software such as Virtustream’s xStream. An initial approach for adoption is to package and deliver Mt. Wilson software as a separate appliance with cloud management and security management independent software vendor offerings. As the usage and experiences increase with increased design and development of attestation-based solutions, other models with tighter integration will become possible.
As attestation APIs become standardized and integral to the interactions and operations of a trusted cloud infrastructure, there is opportunity for providing value-added services on top of the core attestation APIs. This could lead security management and cloud service providers to offer attestation as a service, with granular control to the usage and evolution of the APIs.
Mt. Wilson Programming Examples
In this section, we look at how to invoke the attestation APIs to get trust information about a server in a data center. Figure 4-11 shows the high-level steps involved in setting up the system and configuring it for use.
Figure 4-11. Mt. Wilson high-level programming steps
After the installation of the Mt.Wilson server and trust agent on the hosts, required only for Xen or KVM hosts, users need to include the .jar file provided as part of the API toolkit in their project and import the following packages:
import com.intel.mtwilson.*;
import com.intel.mtwilson.crypto.*;
import com.intel.mtwilson.datatypes.*;
import java.io.File;
import java.net.URL;
API Client Registration Process
Before the user can make any API calls into the system, the user has to register and the access has to be approved. Below are steps for how to register with Mt. Wilson and how to make API calls after the registration has been accepted. The following code creates a keystore “test1.jks” in the home directory. The keystore contains an RSA keypair that is used to authenticate the API calls to the system. The keystore would also contain the Mt. Wilson SSL certificate and SAML signing certificate, which are downloaded from the server.
File directory = new File(System.getProperty("user.home", "."));
String username = "test1"; // you choose a username
String password = "changeit"; // you choose a password
URL server = new URL("https://mtwilson.example.com:8181"); // attestation server
String[] roles = new String[] { "Attestation", "Whitelist" };
KeystoreUtil.createUserInDirectory(directory, username, password, server, roles);
After the request is created, the user has to contact the system administrator to approve the access request (offline step). After the request is approved, based upon the roles the user has, appropriate APIs can be executed, such as maintaining a whitelist, adding hosts, and obtaining a trust assertion on one or more hosts.
To use the API, the user needs first to create an ApiClient object configured with the credentials and the attestation server. Notice that the variables directory, username, password, and servers are the same as what was used during registration.
File directory = new File(System.getProperty("user.home", "."));
String username = "test1"; // username created during registration
String password = "changeit"; // password created during registration
URL server = new URL("https://mtwilson.example.com:8181");
ApiClient apiClientObj = KeystoreUtil.clientForUserInDirectory(directory, username, password, server);
Once an APIClient object is created, the user can use that to configure whitelists and also to register the hosts with Mt. Wilson so that they attest when challenged.
Whitelisting and Host Registration
Here’s some sample code for how to create a whitelist and register the host with Mt. Wilson—for VMware ESXi hosts:
TxtHostRecord gkvHostObj = new TxtHostRecord();
gkvHostObj.HostName = "hostname-in-vcenter";
gkvHostObj.AddOn_Connection_String = "vmware:https://vcenter.example.com:443/sdk;Username;Password";
boolean configureWhiteList = apiClientObj.configureWhiteList(gkvHostObj);
boolean registerHost = apiClientObj.registerHost(gkvHostObj);
Verify Trust: Trust Attestation
Once hosts are registered with Mt Wilson, it is now possible to request a trust assertion in SAML format using getSamlForHost. You can verify the signature on the assertion and get easy access to the details using verifyTrustAssertion.
Note If you are directly calling into the REST APIs, you have to implement the verification of the SAML assertion using the SAML certificate that needs to be downloaded explicity. The API toolkit downloads this certificate as part of the registration itself.
String samlForHost = apiClientObj.getSamlForHost(new Hostname("hostname-in-vcenter"));
TrustAssertion trustAssertion = apiClientObj.verifyTrustAssertion(samlForHost);
if(trustAssertion.isValid()) {
for(String attr : trustAssertion.getAttributeNames())
System.out.println("Attr:"+attr+":"+trustAssertion.getStringAttribute(attr));
}
As shown in this above example, using the API Client Library is a very simple way of using the Mt. Wilson attestation mechanism. The Mt. Wilson software is being licensed by many ISV and CSPs to integrate trust into the software and service offerings. More and more organizations are moving to clouds, and they are asking for assurance of trust of the platform on which their workloads are running; they are also asking the CSPs to provide proof of a chain of trust. The attestation solution is fast becoming a critical security component in the security toolset. For developers favoring a DIY approach, the open-source OpenAttestation (OAT) is a good starting point for attestation.
Note OAT is the open-source version of Mt. Wilson code, and is provided and maintained by Intel Corporation. You can download the documentation, code, and installation/deployment scripts from the OAT website.
Summary
In this chapter we covered attestation as a foundational function of trusted computing environments that provides proof of trustability and auditability of trust for various computing devices. We covered the TCG remote attestation protocol, and we described the vision and architecture of Intel’s Trust Attestation Platform, followed by a detailed look one of the first attestation solutions, called Mt. Wilson. The chapter reviewed the security architecture and the attestation APIs, and explained how requesters of trust and attestation information can invoke these APIs and process the assertions for decision making. There are many usages in data centers that would utilize the attestation information. As shown in the previous chapter, attestation is used in the creation of trusted compute pools and the attestation-based policy enforcement in these pools. Thus, attestation can be used to provide granular trust-based access control to consumer and BYOD devices, and the kind of services they can access within the cloud data centers. Attestation as a security management component will become an integral component of virtualization and cloud management, and it’s becoming a critical requirement in cloud data centers to assert the integrity and compliance of platforms and systems. ISVs and security management vendors may also start offering it as a SaaS offering. We believe that, over time, value-added capabilities will emerge around the attestation function and will enable monetization possibilities.
Chapter 5 will introduce a new concept and control, called hardware-assisted asset tag, which can be used to provide isolation, segregation, placement, and migration control of workload execution in multi-tenant cloud environments. Additionally, as a specialization of asset tags, geolocation/geo-tagging can be enabled to definitively provide increased visibility to the physical geolocation of the server, which may enable many controls that require hardware-based roots of trust to assert the location of workloads and data. These attributes and the associated controls are dependent on the boot integrity assertion of the platform; hence, they become a great adjacency to trusted compute pools and boot integrity.
________________________
1See http://researcher.watson.ibm.com/researcher/files/us-msteiner/ima.sailer_usenix_security_2004_slides.pdf
2Trent Jaeger et al., “PRIMA: PolicyReduced Integrity Measurement Architecture, SACMAT2006, June 7–9, 2006, Lake Tahoe, California. ACM 1595933549/06/0006.
3Vivek Haldar et al., Semantic Remote Attestation: a Virtual Machine Directed Approach to Trusted Computing, VM2004 Proceedings of the 3rd conference on Virtual Machine Research and Technology Symposium, vol. 3 (Berkeley, CA: USENIX Association).