On Wed, 24 Oct 2018, James Bottomley wrote:
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
I missed 6/7, sorry.
Do you have an example user space program for doing the verification
by using this file?
/Jarkko
