In the following pages, we take a close look at both the TPM and the UEFI. We then step through a trusted boot process showing how they help ensure safe user authentication and sensitive information processing. First, however, we need to define trusted computing.

Trusted computing

A trusted platform (e.g. desktop PC, server, laptop, etc.) possesses high assurance of operating as expected. In other words, trust is the characteristic of keeping data safe and accurate while delivering it where and when it is needed. For example, we can expect a trusted platform to prevent execution of malware and the retrieval of sensitive information by unauthorized individuals. However, trust does not always extend to all areas of a desktop or data center platform. For our purposes, a platform consists of two software attack surfaces (Chapter 5): firmware/drivers/boot loader and OS/applications. See Figure 8-1. Organizations can protect the high-level OS and applications with anti-malware (AM) solutions and attack surface reduction processes. However, the firmware, boot loader, and device driver layers are traditionally unprotected. Although AM vendors might claim to help prevent attacks against these software surfaces, evil maid attacks and Alureon variations are examples of how attackers can bypass anything other than a protected boot path. The UEFI, supported by a TPM, provides mechanisms to stop boot path threats from taking control.

Figure 8- 1: Software Attack Surface

Boot path security challenges

The boot path begins with BIOS load and ends with full initialization of the OS kernel. Figure 8-2 shows the conventional BIOS boot path.

Figure 8- 2: Traditional Boot Path (Cooper, Polk, Regenscheid, & Souppaya, 2011, p. 2-3)

In some BIOS implementations, an implicitly trusted BIOS boot block is the first firmware loaded. It checks the integrity of the remaining BIOS and might also serve as the core root of trust for measurement (CRTM). We discuss CRTM later in this chapter. The primary BIOS is loaded and optionally integrity-checked by the boot block firmware. The BIOS initializes key hardware, including motherboard, CPU, and memory. Peripherals are initialized, including printers and network interface cards (NICs). The boot device is located and the OS boot loader loaded and executed. The operating system kernel is loaded and executed.

Boot path attack surface

The conventional BIOS boot process presents an attack surface as shown in Figure 8-3. In general, threat agents focus on three general malicious behaviors:

Manipulating input. An example of input manipulation is implementation of malware to intercept passwords at login. A common threat agent is a keystroke logger implemented as a device driver. Manipulating output. Malware might act as a local man-in-the-middle element, intercepting application output and sending it to a remote server. In addition, incorrect display information might help an attacker cover an attack or collect additional information. Manipulating memory. Memory manipulation can result in OS or driver corruption and compromised direct memory access (DMA) paths. It can also enable access to information stored in RAM.

These types of attacks can destroy the integrity of one or more platforms across an organization. It is crucial that when the user login prompt appears, the system is trusted and safe for sensitive information and critical business processes. This starts by establishing a root of trust with the TPM as its support.

Figure 8- 3: Boot Path Attack Points (Du, Li, & Shen, 2011, p. 179)

The trusted memory module (TPM)

Let us begin with the short definition. A TPM is… A tamper-resistant integrated circuit built into some computer motherboards that can perform cryptographic operations (including key generation) and protect small amounts of sensitive information, such as passwords and cryptographic keys (Cooper et al, 2011, p. B-1). This is a good description for those with passing interest. However, a more detailed examination is necessary to understand the operation of the UEFI.

TPM architecture and functionality

First, the TPM is not actually a circuit, as described above. Rather, it is a specification managed by the Trusted Computing Group (TCG). Any integrated circuit or other technology that conforms to the specification is called a TPM. Figure 4 depicts the components of a specification-compliant module.

