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.