Browse Prior Art Database

A mechanism for identifying malicious activity during an interactive Trusted Boot

IP.com Disclosure Number: IPCOM000216049D
Publication Date: 2012-Mar-21
Document File: 3 page(s) / 129K

Publishing Venue

The IP.com Prior Art Database

Abstract

This article describes a mechanism for conducting a Trusted Boot in an environment where an interactive firmware prompt is available. At such a prompt, the user may modify the contents of memory and hence undermine the Trusted Boot process. The typical solution is to provide a firmware prompt that either doesn't allow any interaction or severely limits the operations available at the prompt. This article describes a more flexible solution.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 01 of 3

A mechanism for identifying malicious activity during an interactive Trusted Boot

The behaviour described here is included in the Trusted Boot component of the IBM PowerSC offering.

Background

   Trusted Boot is a procedure for booting and establishing a chain of trust in a computing system. Using a secure device, e.g. a TPM (Trusted Platform Module) components of the boot can be cryptographically measured then stored in the TPM. The process is that each component measures and stores in the TPM the next boot component, this measurement is taken before control is transferred to the measured component. Once the system is running the chain of trust can be extracted for inspection by a remote system using a remote attestation procedure e.g. DAA (Direct Anonymous Attestation).

The Problem

   Currently, TPM implementations suffer a vulnerability whereby the code that performs the measurement can become compromised before any measurement has taken place. Several firmware implementations (including EFI and PFW) provide the ability to access a command prompt prior to OS boot. Whilst at this command prompt it is possible to examine and modify the contents of memory.

   Importantly the code that performs the trusted measurements resides in memory at this point and is therefore vulnerable to change. The following steps provide an example of how to exploit this vulnerability in order to circumvent TPM behaviour:

Consider 2 different OS kernels - Valid_Kernel and Compromised_Kernel


1. Boot the machine to the firmware prompt.


2. Modify the in-memory measurement code so that it records or reports the results of the measurements whilst booting Valid_Kernel.


3. Shutdown the machine


4. On disk, replace Valid_Kernel with Compromised_Kernel


5. Boot the machine again to the firmware prompt.


6. Modify the in-memory measurement code so that it performs no measurements but places the pre-recorded measurement values into the TPM.


7. Boot Compromised_Kernel


Thus it is possible to boot Compromised_Kernel whilst recording the values for Valid_Kernel in the TPM.

Any user with access to the firmware prompt can therefore change any of the measurements to suit their means.

Current Solutions + Limitations

The current mechanism for preventing this kind of attack is straightforward but


Page 02 of 3

very limiting. Current solutions remove or inhibit the ability to interact with the firmware in this fashion.

   This approach is inflexible and places unnecessary restrictions on the firmware. There are a number of useful features that can be provided by an interactive prompt that do not compromise the integrity of the boot process. Such options may include:


* Any operation that presents status in a read-only fashion (e.g. display of hardware device tree)


* Selecting to boot in "verbose" mode

*...