Figure 8- 4: TPM Block Diagram (Zimmer, Dasari, & Brogan, 2009) Each of these components, or component groups, plays an important UEFI support role. The RSA Engine can create one-time symmetric keys of up to 2048 bits. It is used during key wrapping operations, digital signing, and encrypting large blocks of data. The SHA-1 (or SHA-256) engine hashes large blocks of data. RNG is a module’s random number generator used to generate keys. The AIK (Attestation Identity Key) is bound to the platform on which the module resides. It is an asymmetric key pair (see Chapter 7) that attests to the validity of the platform’s identity and configuration. There are 24 Platform Configuration Registers (PCRs), many of which are used to store measures created during the UEFI boot process. PCRs are write-only and cleared only on platform reset. In addition to PCRs, module storage consists of VRAM (volatile memory) and NVRAM (non-volatile memory) (Du, Li, & Shen, 2011). NVRAM contains hardware-protected root of trust data necessary to execute and assure boot path measurements. For example, the AIK is stored there. In addition, it contains certificates necessary for attestation of signed operating system files and firmware. NVRAM cannot be easily changed. Conversely, VRAM contains command parameters and is subject to operational changes.

TPM Concepts and Components…

The following values/states are applicable to boot path measurement and are used to support UEFI attestation processes:

AIK Attestation – Only the TPM owner, or an authorized delegate, can create the AIK. The AIK credential attests to the TPM’s authenticity (TCG, 2011). AIK Credential – This is a certificate issued by a Privacy Certificate Authority (CA) containing the public portion of an AIK key pair (TCG, 2011). Attestation by the TPM – This is “An operation that provides proof of data known to the TPM. This is done by digitally signing specific internal TPM data using an AIK. The acceptance and validity of both the integrity measurements and the AIK itself are determined by the verifier. The AIK is obtained by either the Privacy CA or DAA protocol” (TCG, 2011). CRTM – Core RTM is the collection of instructions executed by a platform when performing RTM operations. (Zimmer, Dasari, & Brogan, 2009) DAA and DAA Issuer – Direct Anonymous Attestation is a protocol that establishes authenticity of an AIK. The DAA Issuer uses the DAA protocol to issue certification that the holder of the DAA credentials meets issuer-defined criteria. The platform manufacturer can be the DAA Issuer (TCG, 2011). EK – The Endorsement Key is an RSA asymmetric key pair unique to each TPM. It is used to verify the authenticity of a TPM. The private key decrypts information sent to the TPM during owner installation and other protected initialization processes (TCG, 2011). EK Credential – This certificate contains the public portion of the EK pair. It asserts that the holder of the key pair is a TCG specification compliant TPM (TCG, 2011). KEK – Key Exchange Keys can have the public keys of their key pairs stored in NVRAM. The storage location is known as the signature database, and its contents are used to attest the authenticity of various components, including the boot loader. (Edge, 2011) Platform Attestation – “An operation that provides proof of a set of the platform’s integrity measurements. This is done by digitally signing a set of PCRs using an AIK…” (TCG, 2011). This is the foundation of boot path integrity checking. RTM – The Root of Trust for Measurement is a computing engine capable of making integrity measurements. (TCG, 2011) RTR – Root of Trust for Reporting consists of the PCR values created during measurement. RTR is an important component of remote attestation. (TCG, 2011) RTS – Measurement of components in the boot path consists largely of hash (digest) creation. The RTS maintains a summary and sequence of digests (TCG, 2011) Sealing – Sealing binds protected information to a specific platform by using selected PCR values to encrypt it. If the state of the platform does not match the state at the time unsealing is requested, unsealing is blocked and the protected information remains encrypted (Parno, 2007). Shielded Location – Some TPM operations require strong protection against unauthorized viewing. Shielded memory (curtained) locations in the TPM provide required privacy (TCG, 2011). SRK – The Storage Root Key is the top key in a hierarchy of protected storage keys (TCG, 2011). SRTM – Static RTM begins with measuring and verifying the integrity of the BIOS firmware. It then measures additional firmware modules, verifies their integrity, and adds each component’s measure to an SRTM value. The final value represents the expected state of boot path loads. SRTM stores results as one or more values stored in PCR storage. (Zimmer, Dasari, & Brogan, 2009) TPM Owner – This is the vendor responsible for ensuring implicit trust for the module, applying the AIK and authorizing certain commands (Zimmer, Dasari, & Brogan, 2009). Validation Credential – This component is “a credential that states values of measurements that should be obtained when measuring a particular part of the platform when the part is functioning as expected” (TCG, 2011). Verifier – The verifier uses the DAA protocol to interact with the TPM, testing the validity of the DAA credentials. If the validity test is successful, the verifier produces an AIK credential (TCG, 2011).

