Intel Trusted Execution Technology for Server Platforms

Front matter

Intel® Trusted Execution Technology for Server Platforms

A Guide to More Secure Datacenters

William Futral and James Greene Forewor d by Albert Caballero, CTO, Trapezoid

Introduction

While there are numerous papers and other forms of documentation on Intel? Trusted Execution Technology

(Intel? TXT), most of them focus on helping the platform designer and operating system vendor (OSV) implement the technology on a hardware or software platform. There are, however, a small amount of engineering, marketing and positioning materials that focus on the outcome or the use of the technology that would be helpful to an IT professional. Often though, these materials are more objective than subjective. That is, they tell the designer or implementer what they can do, but not necessarily what they should do, or why they would want to select one option over another. In the practice of making real use of new technologies, this gap creates a problem.

Our experience has shown that when a platform arrives at the datacenter, there is typically very little information to guide the system administrator to make the best use of new capabilities such as Intel TXT. While Intel is well versed in collaborative dialog with our core audience of platform architects, OS architects, and software developers regarding implementation details, the Intel TXT enablement experience exposed us more forcefully to a new audience--and a new opportunity. We continually get questions from IT managers and cloud solutions architects wanting to know how this technology is and should be employed, in order that they can evaluate which options they should implement in their own environments. Hardware and software designers are also inquisitive about how the datacenters deploy the technology, what issues they face, and which features are important to them.

Thus it was obvious that there needs to be a book to provide a more complete picture, starting with why the technology is important, what the hardware does, and then work its way up the stack specifying the roles of the OEM, datacenter, OSV, and ISV. In short, our goal became: create a book that takes the mystery out of this new technology-- from architecture to deployment. This publication also allows us the opportunity to raise visibility for emerging threats, while being in the envious position of being able to raise awareness of solutions based on products that our core audience is quite likely already buying (such as Intel TXT enabled servers and operating systems or hypervisors). Happily, we can also help note that solutions based on this technology are also integrated or enabled at “trivial” extra costs such as the 530-50 cost of adding a TPM module to some OEM servers. In short, these solutions are really near at hand, it is just a matter of getting the word out and helping show the methods and benefits!

This book provides a comprehensive guide for the datacenter as well as providing additional contextual insight for the platform and software suppliers. Thus the first half of this book explains what the technology does and why it works, explains how attestation works, discusses the value of various features, and walks the reader through the process of enabling the technology, creating launch policies, and selecting the best policy for the datacenter. And it does so in the context of explaining what choices are possible and the key considerations behind them. In short, the first half is largely about implementation--the “what” and “how” of Intel TXT.

The second half of this book is designed to provide an overview of the big-picture “why” of implementing Intel TXT. It focuses on the use models--what operational, security and business benefits can be derived from using it? It focuses on the ecosystem requirements—the key hardware, software and services that are needed today and in the future--to make use of Intel TXT in the cloud or enterprise. These discussions are intended to help the IT administrator or enterprise security architect assess the capabilities of the technologies and dependencies of the use models against their business needs. And it closes with a discussion of the future.

No IT manager or architect wants to dedicate their time and resources to build or deploy a one-off solution.

It is essential to not only explain the capabilities (and limitations) of today, but to provide insight into where this foundation may lead and how that may also map into rapidly evolving business needs. The intention here is to help IT and security leaders identify and establish new opportunities to solve security challenges of today, and also position themselves to use enhanced security capabilities to more fully enable and drive the enterprise of the future.

xix

INTRODUCTION

Intel TXT is being deployed today by companies across the globe and in many industries. Are they undertaking wholesale “ripping and replacing” of IT infrastructure to gain the protections and capabilities enabled by Intel TXT? Absolutely not. That is not how IT works. No, instead they are deploying their new server installations with Intel TXT activated and built and targeted to key visibility, control and compliance use models—typically for their cloud infrastructures. In effect, they are establishing new, more secure pools within their existing infrastructure that are more suitable for hosting their more sensitive or regulated workloads. This type of optimized deployment model is also a well-worn IT practice for targeting resources and utilizing the optimal platform to host them.

