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

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.

quoted

This patch series is about adding a simple API which can ensure the
above properties as a layered addition to the existing TPM handling
code.  This series now includes protections for PCR extend, getting
random numbers from the TPM and data sealing and unsealing.  It
therefore eliminates all uses of TPM2_RS_PW in the kernel and adds
encryption protection to sensitive data flowing into and out of the
TPM.

In the third version I added data sealing and unsealing protection,
apart from one API based problem which means that the way trusted
keys were protected it's not currently possible to HMAC protect an
authority that comes with a policy, so the API will have to be
extended to fix that case

TPM 2.0 observations (questioning 'not possible'):

Actually, let me correct that: not possible with the way policy based
trusted keys API works because it expects you to pass in a policy
session handle.  The way to fix this is to fix the API to pass in the
actual policy sequence instead of the commands, but that's long term.

1 - Any policy that requires a password (policypassword) can
substitute
an HMAC (policyauthvalue) at the callers discretion.  They result
in the same policy digest.

Right but this requires the co-operation of the policy handle creator,
so it's an API change.

2 - Any command can be HMAC protected, even one like pcrread that
does not require authorization.  Start an HMAC session and specify
audit Of course, a shared secret has to be used, either a bind or
salted session.

Right, so if we create the session, we can then set it up to use a
salted session, but we don't create it under the current API.

3 - If the command is already using a policy session, but does not 
require a password, I believe that the same technique #2 can be
used - specify audit with that policy session.

I've tested #3 with bind but not salt.  I can test if there's
interest.

I think the API is going to have to change, so if we're looking at a
new API, we should set it up to do the right thing with policy anyway. 
It turns out to be quite easy as I found out when Huawei patched the
openssl_tpm2_engine to add policy to keys.

James

quoted

In this fourth version, I tidy up some of the code and add more
security features, the most notable is that we now calculate the
NULL seed name and compare our calculation to the value returned in
TPM2_ReadPublic, which means we now can't be spoofed.  This version
also gives a sysfs variable for the null seed which userspace can
use to run a key certification operation to prove that the TPM was
always secure when communicating with the kernel.

I've verified this using the test suite in the last patch on a VM
connected to a tpm2 emulator.  I also instrumented the emulator to
make sure the sensitive data was properly encrypted.