It is important that you have a basic understanding of these components and properties before continuing to the following sections on the UEFI and the process of building a root of trust.

The unified extensible firmware interface (UEFI)

The UEFI is the culmination of many years of effort to “fix” the shortcomings of conventional BIOS. It began in 1998 as the Intel Boot Initiative. Later renamed EFI, Intel donated it to the UEFI Forum in 2005 (Anthony, 2011). With the support of major vendors (e.g. Microsoft, Intel, Apple, AMD, etc.), and Microsoft’s requirement for its use for Windows 8 certified platforms, the UEFI specification is finally gaining prominence.

Conventional BIOS limitations

Conventional BIOS has managed the boot process since the advent of personal computers. However, it has not kept up with hardware and cybercrime advances. Some of its limitations include:

It only operates in 16-bit mode It is limited to 1 MB addressable space It frequently causes compatibility problems between vendor add-on hardware and the underlying platform The Master Boot Record (MBR) is limited to four primary partitions per disk Bootable disks are limited to 2.2 TB It has limited support for boot path integrity checking (e.g. BIOS Boot Blocks)

Characteristics of the UEFI

The UEFI addresses all major conventional BIOS limitations. It operates in 32- or 64-bit mode, allowing significant increases in RAM addressing capability. This is necessary given UEFI’s capabilities as a low-level operating system. Further, it is architecture independent. As long as vendors write firmware compatible with the UEFI interface, hardware compatibility issues fade into the past. UEFI benefits extend beyond memory and compatibility improvements. Limitations in MBR-based boot processes are resolved with the UEFI’s use of the GUID Partition Table (GPT). The GPT uses globally unique identifiers to address partitions, allowing booting from disks as large as 9.4 ZB [9.4 x 1021 bytes] (Trivedi, 2011). Further, the UEFI allows more platform boot options, including network boot capabilities, and can act as the foundation for extended boot loaders. Storage limitations disappear, and boot processes can retrieve data and program modules from anywhere on installed storage. Finally, the UEFI is an independent operating environment that presents an API and services to BIOS firmware, third-party firmware, and the operating system. See Figure 8-5. Taking charge of the boot path, the UEFI uses the TPM to measure the integrity of each firmware instance, device driver, or operating system module before it loads. When necessary, it also allows backward compatibility with traditional BIOS operations. This establishes a strong root of trust before the user begins business processing.

Figure 8- 5: EFI Integration into Boot Process (Joshi, Munger, Shutt, Cantwell, & Sieber, 2009, p. 2)

Root of trust: The UEFI boot path

The UEFI-managed boot path has several phases with multiple “moving parts.” To help understand this often-complex environment, we will step from a general discussion to descriptions of specific operations.

Conventional BIOS v. the UEFI

As shown in Table 8-1, the UEFI boot path approaches system initialization differently. It offers flexibility, but its real value within a security context is its control of the boot loader and associated services. Table 8-1: Differences… (Skalsky, Lockett, Turner, Soderlund, & Brinkman, 2010)

Figure 8-6 is a high-level view of the UEFI boot process. UEFI operations use TPM, RTS, RTR, and RTM capabilities to measure and report initial BIOS, Option ROMs, device drivers, and OS components prior to their execution. Any component failing the measurement step is addressed according to policies set on the platform or in the verification services.

Figure 8- 6: High-Level View of the UEFI Boot Process (Zimmer, Dasari, & Brogan, 2009, p. 21)

Stepping through the UEFI boot phases

Figure 8-7 is a detailed depiction of the UEFI Platform Initialization (PI) based boot process. Compare this to the conventional BIOS boot process in Figure 2.

Figure 8-7: The UEFI PI-based Boot Process (Zimmer, Dasari, & Brogan, 2009, p. 16)

Platform initialization

