"Failed to get session"

[grawity]

Now that my distro has upgraded to OpenSSL 3.0 and ripped out all engine support, I'm trying to figure out how to use pkcs11-provider with a hardware eToken – at first via CLI, later hopefully via ruby-openssl – but so far I'm only getting:

$ openssl pkey -pubin -provider pkcs11 -in "pkcs11:token=etoken_ember;id=%3D%D8%99%E2%17%1C%B6%D1"
Could not read key of Public Key from pkcs11:token=etoken_ember;id=%3D%D8%99%E2%17%1C%B6%D1
40679D80097F0000:error:40000001:pkcs11:store_fetch:reason(1):store.c:355:Failed to get session to load keys

Via strace I see it loading p11-kit and libeToken.so and talking to pcscd.

Is this because I haven't provided a PIN? (I tried adding pin-value= but that didn't improve things.)

I'd like to avoid OPENSSL_CONF, both because the specific p11-kit setup I'm using involves remoting via SSH, which loads openssl recursively (so using OPENSSL_CONF results in a forkbomb), and because it seems clumsy (previously my scripts could just call OpenSSL::Engine.by_id("pkcs11")...)

[simo5]

Providers require some configuration, but now we have a "default" driver that can be used if you specify the provider name in the command line or in properties within the application.

I do not understand the OPENSSL_CONF comment, on a working system you should modify /etc/ssl/openssl.cnf to add the provider you want to use there. It will not be used by default unless you specify a pkcs11 uri, so it is safe to have a default configuration in the system for all applications to use.

The specific error you are getting is odd, I would recommend trying first by directly loading the pkcs11 driver you want to use so we can see if that is working on its own.

I assume you want to use /usr/lib64/opensc-pkcs11.so, you can also specify this via the PKCS11_PROVIDER_MODULE w/o having to modify openssl.cnf yet

[grawity]

I do not understand the OPENSSL_CONF comment, on a working system you should modify /etc/ssl/openssl.cnf to add the provider you want to use there. It will not be used by default unless you specify a pkcs11 uri, so it is safe to have a default configuration in the system for all applications to use.

Hmm, I wished it could be entirely drop-in, i.e. I install the pkcs11-provider package and it's ready to use. (I assume there's no openssl.cnf.d/ that packages could add partial configs to...) Though more importantly, how would it handle two tools that need to access different PKCS#11 modules, or different PINs, if they both share the same openssl.cnf with the same "pkcs11-module-token-pin" in it?

However, I get the same error after adding pkcs11 to /etc/ssl/openssl.cnf, and it still has the same problem with infinite recursion in my case (I've explained it below).

I assume you want to use /usr/lib64/opensc-pkcs11.so, you can also specify this via the PKCS11_PROVIDER_MODULE w/o having to modify openssl.cnf yet

Thanks, PKCS11_PROVIDER_MODULE will be useful, but in this case I really want p11-kit-proxy specifically.

The reason is that I've configured p11-kit via ~/.config/pkcs11/modules/ to load a remote module through its remoting support – specifically it does remote: |ssh otherhost p11-kit remote /usr/lib/libeToken.so to access a token connected to another machine. So I can tell the script to use p11-kit-proxy.so as the PKCS#11 module (which is even the default in libp11's pkcs11-engine) and it automagically talks to the remote token.

But if I enable the pkcs11 provider system-wide via openssl.cnf, this happens:

1. whenever ssh is invoked it loads libcrypto;
2. libcrypto loads the providers (including the configured pkcs11);
3. pkcs11-provider immediately loads p11-kit-proxy and enumerates all tokens;
4. p11-kit-proxy reads remote: |ssh ember p11-kit remote... from config and invokes ssh in order to allow pkcs11-provider to talk to the module;
5. the new ssh instance loads libcrypto again... repeat infinitely.

If the process manually loads a provider (e.g. openssl -provider pkcs11) this of course doesn't happen.

