On Tue, Nov 20, 2018 at 09:17:59AM -0800, James Bottomley wrote: > > > Yours might, mine doesn't and I think I can mitigate the we can > > > give you approved PCRs attack ... I can't prevent the we muck with > > > your PCRs attack. > > > > It is not 'mine' or 'your' threat model. These trade offs are baked > > into the TPM protocol design itself. > > > > I guess I haven't really heard you explain what your threat model > > is. > > OK, the TPM is supposed to provide attestation of the correct > environment on a device under someone else's control (the classic > example is laptop provided by a company to an employee). The device is > under the physical control of the entity you don't entirely trust so > the TPM is supposed to attest that they're running an approved OS ... > we have whole TCG specs for that situation. Well.. Attestation started out as a way to prove things about hardware you physically control - ie data center servers. That they haven't been manipulated. I'm not surprised people want to use this on the client, but in this case you really have to trust the employee to not disassemble the laptop... The idea that it could extend to HW you don't control is, frankly, a bit of wishful thinking. The system is strong enough to defend against casual abuse, but a determined and funded adversary has, many, many, options to create a situation where the TPM attests the system is running software that it actually isn't. The scary thing about the interposer is how inexpensive and simple it is, many other attacks require considerable determination and funding. > > I would think if an interposer can muck with the PCRs then the main > > attack would be to cause the CPU to run code that does not match the > > PCRs while tricking the TPM into thinking the PCR matches. > > The interposer sits on the serial bus ... it has no contact with the > CPU. That's the point about it, it's a simple to attach easy to > construct device because the TPM bus (LPC, i2c, spi etc) is easy to > interface to. getting a device which can man in the middle the main > CPU address bus, say, is at least an order of magnitude more difficult. It doesn't need contact with the CPU. The basic flow would be to use the interposer on SPI or LPC to block the Nth PCR update, having determined that Nth comes from the BIOS and covers the bootloader.. The BIOS ignores the error, or can't tell the PCR update was corrupted. From there it is easy to see how to get into a hostile kernel and extend the PCRs to match a trusted kernel. But even this convoluted attack is kind of silly. If I can touch the TPM physically then just boot into my hostile kernel and *trigger TPM reset*. Then I can simply issue reset and then extends from the hostile kernel to mimic a trusted system. Easy! One wire and a microscope will do the job! So it really is essential that all steps, including the BIOS use secure PCR updates, or you may as well not bother in Linux, at least for security reasons. And I think you were on the right track, the TPM should have a per-boot authorization that flows through all layers of the TPM stack and guarantees the TPM hasn't been rebooted and with crypto prevents lost PCR updates. But that does require standardization, as we do need the BIOS to participate. Though keep in mind, tt doesn't prevent physical access from manipulating the PCRs, it just makes it more expensive than one wire and a microscope. Maybe it now involves de-soldering, etc. Jason