The first three phases, listed below, prepare a platform for the OS boot loader. SEC Phase – In the UEFI root of trust, nothing executes unless it is integrity-checked. This includes firmware necessary to initialize the CPU, chipset, and motherboard. This is the responsibility of the SEC (security) phase.

CPU cache is flushed and the main initialization routine is executed from ROM

Cache states for certain memory ranges are set to a known state

Microcode patches are applied

A data area is established within the CPU cache, prior to RAM initialization, so that “a stack-based programming language can be used early in the initialization” (Rothman, 2009, p. 4)

At this point, all code loaded or executed was either implicitly trusted or integrity-checked. The platform is prepared for handoff to the PEI phase.

PEI Phase – Tasks in the PEI (pre-EFI) phase prepare the platform for main system initialization in the DXE phase. Steps include,

Services are transferred from ROM to data running in CPU cache.

CRTM is initiated

The PEI Dispatcher is loaded. The dispatcher loads a series of modules that might vary between platforms. These modules complete the remaining PEI tasks.

Processors are initialized

Motherboard and built-in platform interfaces are initialized

RAM is initialized

Boot is handed off to DXE phase

DXE Phase – DXE (driver execution) execution is based on resources discovered and described in the PEI phase. “This includes DXE core callable interfaces, event services, and the eventual launch of the DXE dispatcher” (Rothman, 2009, p. 6).

I/O buses are discovered

Option ROM/drivers are loaded from host-bus adapter cards

Measurement and sealing operations

Again, no code is executed until measured. To accomplish this, the CRTM is loaded during the PEI phase. Figure 8-8 shows the PCRs in which the CRTM code might store specific measures.

Figure 8-8: TPM Measurement Locations (Zimmer, Dasari, & Brogan, 2009, p. 23) Measuring is a process of extending values in each PCR. The extended value of each PCR used for measurement is compared to an expected value. For example,

All measurement PCRs are set to zero on platform reset or power up. Platform firmware is hashed with SHA-1 and stored in PCR0. For each driver in system board flash

The driver is hashed with SHA-1 The hash value is concatenated with the current PCR0 value The concatenated value is hashed and stored in PCR0. A formulaic representation is PCR0 = H(PCR0 || data), where H = Sha-1 hash operation, || = concatenate, and data = new hash value or data block less than 20 bytes. New data blocks to be concatenated do not require hashing if they are 20 bytes or less in length (Parno, 2007).

Step 3 is repeated for protocols/handlers, boot devices, and EFI runtime services. The final extended value is a measure of a specific system state.

If a PCR value is not expected, the UEFI manages the questionable component set according to platform, operating system, or user-defined UEFI policy. In many mismatch situations, value difference management is dependent upon by the platform and operating system used. Measurements and certificate-based attestation of software components occur throughout the remaining boot path phases. In addition to providing system state information, PCRs are also used for sealing operations. Sealing uses system state information to protect sensitive data. For example, the Seal(indices,data) command can instruct the TPM to encrypt a key or other sensitive data using system measurement values (Parno, 2007). The indices parameter represents a collection of values from PCRs used for system state measurement. These measures are added to the data to be protected and encrypted with the SRK. If any of the included PCR values change prior to an unseal request, the unseal operation fails.

Boot loader preparation and OS load

The PEI and DXE phases prepare the platform for operating system load, accomplished during the remaining boot path phases. To illustrate operation of the UEFI, I use Microsoft Windows 8 design elements. There are tightly linked to the UEFI process. Microsoft calls its implementation the secure boot architecture. See Figure 8-9.

Figure 8-9: Microsoft Secure Boot Architecture (Sinofsky, 2011) In the Microsoft model, firmware and the boot loader are integrity checked using signatures as well as measurements. The objective is to ensure all executables are signed and the signature public keys stored on the target platform in an “allowed database.” (Edge, 2011). Prior to boot loader execution, for example, its signature is checked, as shown in Figure 8-10. KEKs are typically unique for each component. If the signature is invalid, the executable is managed according to user-defined policy. Another feature of Windows 8 secure boot is Early Launch Anti-Malware (ELAM) operations. ELAM drivers load prior to launch of third-party components. They then control verification and initialization of additional OS components, device drivers, etc. Preventing malware load prior to OS initialization is necessary to prevent attacks against low-level hardware attack points. The extent to which these measures are implemented depends upon the platform manufacturer and the platform administrator’s decision whether or not to enable secure boot.

