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. 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 is actually the return one, which allows the kernel to know the write succeeded. James
