On Wed, 2018-10-24 at 03:13 +0300, Jarkko Sakkinen wrote: > 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? It's patch 6/7. It exposes the null ec primary name in sysfs: jejb@jarvis~> cat /sys/class/tpm0/tpm/null_name 000ba4fa35ecfbf7c85e5407d07edc27f6a522c8b1a011bcb68c60b27baf21f9d9ec The key certification gives you back a signed copy of the name which you can verify against this. James
