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. > > 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 > > 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. > >