---

But I did test directly on the server machine, without any of this p11-kit remoting being involved (i.e. just directly loading libeToken.so), and I get the same error:

ember$ PKCS11_PROVIDER_MODULE=/usr/lib/libeToken.so openssl pkey -pubin -provider pkcs11 -in "pkcs11:token=etoken_ember;id=%3D%D8%99%E2%17%1C%B6%D1"
Could not read key of Public Key from pkcs11:token=etoken_ember;id=%3D%D8%99%E2%17%1C%B6%D1
40A72CA76B7F0000:error:40800001:pkcs11:store_fetch:reason(1):store.c:355:Failed to get session to load keys

The module is from SafeNet Authentication Client 10, for an "Thales/Gemalto/Alladin" eToken 5110. I think the pkcs11: URL is correct because p11tool from GnuTLS accepts it.

[simo5]

Can you check if the SafeNet module links to openssl by chance?
The recursion in OpenSSH is unfortunate, it is something we'll have to deal with, but you can wrok around it by setting PKCS11_PROVIDER_MODULE, maybe we'll grow an option to set an environment variable after initialization that will autodisable the pkcs11 provider if the called module somehow recurse into it, but this would work only for in process libraries, for proxying like actions you will need to find a way to disable the provider in the server, maybe starting it with PKCS11_PROVIDER_MODULE=/dev/null ? (it will cause a failure to load the module but shouldn't break anything else, the provider will simply go "offline" and not be available in that process.

[grawity]

Can you check if the SafeNet module links to openssl by chance?

Not directly, but looks like it does dynamically load libcrypto.so.1.0.2 or libcrypto.so.1.0.0 (the system has the latter installed).

(Yes, it's a somewhat old version of SAC.)

The recursion in OpenSSH is unfortunate, it is something we'll have to deal with, but you can wrok around it by setting PKCS11_PROVIDER_MODULE,

But that means I won't be able to use pkcs11-provider in the original project either (the CA script that needs to load p11-kit-proxy and access the remote token)? So I really wish on-demand loading worked (whatever the Ruby equivalent of OSSL_PROVIDER_load() is going to be).

(The provider is already disabled on the SSH server side, the recursion happens entirely on the client side.)

[simo5]

You can definitely use https://www.openssl.org/docs/manmaster/man3/OSSL_PROVIDER_load.html and custom load a provider in your application.
But this is an openssl level "issue", nothing I can do in the provider itself.

[simo5]

Though more importantly, how would it handle two tools that need to access different PKCS#11 modules, or different PINs, if they both share the same openssl.cnf with the same "pkcs11-module-token-pin" in it?

the pin does not have to be specified in config, it can always be specified in the uri if needed.

[grawity]

You can definitely use https://www.openssl.org/docs/manmaster/man3/OSSL_PROVIDER_load.html and custom load a provider in your application. But this is an openssl level "issue", nothing I can do in the provider itself.

Alright, so that sounds like openssl -provider should also work and I'm doing something wrong with it. I'll try with something like softhsm or a yubikey then, without any remoting, and see if I can get it working.

[beldmit]

I have a feature request for OSSL_PROVIDER_load_ex function that will accept the initialization parameters but I have no resources to work on it. It would be useful for PKCS#11 provider

[simo5]

@beldmit IIRC the p11-kit module does not need initialization parameters

[grawity]

So apparently the problem was simply the PKCS#11 URI not matching anything, which was fixed by commit cd52fd4 – at least directly on the server (no fancy remoting or anything) it seems to work with the -provider option now:

$ pacman -Q pkcs11-provider
pkcs11-provider r202.g339e146-1

$ openssl pkey -provider pkcs11 -in "pkcs11:token=etoken_ember;id=%3D%D8%99%E2%17%1C%B6%D1;type=private" -pubout
Enter pass phrase for PKCS#11 Token:
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7V1+5sZfsOEcvOaWpYp7