These earlier adopters are gaining hard-earned benefits today and setting the stage for a more secure future for their businesses. They are learning much from this process as they pioneer solutions even as the market and technologies mature (and in fact they help shape the direction of the maturation by working with Intel and others to implement these solutions). Our objective with this book is to help share the groundwork of experts and pioneers and to lower the barriers to implementation so that these trust-based solutions can deliver value much more broadly through the industry.

XX

Introduction to Trust and Intel?

Trusted Execution Technology

Every contrivance of man, every tool, every instrument, every utensil, every article designed for use, of each and every kind, evolved from very simple beginnings.

- Robert Collier

Intel? Trusted Execution Technology (Intel? TXT) is a technology that uses enhanced processor architecture,

special hardware, and associated firmware that enable certain Intel processors to provide the basis for many new innovations in secure computing. It is especially well suited for cloud computing and other uses where data integrity is paramount. Its primary goal is to establish an environment that is known to be trusted from the very start and further provide system software with the means to provide a more secure system and better protect data integrity. This is essential in that if the platform cannot be protected, then the data it will store or process cannot really be protected. At a minimum, this technology provides discrete integrity measurements that can prove or disprove a software component's integrity. These software components include, but are not limited to, code (such as BIOS, firmware, and operating system), platform and software configuration, events, state, status, and policies.

By providing a hardware-based security foundation rooted in the processor and chipset, Intel TXT provides greater protection for information that is used and stored on servers. A key aspect of that protection is the provision of an isolated execution environment and associated sections of memory where operations can be conducted on sensitive data, isolated from the rest of the system. Likewise, Intel TXT provides for sealed storage where sensitive data such as encryption keys can be securely kept to shield them from being compromised during an attack by malicious code. Attestation mechanisms verify that the system has correctly invoked Intel TXT to make sure that code is, in fact, executing in this protected environment.

This book describes how this technology can benefit the datacenter, and it specifically addresses the concerns of the cloud service provider and the cloud service client. The goals of this book are as follows:

e To explain what this technology does and its underlying principles

e To describe the roles and responsibilities for enabling and using this technology

e To guide the system administrator in establishing the right launch control policy e To discuss how software (local and remote) can take advantage of this technology e To look at some current and future innovations and how they apply to public and private clouds

Clearly these are important topics, so let’s get started!

CHAPTER 1 ™ INTRODUCTION TO TRUST AND INTEL® TRUSTED EXECUTION TECHNOLOGY

Why More Security?

Intel Trusted Execution Technology is relatively new for servers. It was initially developed for desktop and mobile computing platforms. It first debuted in servers in 2010 as attacks on datacenters started to escalate and calls for platform hardening formalized. For quite some time, server platforms were thought to be immune from attacks because they are typically kept in secure rooms and managed by highly skilled professionals. That is no longer sufficient. The frequency of attacks against datacenters is growing at astounding rates and those attacks are increasingly likely to have come from organized crime, corporate competitors, or sponsored by foreign governments with very sophisticated methodologies and deep resources.’ Corporate executives worry that a breach could be

very costly—both socially and economically, in the face of new regulations and stiffer penalties for failing to protect personal information.

Andy Grove, one of the Intel’s founders, wrote the book Only the Paranoid Survive (Doubleday Business, 1996). This book is about recognizing inflection points and taking action. Server security is definitely at one of those inflection points. A successful attack could do significant damage to a company, regardless of whether that company is providing the service or using it—especially if adversaries can demonstrate that the company failed to use available security precautions. But it doesn’t even take a successful attack. Just the failure to use available security precautions, or to make them available to your customers, could do irreparable harm.

Furthermore, this need for vigilance and caution doesn’t only apply to business environments. The individual making online purchases, retail companies using cloud computing services, and cloud service providers all want more assurances that transactions and data are protected.

The answer is a higher level of security, better ability to mitigate attacks, and the means to prove those capabilities are enforced. Intel Trusted Execution Technology (or Intel TXT) can now be a significant part of that solution.

