Conversation

@jarkko good timing indeed, a colleague at work was just trying out TPM bus sniffing against Windows and Linux targets. Didn't read the full patch set, does this prevent passive sniffing on existing systems that just use tpm2_nvread without any sessions or are user space changes necessary as well?

1
0
1
@lindi2 Cool to hear! And please contact me if you find something. I'd expect at least some issue, if not security, then stability but that is obviously to case for any code that has not yet been in the warzone, right? :-)

So, yeah it *should*. It uses null seed for TPM key generation which is shuffled per power on and creates HMAC pipe to the TPM which is unconditonally applied to the user space devices. also it denies comms if the null seed is resetted.

Also the stuff @pid_eins and systemd folks have been working is expected to not be "warzone ready" ;-) some social of the media feedback on that has been somewhat uneducated (not referring to demo videos, it is helpful the demonstrate the issues and open source by definition should be brutally honest and transparent).
1
0
0

Jarkko Sakkinen

Edited 6 months ago
@lindi2 @pid_eins I'll do my PR probably on Monday so you can expect the feature in rc1 if Linus agrees on it.

For earlier testing, use linux-next tree. For any findings please do not send just "hush mail" to me but instead use linux-integrity@vger.kernel.org mailing list :-) We have full release cycle for v6.10 to fixup things. Also any suggestions how to counter-measure e.g. any security findings are obviously appreciated!

If those suggestions lead to bug fix, you can either bake up possible patch yourself or we fix it up then obviously the reported-by (for the report itself) and suggested-by (for the solution) are applied to the commits.
1
0
0

@lindi2 @pid_eins good news, Linus pulled my PR’s in queue:https://social.kernel.org/notice/AhrCE3Z7RqcBa1p1Hc. So the changes are now in the mainline.

For security research: HMAC pipe is for the kernel clients we do not want to layer /dev/tpm0. It can be done just as well in the user space (and should be when required).

I.e. right now for trusted keys, and soon’ish for asymmetric keys (feature requried for x.509 certificates [1]). You can also grep the call sites by:

$ git grep "tpm2_start_auth_session(.*);"
drivers/char/tpm/tpm2-cmd.c:	rc = tpm2_start_auth_session(chip);
drivers/char/tpm/tpm2-cmd.c:	err = tpm2_start_auth_session(chip);
include/linux/tpm.h:int tpm2_start_auth_session(struct tpm_chip *chip);
security/keys/trusted-keys/trusted_tpm2.c:	rc = tpm2_start_auth_session(chip);
security/keys/trusted-keys/trusted_tpm2.c:	rc = tpm2_start_auth_session(chip);
security/keys/trusted-keys/trusted_tpm2.c:	rc = tpm2_start_auth_session(chip);

x.509 part will be 6.11 feature.

[1] https://datatracker.ietf.org/doc/draft-woodhouse-cert-best-practice/ NOTE: a bit out of date, I chatted quickly with David and he is planning to remove TPM 1.2 and DSA keys from the draft.

1
0
0

Jarkko Sakkinen

Edited 6 months ago
@lindi2 @pid_eins After TPM2 asymmetric keys has landed we could conclude that the kernel side is in some sense "feature complete" as far as TPM2 is concerned.

There might be some additional stuff in EFI upcoming *possibly*. I'm thinking UKI here but since I'm not that familiar with it, I don't have exact picture what it might possibly require from kernel. But at least as far as runtime features are concerned, looking solid.
0
0
0