Re: [PATCH v4 00/13] add integrity and security to TPM2 transactions

From: Stefan Berger <stefanb@linux.ibm.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>,
	linux-integrity@vger.kernel.org
Cc: Jarkko Sakkinen <jarkko@kernel.org>,
	keyrings@vger.kernel.org, Ard Biesheuvel <ardb@kernel.org>
Subject: Re: [PATCH v4 00/13] add integrity and security to TPM2 transactions
Date: Mon, 4 Dec 2023 16:02:19 -0500	[thread overview]
Message-ID: <99abf64b-10af-4a24-ac12-117141798956@linux.ibm.com> (raw)
In-Reply-To: <a56dfd99262b31db06713f6f0b6ff2ba58c2fa4b.camel@HansenPartnership.com>

On 12/4/23 14:24, James Bottomley wrote:
> On Mon, 2023-12-04 at 13:56 -0500, Stefan Berger wrote:
>>
>>
>> On 4/3/23 17:39, James Bottomley wrote:
>>> The interest in securing the TPM against interposers, both active
>>> and
>>> passive has risen to fever pitch with the demonstration of key
>>> recovery against windows bitlocker:
>>>
>>> https://dolosgroup.io/blog/2021/7/9/from-stolen-laptop-to-inside-the-company-network
>>>
>>> And subsequently the same attack being successful against all the
>>> Linux TPM based security solutions:
>>>
>>> https://www.secura.com/blog/tpm-sniffing-attacks-against-non-bitlocker-targets
>>>
>>> The attacks fall into two categories:
>>>
>>> 1. Passive Interposers, which sit on the bus and merely observe
>>> 2. Active Interposers, which try to manipulate TPM transactions on
>>> the
>>>      bus using man in the middle and packet stealing to create TPM
>>> state the interposer owner desires.
>>
>> I think this is another capability of an interposer that should be
>> mentioned here, unless technically not possible but I would not know
>> why:
>>
>> 3. Active Interposers that send their own commands to the TPM to for
>> example cause DoS attacks.
>>
>> If we protect PCR extensions now and the interposer can send his own
>> PCR extensions and the TPM 2 accepts them (TPM doesn't have a mode to
>> reject unprotected commands in general), why protect the PCR
>> extensions from IMA then?
> 
> Well the PCRs are world writable in a standard system, so anyone with
> access, i.e. anyone in the tpm group, can arbitrarily extend them and
> destroy the replay.  So I ignored this because while an interposer can
> do this, you don't have to be an interposer to cause log replay
> disruption like this.

Presumably the folks in the tpm group are trusted while the interpose is 
not.

> 
> The actual threat to PCR extends from an interposer is silent discards
> where the attacker seeks to fake the log after the fact to match a
> quote they've discarded a suspicious event from.  Thus the HMAC check

Well, it's not that simple to fake the log unless you are root and then 
all bets are off when it comes to sending commands to the TPM.

> is actually the return one, which allows the kernel to know the write
> succeeded.
> 
> James
> 