On Mon, 22 Oct 2018, James Bottomley wrote:

On Mon, 2018-10-22 at 09:53 -0400, Ken Goldman wrote:

quoted

On 10/22/2018 3:33 AM, James Bottomley wrote:

quoted

By now, everybody knows we have a problem with the TPM2_RS_PW easy
button on TPM2 in that transactions on the TPM bus can be
intercepted and altered.  The way to fix this is to use real
sessions for HMAC capabilities to ensure integrity and to use
parameter and response encryption to ensure confidentiality of the
data flowing over the TPM bus.

Does this design assume that there was at time zero no monitoring?
This would permit some shared secret to be established.

Or does it assume that the interception may have been present from
the first boot?  If so, how is the first shared secret established.
Salting using the EK is the usual method, but this requires walking
the  EK certificate chain and embedding the TPM vendor CA
certificates in the  kernel.

The design establishes the shared secret at start of day using an EC
derived key from the null seed.  This can obviously be spoofed by a TPM
Genie running before the system was rebooted.  However, the computed
key name is exposed to user space and TPM2_Certify will fail when
userspace checks the null seed so you will know after the fact whether
the communication channel established on boot was secure or not.

It is possible to use either the EPS or SPS if we pass in the public
points as kernel parameters but this is getting rather complicated for
casual users.

Where was the code that exposes it to the user space?

/Jarkko