Types of Attacks

Bad people do bad things for all sorts of reasons. Some try to prevent use of the platform (denial of service, a.k.a. DoS attacks), some want to destroy or corrupt data, and others want to steal data. They will attack data in flight, at rest, and in use.

Data-in-flight refers to the transmission of data from one place to another. Using a secure channel that encrypts data during transport helps defend against in-flight attacks, but one also has to make sure that the recipient is the intended recipient and guard against replay attacks and the man-in-the-middle attacks. A replay attack is where an attacker intercepts a transmission and resends a copy of that transmission at a later time to fool the recipient into thinking it came from an authorized source portraying a real transaction. The man-in-the-middle attack is where an entity inserts itself into the communication link, forwarding transactions between the two endpoints, and thus gaining access to the privileged information. For this case, entity A starts a session with the attacker (the “man in the middle”) thinking it is a session with entity B. The attacker then starts a secure session with the intended entity B, claiming it is entity A. The attacker is now able to steal or modify the data being transmitted between A and B.

Data-at-rest refers to the storage of data. Encrypting the data before storing on disk is a growing practice, but it also requires protection of the encryption keys. One answer is sealing of data, such as keys, so that it can only be used by authorized agents. But again, this raises the question of who to trust and how to prevent untrusted entities from gaining access.

‘Example from the US Federal Bureau of Investigation (FBI), November 2011, http://www. fbi. gov/news/stories/2011/ november/malware 110911.

CHAPTER 1 ™ INTRODUCTION TO TRUST AND INTEL® TRUSTED EXECUTION TECHNOLOGY

Data-in-use refers to the data being manipulated by the application. Applications typically work on unencrypted data, so an attacker gaining access to that data circumvents any transport or storage protections. These attacks come from many different directions and target various components and operations. For example:

e Frontal attack: A direct attack on a system operation, generally by modifying or corrupting the system code or tricking the system.

e Flanking: Reset attacks have proven effective. This is where an attacker forces a reset after it has manipulated the BIOS to boot malicious software, which then inspects secrets and other privileged information that remain in memory.

e Spying: Root kits are an example of where an attacker causes the platform to boot malicious code that uses the platform's virtualization capabilities to then load the expected operating system in a false virtual environment. The system software is unaware that it is in a virtual environment and the root kit is now in control of the platform and has access to everything that the system places in memory.

A successful defense not only requires mechanisms to protect data, but also the means to detect changes and establish trust in the platform.

What Is Trust? How Can Hardware Help?

For most people, trust means that you have faith in someone or something to do the right thing. A broader definition would be “faith in someone or something to do something consistently.” For instance, one might say that they “trust” that a computer virus will do harm—but they don’t “trust” the virus. Generally, we trust the operating system to protect data and system resources, but we don’t trust an operating system that has been infected with a virus or influenced by other malicious code. The challenge is to tell the difference.

Can we trust the system to determine if it is trustworthy? If you were to ask anyone if they can be trusted, they will likely respond “yes” —especially criminals. The same holds true for software, especially malicious software. To trust software, we need the ability to verify it in a way such that any change to the software changes its credential. For instance, if an operating system can prove that it is an authentic version and has not been modified, it deserves more trust than one that cannot. In fact, knowing that software has been modified is also valuable—because it allows corrective action such as quarantine and repair.

Thus we cannot depend on the software itself to detect if it has been modified (for example, infected with malicious code), because the malicious code might control or block the module that makes the trust decision.

Thus we look to hardware to help make that determination.

The industry's leading security experts formed a nonprofit industry initiative known as the Trusted Computing Group’ (TCG) to enhance trust and therefore security on computing platforms. The charter of the TCG is to develop industry standards for trusted computing building blocks and define their use for various platform types. Their efforts have produced a specification for a special security component (called a Trusted Platform Module, or TPM) and specifications for how to use that module in PCs and servers. These documents are available from the TCG web site (www. trustedcomputinggroup. org/). Several companies produce TPM chips that comply with these specifications, specifically for use on PCs and servers. The TPM chip is a very secure device that provides a number of security functions, and it is implemented in systems according to the TCG specifications by your favorite server manufacturers.

