While other instantiations are possible, the following techniques are described in terms of features of trusted platform modules, or tpMs, and recent CpUs from aMd and Intel:

Measurement. When tpM-equipped platforms first boot, platform hardware takes a measurement (sha- 1 hash) of the BIos, recording it in one of the tpM’s platform Configuration registers (pCrs). 25, 28 the BIos is then responsible for measuring the next software component (such as the bootloader) and associated data files. the BIos records the measurement in a pCr before executing the software. If each subsequent software component performs these steps—measure, record, execute—the tpM holds a set of measurements of all code executed on the platform. 25

Attestation. to securely convey measurements to an external verifier, the tpM creates attestations; with a verifier-supplied nonce, the tpM uses a private key never accessible outside the tpM to generate a tpM quote, or a digital signature over the nonce and the content of the pCrs. the nonce assures the verifier that the attestation is fresh and not copied from a previous boot cycle.

to ensure the attestation comes from a real hardware tpM, not a software emulation, the tpM includes an endorsement keypair and endorsement certificate for the public key from the platform’s manufacturer declaring it belongs to a real tpM. to preserve user privacy, the tpM uses attestation-identity keys (bound anonymously to the endorsement key) to sign attestations.

Secure storage. the tpM also includes a limited amount of nonvolatile raM (nvraM). reading and writing to nvraM can be restricted based on pCr content, so an nvraM location can be made accessible only to a particular set of software. that software can use the protected nvraM to store a symmetric key that can then be used to encrypt and integrity-protect bulk data.

Dynamic root of trust for measurement. to protect the launch of a virtual machine monitor (vMM), recent commodity CpUs from aMd and Intel extend the x86 instruction set to support a dynamic root of trust for measurement (drtM) operation. 1, 10 drtM provides many of the security benefits of rebooting the computer (such as starting from a clean slate) while bypassing the overhead of a full reboot; that is, devices remain enabled, the BIos and bootloader are not invoked, and memory contents remain intact. drtM is implemented through a new sKInIt instruction on aMd CpUs or GetseC[senter] on Intel CpUs, which can launch a vMM at an arbitrary time (hence the colloquialism late launch) with built-in protection against software-based attacks. When a drtM is invoked, the CpU’s state is reset, and direct memory access (dMa) protections for a region of memory are enabled. the CpU hashes the content (such as data and executable code) of the memory region, extends the measurement into the tpM’s pCr 17 (and 18 on Intel), and begins executing the code.

Trust assumptions. relying on a tpM’s guarantees involves trusting the tpM manufacturer, the platform vendor, and the pKI linking them to the tpM’s keys. the CpU, raM, and chipset must also be trusted. the tpM is designed to withstand software-based attacks and limited hardware attacks (such as rebooting the machine) but is not expected to resist sophisticated physical attacks.

Security Features in
Commodity Computers

report the software state of the plat-
form. Given the software state, users
(or their agents) can decide whether
the platform should be trusted. While a
full-blown secure coprocessor (such as
the IBM 4758) 27 might appeal, cost lim-
its deployment. However, as of 2010,
more than 350 million30 commodity
computers had been sold worldwide
with a special-purpose security chip
called the TPM, as described in the
sidebar. 28 With appropriate software
support, it can be used to report on the
software executing on the computer.
The resulting attestation can be veri-
fied by a user’s trusted device (such as
a cellphone or special-purpose USB
fob). 29 Thus, the user’s trust in the de-
vice can be extended, via the TPM, to
establish trust in the software on the
machine. For example, Garriss et al.
used a cellphone to verify a virtual ma-
chine monitor on a kiosk computer, 5
though a kiosk might not satisfy the
hardware security assumptions dis-
cussed earlier.