[PATCH v4 0/7] add integrity and security to TPM2 transactions

[Jarkko Sakkinen]

On Mon, 22 Oct 2018, James Bottomley wrote:
> On Mon, 2018-10-22 at 09:53 -0400, Ken Goldman wrote:
>> On 10/22/2018 3:33 AM, James Bottomley wrote:
>>> 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