engine name: tpm2tss or libtpm2tss?

[flihp]

Some clarity on the discussion from the list would probably save folks trying to experiment with the engine: https://lists.01.org/pipermail/tpm2/2018-August/000846.html

To be as faithful to your examples I had to do this for my LSS talk:

export OPENSSL_ENGINES=/usr/local/lib/openssl/engines
export LD_LIBRARY_PATH=/usr/local/lib:/usr/local/lib/openssl/engines

echo "foo" > ${DATA_FILE}

tpm2tss-genkey -a rsa -s 2048 example.key
openssl rsa -pubout -engine tpm2tss -inform engine -outform pem -in example.key -out example.pem
openssl pkeyutl -sign -engine tpm2tss -keyform engine -inkey example.key -in msg.txt -out msg.sig
openssl pkeyutl -verify -pubin -inkey example.pem -sigfile msg.sig -in msg.txt

Adding the engine directory to LD_LIBRARY_PATH was necessary in order to use the engine name tpm2tss. Without this, the engine can be used by referring to it as libtpm2tss. On a "real" installation I have no idea whether or not the engine path is added to the search path for the dynamic linker.

[flihp]

Cc @joshuagl

[AndreasFuchsTPM]

Hmmmm... OpenSSL's own engines are prefixed with lib*. That's why I did not rename it.

I guess, I'll have to find an expert on OpenSSL to tell me, what it's supposed to be...

[JamesRHarris]

This a openssl-1.1 issue. see

https://github.com/openssl/openssl/commit/9ee0ed3de66678a15db126d10b3e4226e835b8f5

[AndreasFuchsTPM]

@JamesRHarris thanks for the hint ! So the question arises now: Which name do we choose ? Make this a configure Flag or check for the version of the installed openssl ? I'm even more confused now on what the correct name is for us...

[JamesRHarris]

@AndreasFuchsSIT I would suggest sidestepping the entire issue. My personal thought is openssl broke compatibility for no good reason. They should have supported both naming conventions for at least one major release cycle marking the old one as deprecated possibly providing run-time warnings.

One option is to punt the whole thing. Install tpm2tss.so and a symlink libtpm2tss.so. Another option is to use pkg-config to get the openssl version , aka 'pkg-config --modversion openssl' and use the correct engine name. Finally demand the end user declare what they want with a configure flag.

I would suggest going with a symlink by default so it just 'works' for most people. Then allow configure options to override the behavior and install with only one name or glean version and infer the behavior based on the reported version.

[AndreasFuchsTPM]

Could you test #7 if this works better now ?

I symlinked the other way around since libtool would not allow non-lib*-prefix libraries, but I want to keep libtool due to testing the executable without installing.

Any other ideas welcome.

[dwmw2]

You can make libtool build tpm2tss.so by adding -module to its LDFLAGS

[AndreasFuchsTPM]

So you think linking libtpm2tss.so -> tpm2tss.so is better than tpm2tss -> libtpm2tss.so ? Or was this an educational comment (which I also appreciate) ?

[dwmw2]

Nah, I think AC_SUBST(DSO_NAME...) to one or the other based on the result of $PKG_CONFIG --atleast-version=1.1 libcrypto and then a bit of s/libtss2tpm/@DSO_NAME@/ in Makefile.am...

Libtool complains that linking tpm2tss-grnkey to a module is non-portable though. Might want to either put the bit we use directly into a separate actual library and link both the engine and the tool to that. Or just use engine ctrl and do nothing directly in the tool.

[dwmw2]

https://github.com/dwmw2/tpm2-tss-engine/commit/a9106fafffc7632c08faa006719150e5d08efa0c

[dwmw2]

As I think about it, I actually come to like the idea of moving the actual TPM2 parts out into a library, which is used from both the ENGINE and tpm2tss-genkey. Because that library can exist in both tpm2-tss ibmtss forms with identical API,and we can also let GnuTLS use that.

[AndreasFuchsTPM]

As I mentioned somewhere somehow before: Have 2 frontends (GnuTLS and OpenSSL) and 2 backends (tpm2tss and ibmtss) under BSD-3clause would be my favorite...

[dwmw2]

Yep. So I did the above-referenced @DSONAME@ commit and stopped short of submitting a PR because of that warning:

*** Warning: Linking the executable tpm2tss-genkey against the loadable module
*** tpm2tss.so is not portable!

But actually, I think we can take that as a motivation to split stuff out into a library that both ENGINE and tpm2tss-genkey can use, which will shut up the warning. Then later we can look at using that same library from my GnuTLS code, and doing an implementation of it using ibmtss.

That implies that the parts of the code that we put in the library shouldn't have anything OpenSSL-specific, and the parts of the code in the ENGINE and tpm2tss-genkey shouldn't have anything TSS-specific.

I could live with ignoring the "shouldn't have anything OpenSSL-specific' requirement for now, and fixing that up in the future if we really want to make the library available outside the engine.

[AndreasFuchsTPM]

I'm doupting a little that the "non-OpenSSL" lib makes too much sense, because ESAPI is allmost at that level anyways. That was at least my impression going through the code and removing all ASN.1 and EVP_KEY containing code...

I'm starting to think that we talke tpm2tss-genkey and like the 2 necessary function statically into there to circumvent the warning ?

[dwmw2]

I'm doupting a little that the "non-OpenSSL" lib makes too much sense, because ESAPI is allmost at that level anyways. That was at least my impression going through the code and removing all ASN.1 and EVP_KEY containing code...

Hm? http://git.infradead.org/users/dwmw2/openconnect.git/blob/tpm2:/gnutls_tpm2_esys.c has no OpenSSL code...

I'm starting to think that we talke tpm2tss-genkey and like the 2 necessary function statically into there to circumvent the warning ?

That makes some sense.

[AndreasFuchsTPM]

It has Openvpn-types inside the functions. I just fear that we come up with what becomes almost a "NULL-wrapper" and "yet another API" that are not worth it... I'll have to do some more thinking about this...

[dwmw2]

Yeah, that's definitely a concern.