Replace TPM support with alternative library

[ethindp]

Currently, TPM support requires the Trousers library, which to my knowledge hasn't been maintained for quite a while and isn't even available in the distributions that I've tried (arch, Ubuntu, Fedora, CentOS). According to it's SourceForge website, the last news publication was all the way back in 2008. I believe that it might be a good idea to replace this with something more modern that's available. According to my research, the TPM 2.0 TSS might theoretically be a good alternative. If we want to go for cross-platform usage (i.e. on Windows/MacOS) too though we may wish to just use the platform-provided interfaces. I sadly don't know how to do that on MacOS, but on Windows I think we can do this through the TPM base services API. I can't say for certain though as I've never directly interacted with TPMs before like this.

[reneme]

Currently Botan supports TPM 1.2 only, and that support is deprecated. TPM 2.0 is a completely new specification that offers much more flexibility and functionality than what we currently have a wrapper for.

That said, there's an ongoing effort to add basic TPM 2.0 support using the tpm2-tss you mentioned. See: #3877

Do you have a concrete use case for TPM 2.0 that you could share details about?

[randombit]

TPM Base Services API is IIUC just a multiplexer that allows several clients to access the hardware without conflicts. Similar to /dev/tpm on Linux. I think regardless of platform, we should program to the TPM2 interface spec, which MS seems to implement in this set of libraries

[ethindp]

@randombit Nothing off the top of my head (other than doing interesting things like storing SSH keys), although I could see it being useful as an RNG source or a full-on alternative cryptographic back-end that could be used for the cipher interface (for both long-term and ephemeral keys maybe?). The only significant downside to tpm2-tss is getting it to work on Windows. I just mentioned it since I know that Botan supports it but I could never get it to work since the library needed is pretty much unavailable without manual compilation. I was also going to suggest a possible upgrade to the latest PKCS11 standard but in that area I don't know what the most widely-used version is. In theory we could support all three versions (2.40, 3.0 and 3.1), given that (supposedly) they're all backwards-compatible with one another, but Idk how much of an implement overhead that would be. (As an aside, for the PKCS11 headers, you may wish to check out https://github.com/latchset/pkcs11-headers -- it has public domain versions of the headers you could include in Botan to make it even more self-contained.)