Documentation/security/tpm/tpm-security.rst

Source file repositories/reference/linux-study-clean/Documentation/security/tpm/tpm-security.rst

File Facts

System
Linux kernel
Corpus path
Documentation/security/tpm/tpm-security.rst
Extension
.rst
Size
11404 bytes
Lines
217
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

.. SPDX-License-Identifier: GPL-2.0-only

TPM Security
============

The object of this document is to describe how we make the kernel's
use of the TPM reasonably robust in the face of external snooping and
packet alteration attacks (called passive and active interposer attack
in the literature).  The current security document is for TPM 2.0.

Introduction
------------

The TPM is usually a discrete chip attached to a PC via some type of
low bandwidth bus.  There are exceptions to this such as the Intel
PTT, which is a software TPM running inside a software environment
close to the CPU, which are subject to different attacks, but right at
the moment, most hardened security environments require a discrete
hardware TPM, which is the use case discussed here.

Snooping and Alteration Attacks against the bus
-----------------------------------------------

The current state of the art for snooping the `TPM Genie`_ hardware
interposer which is a simple external device that can be installed in
a couple of seconds on any system or laptop.  Recently attacks were
successfully demonstrated against the `Windows Bitlocker TPM`_ system.
Most recently the same `attack against TPM based Linux disk
encryption`_ schemes.  The next phase of research seems to be hacking
existing devices on the bus to act as interposers, so the fact that
the attacker requires physical access for a few seconds might
evaporate.  However, the goal of this document is to protect TPM
secrets and integrity as far as we are able in this environment and to
try to insure that if we can't prevent the attack then at least we can
detect it.

Unfortunately, most of the TPM functionality, including the hardware
reset capability can be controlled by an attacker who has access to
the bus, so we'll discuss some of the disruption possibilities below.

Measurement (PCR) Integrity
---------------------------

Since the attacker can send their own commands to the TPM, they can
send arbitrary PCR extends and thus disrupt the measurement system,
which would be an annoying denial of service attack.  However, there
are two, more serious, classes of attack aimed at entities sealed to
trust measurements.

1. The attacker could intercept all PCR extends coming from the system
   and completely substitute their own values, producing a replay of
   an untampered state that would cause PCR measurements to attest to
   a trusted state and release secrets

2. At some point in time the attacker could reset the TPM, clearing
   the PCRs and then send down their own measurements which would
   effectively overwrite the boot time measurements the TPM has
   already done.

The first can be thwarted by always doing HMAC protection of the PCR
extend and read command meaning measurement values cannot be
substituted without producing a detectable HMAC failure in the
response.  However, the second can only really be detected by relying
on some sort of mechanism for protection which would change over TPM
reset.

Secrets Guarding
----------------

Certain information passing in and out of the TPM, such as key sealing

Annotation

Implementation Notes