“http://www. trustedcomputinggroup.org/

CHAPTER 1 ™ INTRODUCTION TO TRUST AND INTEL® TRUSTED EXECUTION TECHNOLOGY

A TPM chip is also one of the base components of Intel TXT, and provides the means to securely measure software components such as firmware, platform configuration, boot code, boot configuration, system code, system settings, and so on, to form a set of credentials for the platform components and system software. It also provides for accurately using those measurements as proof of trust and the ability to protect those measurements.

The measurement process for Intel TXT starts with hardware (that is, microcode designed into the Intel processor) and uses hardware (special chipset registers) to start the measurement process and store the measurements in the Trusted Platform Module chip in a way that cannot be spoofed by software.

What Is Intel? Trusted Execution Technology?

Intel TXT uses a combination of hardware, firmware, and software, and is built on and fully compliant with the Trusted Computing Group PC Client and Server specifications.

In general, Intel TXT is:

e A collection of security features. e A means to verify that those features are in use. e The means to securely measure and attest to system configuration and system code.

e Ameansto set policies to establish a trust level based on those measurements. Based on those policies, it is a means to:

- Invoke enhanced capabilities (secure mode) for systems that meet that policy. — Prevent a system that fails the policy from entering the secure mode.

— Determine if the system has entered the secure mode environment.

e The means for a trusted OS (that is, the system operating in the secure mode environment) to provide additional security features.

The ultimate goal of Intel TXT is to provide a more secure and hardened computing environment, but it is not a means to an end. Rather it is a tool for achieving higher levels of trust, and that trust does not come from simply enabling Intel TXT. The platform owner (e.g., datacenter IT manager) plays a key role in establishing what trust means, and Intel TXT provides the flexibility so that the system administrator can create a trust policy to match the requirements of the datacenter. Servers that implement Intel TXT can demonstrate (attest) that they comply with a specific trust policy, and thus can be used to form pools of trusted servers based on the established trust policy. Servers without Intel TXT and those that don’t meet the trust policy can be excluded from the trusted pools. With the right policies in place, the datacenter can provide trusted pools of servers, allowing service clients to create “use policies” depending on the trust level. One example of this is the ability to confine critical applications (such as e-commerce services processing credit card information) to run only within a trusted pool. This has many applications for both private and public cloud providers, as well as their clients.

Before one can create a trust policy, it is important to understand what Intel TXT does and does not do. To put it in perspective, if we look at a bank’s security, we find multiple security methods in use (locks on the doors, bars on the windows, a security alarm system, a surveillance system, a vault, armed guards, and so on). This is defense in depth and implies that no one method can do it all and that various methods come into play at different times (for example, doors and vaults tend to be unlocked and portions of the security alarm system are disabled during banking hours when armed guards are present). Of particular interest is to note that some of the methods are to prevent intrusion and others are just to detect and report it. The same is true for computer security; knowing when a breach has occurred is very important—just as a bank manager would not open the vault until he knows the bank is secure, Intel TXT can be configured to only allow the OS to launch if it knows the platform and system software are secure and trusted (as defined by the datacenter’s policy). This secure launch allows the software to operate as a trusted OS, but only after validating that the platform configuration and system software meet the datacenter’s policy.

CHAPTER 1 ™ INTRODUCTION TO TRUST AND INTEL® TRUSTED EXECUTION TECHNOLOGY

So how do we define secure in this context? The short answer is to make sure that the system software is using all of the protection afforded by the processor and chipset architectures.

And how do we define trusted? The answer requires a means to measure the platform and the software. For servers, Intel TXT does that by incorporating two TCG concepts—a static chain of trust and a dynamic chain of trust, as illustrated in Figure 1-1. The static chain of trust measures the platform configuration, and the dynamic chain of trust measures the system software, software configuration, and software policies.

n Static Chain of Trust Dynamic Chain of Trust ower