Figure 8-10: Security Databases for Certificates (Sinofsky, 2011) I use Windows 8 initialization to walk through the remaining boot path phases. BDS Phase – The OS boot loader is located and its signature checked. When secure boot is enabled, the UEFI will not execute unsigned boot loaders. OS Load – The OS kernel is loaded and begins to assume control of the system. The kernel loads ELAM drivers. Final drivers and third-party components are checked and executed. UEFI boot path components shut down as the platform runtime environment becomes fully operational. Remote Attestation – If configured, the platform reports its operational state to a verification server. If unknown components were loaded or if measurements are not consistent with expectations, administrators take steps to resolve trust issues. The phases represented in this chapter are based on material from various sources, and UEFI implementation differs between platform manufacturers. Further, the UEFI specification and its interpretation continue to evolve. Some time will pass before the TPM/UEFI root of trust operations are as commonly accepted as conventional BIOS is today.

The controversy

No new technology or security methodology arises without disagreement. Two significant disagreements revolve around the rise of the UEFI: runtime trust and OS signing. Some question the assertion that TPM and UEFI ensure a trusted platform. Once the operating system takes control, malware can slither into the operating system. While this is true, non-zero-day malware infections find it difficult to make it past intrusion prevention/detection systems or into patched, malware-protected platforms. The purpose of trusted boot is to effectively reduce the probability that hard (or impossible) to detect malware can take control of low-level platform processes. In my opinion, the UEFI and the TPM accomplish this. This does not relieve security managers from attention to higher-level security processes OS signing is a bigger issue. Microsoft currently requires all Windows 8 certified platform vendors to provide secure boot functionality. When enabled, only signed OS components will load. While this might work fine for Microsoft and Apple, free OS vendors are not happy. Linux implementations, for example, often do not include signing. Obtaining and managing code certificates is difficult, if not impossible, for decentralized and underfunded coding operations. While this is not typically a big problem for business desktop and mobile computing devices, it can cause problems for more technical users. Further, it can possibly affect use of Linux-based appliances. Although platform vendors can provide user selection of secure boot enforcement, the question is will they? If including secure boot shut down increases cost, maybe not. Consequently, users of free OS distributions will have to verify platform compatibility. It is too early to tell whether or not this will unreasonably constrain use of free operating systems.

Conclusion

The probability of successful low-level attacks against boot path components has been a deterrent to ensuring the initial trust of a platform on power-up. However, use of a TPM and the UEFI helps block boot path threats. Beginning with power-up, all firmware is measured or signature-checked to ensure authenticity. Collections of pre-boot loader measurements can attest to the trusted state of a platform, alert administrators to potential issues, or block platform initialization. Boot loader signing prevents malicious takeover by ensuring only authorized boot components load. Finally, ELAM drivers verify the authenticity of third-party drivers and other software loading after the kernel but before user interaction. While controversy surrounds intended implementation of the UEFI, this is a good start toward protecting the foundational components of our systems. We need to work together to evolve secure boot in a way that protects users and maintains the flexibility to use the right operating system for each business, security, or research process.    

Sources

Demystifying UEFI, the long-overdue BIOS replacement BIOS Protection Guidelines, NIST Special Publication 800-147 Ensemble of Trusted Firmware Services based on TPM. International Journal of Digital Content Technology and its Applications UEFI and “secure boot”. Deploying UEFI-Aware Operating Systems on Dell PowerEdge Servers The Trusted Platform Module (TPM) and Sealed Storage Reducing Platform Boot Times: UEFI-based Performance Optimization Protecting the pre-OS environment with UEFI Introducing UEFI-Compliant Firmware on IBM System x and BladeCenter Servers, Revision 1. Glossary Learn How UEFI Will Replace Your PC’s BIOS Trusted Platforms: UEFI, PI and TCG-based firmware