On Mon, 2018-11-19 at 20:05 -0700, Jason Gunthorpe wrote: > On Mon, Nov 19, 2018 at 04:54:32PM -0800, James Bottomley wrote: > > On Mon, 2018-11-19 at 16:08 -0700, Jason Gunthorpe wrote: > > > On Mon, Nov 19, 2018 at 02:36:28PM -0800, James Bottomley wrote: > > > > On Mon, 2018-11-19 at 14:44 -0700, Jason Gunthorpe wrote: > > > > > On Mon, Nov 19, 2018 at 01:34:41PM -0800, James Bottomley > > > > > wrote: > > > > > > On Mon, 2018-11-19 at 14:19 -0700, Jason Gunthorpe wrote: > > > > > > [...] > > > > > > > Sure, for stuff working with shared secrets, etc, this > > > > > > > make sense. But PCR extends are not secret, so there is > > > > > > > no reason to encrypt them on the bus. > > > > > > > > > > > > OK, there's a miscommunication here. I believe the current > > > > > > document states twice that there's no encryption for PCR > > > > > > operations. We merely use a salted HMAC session to ensure > > > > > > that they're reliably received by the TPM and not altered > > > > > > in-flight. > > > > > > > > > > Sure, but again, what is this preventing? > > > > > > > > It prevents the interposer having free reign to set the PCR > > > > values by substituting every measurement you send to the TPM. > > > > > > But the threat model for PCR excludes the possibility of an > > > interposer. If you have an interposer the PCB is broken and all > > > PCR security is already lost. > > > > 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. You seem to be saying it's not viable to expect the TPM to function in the above environment and I'm saying I think it is but we may have to adjust our definition of "function". This is the situation where I want to get confirmation that PCR measurements went to the TPM and detach it if they don't. request/response encryption is probably most useful in the case of self owned devices that may have suffered third party interference with a view to stealing secrets (think foreign government finds your powered off laptop in your hotel room), the so called "evil maid" attack. Personally, since I own my own laptop, I care about the latter, but I think, since we have infrastructures relying on it that we, as responsible kernel developers, have to care about the former as well. > 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. The point about interposers is that they address the technology gap. Sure it was possible to use a Focussed Ion Beam to extract secrets from a decapped TPM like the black hat guys did but that's just impractical for the average user as is the JTAG technology that would allow you to interface with the main CPU bus. An interposer is a very practical and easy to install device. James > This would let an attack unseal, say, a disk encryption secret while > running a hostile version of Linux. A big failure of the fundamental > PCR guarentee. > > So any point along the PCR trust chain that does not do secure PCR > updates is a failure point. Since the BIOS doesn't do it, one would > probably start by replacing the bootloader and kernel in conjunction > with the interposer? > > The incremental gain from having the kernel do this seems negligible > to me. > > I think to properly address this threat work needs to be done in the > TPM spec to establish a secure TPM communication channel at power > on.. > > > > > some scope for detecting the presence of an interposer if it > > > > does > > > > try to tamper with your measurements. > > > > > > But I can still tamper with them.. I can have the interposer > > > delete/fail the kernel PCR commands and issue un-hashed ones. > > > > You can't because you don't have the HMAC key to fake the response, > > so > > as long as I check the HMAC return I know you've tampered. > > .. and you stop using the TPM after this. Otherwise the interposer > can > fail the command, issue an extend with the right data, and cause the > PCRs to match trusted data while running actually untrusted code. > > > > The kernel would have to do something extreme like fault the TPM > > > and > > > totally disable the linux device if any PCR extend fails. That > > > should > > > probably be included in the plan? > > > > If we detect an interposer (if one of the HMACs or encrypt/decrypt > > fails) it depends on policy what you do. We certainly log a > > message > > saying TPM integrity is compromised. I think we should also > > disable > > the TPM, but I haven't done that yet because I thought it would > > bear > > more discussion. > > Logging doesn't seem useful - if a HW interposer is present then > someone is already in control of the HW and will happily ignore > warnings ... > > Jason >