ON Measure Boot Measure Verify Platform Measure SBIOS Measure Trusted Meets Trust Policy F i OS Code & Validate Code 7 & Validate Additional ACM Additional Measurements ACM Measurements

-> Loader

Security Checks

Lock Configuration

Figure 1-1. Intel® TXT launch timeline with static and dynamic chain of trust

Static Chain of Trust

The static chain of trust measurements start when the platform powers on. It starts with microcode that is embedded in the processor measuring an authenticated code module (ACM) provided by Intel. The ACM is a signed module (whose signature and integrity is authenticated by microcode) that performs special security functions. The ACM measures a portion of the BIOS code. That code then measures the remainder of BIOS code and configuration. Note that BIOS code does not execute until after it has been measured. These measurements are stored in special platform configuration registers (PCRs) inside a TPM (remember that the TPM is a very secure hardware device specified by the TCG). Different PCRs hold different launch component measurements (as specified by the TCG). During this process, the BIOS is required to turn on certain security features, and then call a function in the ACM that performs a security check. Before the BIOS executes any additional code, such as option ROMs on third-party adapters, it must lock the platform configuration by calling the ACM again, which performs additional security checks, and then locks certain platform and processor registers. The BIOS also measures the Master Boot Record (MBR) and the OS Loader when it boots the operating system.

The main takeaways are that measurements are started by hardware, measurements are protected from tampering by the TPM, and code is measured before it is executed.

These “static” measurements are done only once, each time the platform powers on. These measurements are referred to as platform configuration measurements.

Dynamic Chain of Trust

The dynamic chain of trust starts on request by the operating system (OS) via a special processor instruction, which measures and verifies another ACM (the SINIT ACM), which will oversee the secure launch. The SINIT ACM performs additional checks, which include making sure the BIOS passed its security checks and has locked the platform configuration. The ACM then measures the OS (actually a portion of the OS referred to as the trusted OS) and invokes

CHAPTER 1 ™ INTRODUCTION TO TRUST AND INTEL® TRUSTED EXECUTION TECHNOLOGY a launch control policy (LCP) engine that will determine if the platform configuration and OS will be trusted (as defined by the policy set by the system administrator).

A trusted OS (a term used by the TCG for system code that invoked and passed the secure launch process—proving it meets the launch control policy) is allowed access to additional (privileged) security functions, including using additional PCRs. The trusted OS can measure such things as additional code, data, and configuration into those PCRs, and use the content of any of the PCRs to make trust decisions and seal/unseal data. Applications (both on and off the platform) can also use those measurements to make trust decisions.

Virtualization

Intel TXT works equally well for both virtualized and nonvirtualized platforms. In the course of bringing Intel TXT to market, the feedback has been quite strong that the primary and most compelling usage model for Intel TXT

on servers is with virtualized and cloud-based server systems. This is generally because it addresses some of the key challenges introduced by moving to shared infrastructures. Specifically, it provides the ability to better control applications (in the form of virtual machines) and migration of applications among available platforms (the cloud) based on host trustworthiness. In other words, high availability and optimum utilization is achieved by migrating applications to available servers while still maintaining a trusted environment.

The term OS for a server platform can be confusing because of the existence of multiple operating systems on a virtualized host platform. This book uses the term host OS to refer to a hypervisor, virtual machine monitor (VMM), or in the case of a nonvirtualized platform, the traditional bare-metal operating system or any other application or utility that boots first. In any case, the host OS is the first system control program to boot. This is in contrast to an OS instantiated in a virtual machine (VM), which will be referred to as a guest OS. Furthermore, a trusted OS is a host OS that has successfully performed a secure launch. As a side note, while it is possible for the host OS to provide the same type of secure launch to its guest operating systems, that capability is outside the scope of the current version of Intel TXT and not discussed in this book.

OK, that last paragraph can be a little hard to read. So let’s try these definitions:

e OS: The system software that manages platform resources and schedules applications. This includes e Ahypervisor or virtual machine monitor that manages the virtual machines. e An OS that executes in a VM (i.e., the guest OS). e An OS executing on a nonvirtualized platform.

