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.
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'):
1 - Any policy that requires a password (policypassword) can substitute
an HMAC (policyauthvalue) at the callers discretion. They result
in the same policy digest.
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.
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.
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.