e Host OS: An OS that is not executing in a virtual machine, which can perform a secure launch, and thus can be measured by hardware (i.e., Intel TXT).

e Guest OS: An OS that is executing in a virtual machine, which is not measured by hardware.

e Trusted OS: A host OS that has performed a measured launch and passed the datacenter policy.

Measured Launch Environment

Because trust is a subjective term, Intel refers to the trusted OS as the measured launch environment (MLE), because Intel TXT certifies the measurement of the trusted OS (not its trust) and enforces the platform owner's policy—that is, it has measured the OS and platform configuration and verified that they meet the platform owner's launch policy. The measurements (i.e., the values in the PCRs) can be used by any entity to make a trust decision. For example, the platform owner can specify multiple OS measurements and platform configurations that will pass its launch policy, but an application can be more restrictive and trust only a subset. As we will see later, this concept can be extended and is the basis of attestation, which will be explained in detail later in this book.

CHAPTER 1 ™ INTRODUCTION TO TRUST AND INTEL® TRUSTED EXECUTION TECHNOLOGY

The host OS is allowed to enter and exit the measured launch environment without having to reboot the platform. To exit, the host OS simply invokes another special processor instruction that will reset the PCRs that were used to measure the launch and those that were set by the trusted OS. Of course, this action also curtails the host operating system’s access to some of the additional security resources. Reentering the secure environment restarts the dynamic chain of the trust process, and thus recalculates the MLE measurements storing them in those PCRs, allowing a different trusted OS (or different configuration of the same OS) to execute with its own set of trust credentials.

Finding Value in Trust

One of the nice things about Intel TXT is that its value can be appreciated by a number of different entities for various purposes. Some of these values have already been realized and there are many more to come.

Cloud Computing

Looking at a typical cloud management model, as illustrated in Figure 1-2, the cloud service provider maintains a pool of application servers, which hosts various applications provided by the cloud service clients. These applications are scheduled to run at times and locations to meet both provider and client polices.

Service Provider

CLOUD SERVICE

Dn CLIENT Server S Server 3 Server lpg Management Server Mg Services Server o z © | | Schedulin CLOUD Server = Scheduling SERVICE Server 2 CLIENT <x Server

Client Policy

Figure 1-2. Cloud management model

The service provider must be able to demonstrate that the cloud meets governing regulations, and provide an audit trail to assure the client that all client and government requirements have been meet.

CHAPTER 1 ™ INTRODUCTION TO TRUST AND INTEL® TRUSTED EXECUTION TECHNOLOGY

Because Intel TXT provides measurements of platform configurations and operating systems, adding Intel TXT to the picture allows the trust status of the application servers to enter into the equation. It allows both the service provider and the service client the ability to establish trust policies based on Intel TXT measurements and to identify servers that meet those polices, as illustrated in Figure 1-3.

Cloud Service Provider

Quarantined

Cloud Management Services

Scheduling Compliance

SERVICE CLIENT

Application Servers

Trusted Compute Pool

Client Policy

Figure 1-3. Cloud management trust model

Up till now, we have talked about measuring components, but the measurements themselves don’t prove anything, or do they? Actually, it is the combination of the components that are measured, how the measurements are made, how the measurements are stored, and how the measurements are accessed that provides the basis for attestation.

Attestation: The Founding Principle

Furthering our discussion of how a bank uses multiple security concepts, let’s focus on the banking transaction. Before executing a transaction, bank tellers require proof of the customer’s identity. In the United States, that would typically be a driver’s license or some other government-issued identification. State-issued driver’s licenses and IDs have evolved over the years. In 1960, a license was simply a piece of paper printed with the state seal and folded in half to about the size of a business card. Personal information such as date of birth, height, weight, color of eyes, and hair color were typed in the respective boxes on that form by the issuing agency. Needless to say, it was fairly easy to modify, and thus subject to abuse. To reduce misuse and fraud, states started laminating each license with