opensc 0.21.0 break my openvpn config using a Aladdin Knowledge Systems Token JC PKI

[EricV]

As soon as I install opensc 0.21.0, the detection of this PKI token by openvp is broken.

Bus 005 Device 003: ID 0529:0620 Aladdin Knowledge Systems Token JC

Steps to reproduce

It seems the PKI key is no more detected and the code keeps asking for inserting the token and the window to enter Pin code never displayed. Downgrading to opensc 0.20.0, the problem vanishes.

Note that for this PKI, there is a specific library to use libeToken.so but pkcs11-tool works when instructed to use this module.

It is probably a bad interaction via libpkcs11-helper but I have no clue yet.

Could you provide some direction to help debugging the problem.

[dengert]

Start with Debug log and SPY trace. See: Using-OpenSC

[frankmorgner]

Please create a debug log of your problem as described in the comments of our issue template. You may also want to look at the hints on how to write a good bug report.

[EricV]

Thanks for the people who responded. I probably need to give you some more context to see why the general way of debugging is hard to use (at least I think so) in my case.

First the openvpn process is started by systemd and is used as a slave process that receives its command via a communication socket (See /usr/share/doc/openvpn/management-notes.txt.gz for command
output format and real-time message format). Then a graphical front end, display the progress and ask for PKI PIN code or barks if it does not detect the key, probably from real notification send by openvpn process through the socket channel.

So the command line option, opensc log and even the spy library trick is hardly relevant because at first, I do not call or use opensc directly, then although I know what pkcs11 library should be used to access my dongle, is never explicitly set it and I do not even know where the path for the library is given to openvpn.

First do you have a clue on were the interaction between openvpn and opensc-pkcs-11 could take place. Only installing opensc-pkcs-11 is sufficient to break my openvpn setup.

dpkg -L opensc-pkcs11
/.
/usr
/usr/lib
/usr/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu/libopensc.so.6.0.0
/usr/lib/x86_64-linux-gnu/libsmm-local.so.6.0.0
/usr/lib/x86_64-linux-gnu/onepin-opensc-pkcs11.so
/usr/lib/x86_64-linux-gnu/opensc-pkcs11.so
/usr/lib/x86_64-linux-gnu/pkcs11
/usr/lib/x86_64-linux-gnu/pkcs11-spy.so
/usr/share
/usr/share/doc
/usr/share/doc/opensc-pkcs11
/usr/share/doc/opensc-pkcs11/NEWS.gz
/usr/share/doc/opensc-pkcs11/README.md
/usr/share/doc/opensc-pkcs11/changelog.Debian.gz
/usr/share/doc/opensc-pkcs11/copyright
/usr/share/p11-kit
/usr/share/p11-kit/modules
/usr/share/p11-kit/modules/opensc-pkcs11.module
/usr/lib/x86_64-linux-gnu/libopensc.so.6
/usr/lib/x86_64-linux-gnu/libsmm-local.so.6
/usr/lib/x86_64-linux-gnu/pkcs11/onepin-opensc-pkcs11.so
/usr/lib/x86_64-linux-gnu/pkcs11/opensc-pkcs11.so
/usr/lib/x86_64-linux-gnu/pkcs11/pkcs11-spy.so
/usr/share/doc/opensc-pkcs11/README

I assume that is this via libpkcs11-helper that will look at /usr/share/p11-kit/modules directory. Could you confirm?

Then do you have a suggestion to use openvpn to access and read the PKI credential from command line to simplify the problem reproduction and use the debug method you suggested.

Thanks for your support.

[EricV]

So I progressed. I looked at the pcks11 options used to start openvpn in the systemd service file

If I use opensc 0.21.0, the PKI led blinks and is accessed but no pkcs11-id are displayed :

openvpn --pkcs11-providers p11-kit-proxy.so --show-pkcs11-ids

The following objects are available for use.
Each object shown below may be used as parameter to
--pkcs11-id option please remember to use single quote mark.

Downgrading to opensc 0.20.0 I get (stuff removed for confidentiality reasons)

openvpn --pkcs11-providers p11-kit-proxy.so --show-pkcs11-ids

The following objects are available for use.
Each object shown below may be used as parameter to
--pkcs11-id option please remember to use single quote mark.

Certificate
DN: xxxxxxxxxxxxxxxxxxx
Serial: xxxxxxxxxxxxxxxxxxx
Serialized id: xxxxxxxxxxxxxxxxxxx

Certificate
DN: xxxxxxxxxxxxxxxxxxx
Serial: xxxxxxxxxxxxxxxxxxx
Serialized id: xxxxxxxxxxxxxxxxxxx

Certificate
DN: xxxxxxxxxxxxxxxxxxx
Serial: xxxxxxxxxxxxxxxxxxx
Serialized id: xxxxxxxxxxxxxxxxxxx

Certificate
DN: xxxxxxxxxxxxxxxxxxx
Serial: xxxxxxxxxxxxxxxxxxx
Serialized id: xxxxxxxxxxxxxxxxxxx

p11-kit list-modules
p11-kit-trust: p11-kit-trust.so
library-description: PKCS#11 Kit Trust Module
library-manufacturer: PKCS#11 Kit
library-version: 0.23
token: System Trust
manufacturer: PKCS#11 Kit
model: p11-kit-trust
serial-number: 1
hardware-version: 0.23
flags:
write-protected
token-initialized
opensc-pkcs11: opensc-pkcs11.so
library-description: OpenSC smartcard framework
library-manufacturer: OpenSC Project
library-version: 0.21
orange-dongle-aladdin: /usr/lib/libeToken.so
library-description: SafeNet eToken PKCS#11
library-manufacturer: SafeNet, Inc.
library-version: 10.7

How to debug further from there?

[dengert]

Check that there are not two modules files in /usr/share/p11-kit/modules trying to load the opensc-pkcs11.so.

While trying to test OpenSC-0.21.0 built from git tag 0.21.0 on Ubuntu-0.20.0
gdb --args ./pkcs11-tool --module p11-kit-proxy.so -O
I was getting strange messages about a breakpoint being set 2 times.
and the command would get a segfault.

/usr/share/p11-kit/modules had 4 files:

root@XUbuntu-20:/usr/share/p11-kit/modules# ls -l
total 20
-rw-r--r-- 1 root root 560 Mar 11  2020 gnome-keyring.module
-rw-r--r-- 1 root root 183 Jun 29  2018 opensc.module
-rw-r--r-- 1 root root 183 Jan 10 07:52 opensc-pkcs11.module
-rw-r--r-- 1 root root 902 Feb  8  2020 p11-kit-trust.module
-rw-r--r-- 1 root root 171 Mar 22  2020 softhsm2.module

I had modified opensc-pkcs11.module to use an absolute path to the test version.
But when I commented out the entries in opensc.module from 2018, (which it looks like I had added :/)
the command now works. I don't normally use p11-kit.

It the above is not your problem...

Modify the opensc.conf file to turn on debugging.
Most likely it is /etc/opensc/opensc.conf modify these two lines:

	# debug = 3;
	# debug_file = opensc-debug.txt;

to

	debug = 3;
	debug_file = /tmp/opensc-debug.txt;

Any process that uses OpenSC will append to this file, so only run the test that fails. You may need to touch /tmp/opensc-debug.txt and chmod 777 incase openvpn is running as root as part of its processing.

We are looking to see if opensc is actually run, and was it trying what was it doing if it crashes. It might be trying to test your token to see if opensc supports it or not. In that case look a line containing `sc_connect_card: matched:'

If you get a core file, try using gdb command-name core and do a where command.

[EricV]

oot@tri-yann4:/usr/share/p11-kit/modules# grep opensc-pkcs11.so *
opensc-pkcs11.module:module: opensc-pkcs11.so
root@tri-yann4:/usr/share/p11-kit/modules# ls -l
total 16
-rw-r--r-- 1 root root 560 Mar 11 2020 gnome-keyring.module
-rw-r--r-- 1 root root 140 Aug 30 09:10 opensc-pkcs11.module
-rw-r--r-- 1 root root 154 Oct 22 14:19 orange-dongle-aladdin.module
-rw-r--r-- 1 root root 902 Dec 12 13:40 p11-kit-trust.module

With the 0.20.0 modules

pkcs11-tool --module p11-kit-proxy.so -O
Using slot 1 with a present token (0x12)

With 0.21.0 modules

pkcs11-tool --module p11-kit-proxy.so -O
error: PKCS11 function C_GetSlotInfo failed: rv = CKR_FUNCTION_NOT_SUPPORTED (0x54)

Aborting.

And apparently the file is loaded only once:

/usr/share/p11-kit/modules# strace pkcs11-tool --module p11-kit-proxy.so -O 2>&1 | grep open | grep opensc-pkcs11.so
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/pkcs11/opensc-pkcs11.so", O_RDONLY|O_CLOEXEC) = 3
root@tri-yann4:/usr/share/p11-kit/modules#

Thanks for your help. Telle me if you need any more info.

[dengert]

Yes, I need more where is the opensc-debug.log

[EricV]

File is too large it refuse to atache it. Any email to send it directly?

[EricV]

Log File Stored at :
http:https://pastebin.fr/80241

[dengert]

OpenSC does not support you token. but your other vendor module does. What may have happened:

• The order of the modules loaded by p11-kit may have changed.
• OpenSC changed the return code, and p11-kit does not know it should go on to the next module that may support the token.
• OpenSC handling of slots has changed, and this may complicate the situation of seeing a token that opensc can not support.
• p11-kit has changed.

@EricV see man man pkcs11.conf there are a number of options you could use to change the order of the modules: priority, enable-in, enable-out and disable-in.

Where did you get the the 0.21.0 build? the line numbers don't match up. and I don't see how CKR_FUNCTION_NOT_SUPPORTED is returned. It should be CKR_TOKEN_NOT_RECOGNIZED

@frankmorgner, @Jakuje did we every have a way to handle running under p11-kit, and returning some different CKR_ so p11-kit could handle this?

Do we need a way to remember a slot with a token we can not handle differently from a token we can handle but has real problems? (It looks like we go through the whole process of trying to find a driver for it with every C_GetSlotInfo I see a delay of 1 second, but when it can multiple seconds to query a card, that is not long enough.

Did we make any changes in 0.21.0 to cause the failure, or cause p11-kit to change the order of the modules.

I note that the lines and return codes in the debug log do not match what is in master or tag-0.21.0.
Although bb2547abca12f3ce22d48c3c171ea5e44ab4c4a Jun 2, 2020 could have changed something

Lines 16166:

P: 8266; T: 0x140384749496384 19: 53: 23.340 [opensc-pkcs11] card.c: 371: sc_connect_card: unable to find driver for inserted card
P: 8266; T: 0x140384749496384 19: 53: 23.432 [opensc-pkcs11] reader-pcsc.c: 669: pcsc_disconnect: SafeNet eToken 5100 [Main Interface] 01 00: SCardDisconnect returned: 0x00000000
P: 8266; T: 0x140384749496384 19: 53: 23.432 [opensc-pkcs11] card.c: 403: sc_connect_card: returning with: -1210 (Card is invalid or cannot be handled)
P: 8266; T: 0x140384749496384 19: 53: 23.432 [opensc-pkcs11] slot.c: 259: card_detect: SafeNet eToken 5100 [Main Interface] 01 00: SC connect card error -1210
P: 8266; T: 0x140384749496384 19: 53: 23.432 [opensc-pkcs11] misc.c: 86: sc_to_cryptoki_error_common: libopensc return value: -1210 (Card is invalid or cannot be handled)
P: 8266; T: 0x140384749496384 19: 53: 23.432 [opensc-pkcs11] pkcs11-global.c: 582: C_GetSlotInfo: C_GetSlotInfo () card detect rv 0x54
P: 8266; T: 0x140384749496384 19: 53: 23.432 [opensc-pkcs11] pkcs11-global.c: 599: C_GetSlotInfo: C_GetSlotInfo () flags 0x6
P: 8266; T: 0x140384749496384 19: 53: 23.432 [opensc-pkcs11] pkcs11-global.c: 600: C_GetSlotInfo: C_GetSlotInfo (0x4) = CKR_FUNCTION_NOT_SUPPORTED

[EricV]

On 11/01/2021 03:00, Doug Engert wrote: OpenSC does not support you token. but your other vendor module does. What may have happened: * The order of the modules loaded by p11-kit may have changed.

I doubt the module order changed. And using the same order with the old version does work. Pk11-kit command list the module order and it does not change between 0.20.0 and 0.21.0. But indeed libEtoken is after the opensc one p11-kit list-modules p11-kit-trust: p11-kit-trust.so library-description: PKCS#11 Kit Trust Module library-manufacturer: PKCS#11 Kit library-version: 0.23 token: System Trust manufacturer: PKCS#11 Kit model: p11-kit-trust serial-number: 1 hardware-version: 0.23 flags: write-protected token-initialized opensc-pkcs11: opensc-pkcs11.so library-description: OpenSC smartcard framework library-manufacturer: OpenSC Project library-version: 0.20 orange-dongle-aladdin: /usr/lib/libeToken.so library-description: SafeNet eToken PKCS#11 library-manufacturer: SafeNet, Inc. library-version: 10.7

* OpenSC changed the return code, and p11-kit does not know it should go on to the next module that may support the token.

That's it and for me this is a package interface breakage. And it is a bug until other package that interact with opensc are also fixed.

* OpenSC handling of slots has changed, and this may complicate the situation of seeing a token that opensc can not support. * p11-kit has changed.

p11-kit does not change between the working 0.20.0 and non working 0.21.0. The only packages that changes between the working situation and the non working one are opensc and opensc-pkcs11

@EricV <https://github.com/EricV> see |man man pkcs11.conf| there are a number of options you could use to change the order of the modules: priority, enable-in, enable-out and disable-in.

This is not a practical solution, it should be done on several hundred of PCs, with different Linux flavor, versions, and PKIs ... pk11-kit is THE way to support several different token and libraries transparently. Again, we have several version of PKI token using several libs and using p11-kit-proxy.so is the recommended way to use openvpn because of that.

Where did you get the the 0.21.0 build? the line numbers don't match up. and I don't see how CKR_FUNCTION_NOT_SUPPORTED is returned. It should be CKR_TOKEN_NOT_RECOGNIZED

It is the official debian sid repository version. https://packages.debian.org/sid/opensc On the right hand side there are two tar, one http:https://deb.debian.org/debian/pool/main/o/opensc/opensc_0.21.0.orig.tar.gz is the official 0.21.0 tar gz and the other http:https://deb.debian.org/debian/pool/main/o/opensc/opensc_0.21.0-1.debian.tar.xz is the debian build specifics. You have to de-tar it at the root of untrared official package, It creates a debian directory with all is needed to rebuild the package the debian/ubuntu way. At root of the 0.21.0 package you only need to do: fakeroot make -f debian/rules binary to recreate the .deb It contains a patch series directory but the only patch there is a config option for the build.

@frankmorgner <https://github.com/frankmorgner>, @Jakuje <https://github.com/Jakuje> did we every have a way to handle running under p11-kit, and returning some different CKR_ so p11-kit could handle this?

Yes this is the way to go, you should fix your API breakage.

…

-- eric

[EricV]

And just for the record I need opensc for the pkcs11-tool utility that is used for getting keys for ciphering filesystems (LUKS, crypsetup) and that work when specifying the correct library (but is expected to use the same p11kit trick to support multiple PKI models).

[dengert]

@frankmorgner your commit 1bb2547 2020-06-02 has:

@ -87,7 +102,8 @@ static CK_RV sc_to_cryptoki_error_common(int rc)
	case SC_ERROR_INVALID_CARD:
 	case SC_ERROR_WRONG_CARD:
 	case SC_ERROR_NO_CARD_SUPPORT:
-		return CKR_TOKEN_NOT_RECOGNIZED;
+		/* CKR_TOKEN_NOT_RECOGNIZED is handled in sc_to_cryptoki_error() */
+		return CKR_FUNCTION_NOT_SUPPORTED;

Many routines were changed but not C_GetSlotInfo, so sc_to_cryptoki_error() is not called and the above line which used to work now returns CKR_FUNCTION_NOT_SUPPORTED, which causes p11-kit to treat this as a hard error.
What other routines could also have this problem?

[frankmorgner]

I've checked PKCS#11 2,3 and it looks like I've simply missed C_GetSlotInfo. I've created #2200 with a fix.

Historically, there have been many functions returning CKR_TOKEN_NOT_RECOGNIZED, which should not have returned it. Do you have a better suggestion than returning CKR_FUNCTION_NOT_SUPPORTED in that case?

[mouse07410]

Why not just return CKR_TOKEN_NOT_RECOGNIZED here?

That would be my first preference.

[dengert]

in addition to : frankmorgner@d4e177f#commitcomment-45844694

No, because p11-kit would not be expecting CKR_FUNCTION_NOT_SUPPORTED for functions that are required to work such as C_GetSlotInfo. But it apparently goes on to try other modules if CKR_TOKEN_NOT_RECOGNIZED.

We should also look at OpenSC keeping track of these tokens that have failed once, so we do not caused all the overhead of card matching again and again in same PKCS11 "session" from C_Initialize to C_Finalize.

[dengert]

@mouse07410 I agree. The "no" was to Frank's question.

[frankmorgner]

PKCS#11 has a whitelist of return values and usually CKR_TOKEN_NOT_RECOGNIZED is not among them. #2200 correctly completes this list, bit with @dengert 's review I realized that the problem is dug in deeper:

1. OpenSC/src/pkcs11/pkcs11-global.c

   Line 596 in 219c6cc

   rv = card_detect(slot->reader);

2. OpenSC/src/pkcs11/slot.c

   Line 260 in 219c6cc

   rv = sc_to_cryptoki_error(rc, NULL);

3. In card_detect there are multiple other functions called, which all don't respect the conversion (i.e. framework's bind/create_token)

[mouse07410]

I hear you.

But since our purpose is making the tokens work first, and strictly complying with the standard second to that - I still suggest we revert to returning CKR_TOKEN_NOT_RECOGNIZED at least until we figure a truly foolproof solution.

[dengert]

I agree. I would also suggest that we create a 0.21.1 release for this because:

• this fixes a regression
• p11-kit is now the standard way to use PKCS11.
• The bug only effects users who have tokens not supported by OpenSC.
• These are the same users that are using p11-kit
• Without this fix, their recourse is to remove OpenSC
• Our reputation.

[EricV]

I just recompiled with the suggested revert and indeed I can now connect to VPN. Then you decide what is the appropriate short term and long term solution but at least there is a one liner fix.

[dengert]

Ways to test:

• @EricV - Thanks for testing.
• Take a token that is supported by OpenSC, and a vendor pkcs11 module.
• setup to use p11-kit
• modify opensc.conf to not use the OpenSC driver for the token.
• Test without the patch - should fail
• Test with the patch should work

A possible token to use is a Yubkey with PIV applet, and the Yubico PIV pkcs11 module.

@mouse07410 I believe you could easily do this test, but may also have to comment out the openpgp driver in opensc.conf, so OpenSC does not start using PGP applet.

[frankmorgner]

I've adapted #2200 accordingly and I think it should work, but I'm not happy with it either. It still looks hacky.

The problem with short term solution is that they last very long. Once we revert the commit, everyone will forget about it. The correct solution would be to use sc_to_cryptoki_error() everywhere where we need to translate a return value. That, however, would be a big change with the potential to break everything. Again, we see that OpenSC has a lot of good pieces, but many quick solutions make it look like a patchwork quilt.

[dengert]

Somehow the pkcs11-global.c mod does not look right. It is going to endup returning rv = CKR_OK

The previous code may have a a different bug here, in that SC_ERROR_INVALID_CARD was retuned that was then converted to CKR_TOKEN_NOT_RECOGNIZED.

[mouse07410]

The problem with short term solutions is that they last very long

Until there is a better solution - fine with me. May they last as long as they need to.

Once we revert the commit, everyone will forget about it.

I'm already reverting I've already reverted it in my fork. And if everybody forgets about it - then that's how much value this improvement has for everybody.

The correct solution would be to use sc_to_cryptoki_error() everywhere where we need to translate a return value. That, however, would be a big change with the potential to break everything

Maybe. But until there is a fully debugged change that is shown to break nothing - I personally don't care for "correct in theory" solutions, which break functionality in practice.

We don't need to be sticklers for standards at the cost of breaking working tokens and applications.

I say again - let's revert it. And reconsider when there's enough desire to do so, and a fix that's correct and complete enough.

[Jakuje]

Hi. Sorry I am late for party.

The PKCS#11 standard is here to follow. If we could return any value we want, we would not need it and we could just use libopensc instead of opensc-pkcs11 (and teaching everyone else to use it in their applications).

Returning CKR_FUNCTION_NOT_SUPPORTED from C_GetSlotInfo is bad as it signalizes there is something really wrong with the library and now it demonstrated as an interoperability issue. Returning CKR_TOKEN_NOT_RECOGNIZED is also bad, but was probably not caught by p11-kit, because it does not even expect this function could return it.

I read through the comments, but I am not sure how exactly the issue is pinpointed (aside of the source commit), but I would be interested in the log with P11_KIT_DEBUG envoronment variable to see where this is handled inside of p11-kit if it says something about this issue.

[mouse07410]

The PKCS#11 standard is here to follow. If we could return any value we want, we would not need it and we could just use libopensc instead of opensc-pkcs11 (and teaching everyone else to use it in their applications).

Fine. Everybody would welcome your PKCS#11-compliant fix to this problem (that also doesn't break anything else).

In the meanwhile, let's unbreak OpenSC.

[dengert]

@Jakuje you have a point. The C_GetSlotInfo returns info about the slot, and if a token is in the slot. The slot is the reader. C_GetTokenInfo is where CKR_TOKEN_NOT_RECOGNIZED is listed as a valid return value.

So C_GetSlotInfo CKR_OK is valid when OpenSC can not handle the token, as @frankmorgner mod was doing.

So with the above view, p11-kit does not care if more then one module could return that it can support a card, or not support a card via C_GetTokenInfo and the card would then show up in slots from each. I had been thinking about it differently.

In either case C_GetSlotInfo should not return CKR_FUNCTION_NOT_SUPPORTED, and any caller has been dealing with the CKR_TOKEN_NOT_RECOGNIZED from either C_GetSlotInfo or C_GetTokenInfo.
(P11-kit may have been doing something with it, but not what I was thinking it had to do.)

Apparently applications like VPN can handle CKR_TOKEN_NOT_RECOGNIZED from C_GetSlotInfo, and maybe from C_GetTokenInfo, but we never got that far to see if OpenSC does that.

But as @mouse07410 and I point out, we have a regression on our hands, and need to get a fix out to distros before they put this into production releases.

[frankmorgner]

p11-kit does not filter for CKR_FUNCTION_NOT_SUPPORTED and neither does openvpn. I think, OpenVPN uses pkcs11-helper, which checks this return code (search in pkcs11h-certificate.c, for example).

[dengert]

They do a lot of if (rv != CKR_OK) or if (rv == CKR_OK)
https://github.com/p11-glue/p11-kit/blob/master/p11-kit/proxy.c#L519

That is as far as I went.

[frankmorgner]

They do a lot of if (rv != CKR_OK) or if (rv == CKR_OK)
https://github.com/p11-glue/p11-kit/blob/master/p11-kit/proxy.c#L519

That is as far as I went.

Maybe I should have been more verbose in my comment. Checking for (NOT) CKR_OK is not affected when changing CKR_TOKEN_NOT_RECOGNIZED to CKR_FUNCTION_NOT_SUPPORTED. Hence, the problem must be in some layer above/below p11-glue. As said above, I'm suspecting pkcs11-helper. Maybe @alonbl has some idea...

[alonbl]

Hi, As far as I know, CKR_FUNCTION_NOT_SUPPORTED may be returned for optional functions such as sign recover or decrypt, while for mandatory functions such as slot list or info it is unexpected as a core logic may not avoid calling these. Regards, Alon

…

On Wed, 13 Jan 2021 at 13:53 Frank Morgner ***@***.***> wrote: They do a lot of if (rv != CKR_OK) or if (rv == CKR_OK) https://github.com/p11-glue/p11-kit/blob/master/p11-kit/proxy.c#L519 That is as far as I went. Maybe I should have been more verbose in my comment <#2199 (comment)>. Checking for (NOT) CKR_OK is not affected when changing CKR_TOKEN_NOT_RECOGNIZED to CKR_FUNCTION_NOT_SUPPORTED. Hence, the problem must be in some layer above/below p11-glue. As said above, I'm suspecting pkcs11-helper. Maybe @alonbl <https://github.com/alonbl> has some idea... — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2199 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJURLIMSXMWMSIINLB3ZHTSZWCT3ANCNFSM4V2HCZJA> .

[dengert]

Attached are spy and debug logs for testing this issue. OpenSC 0.20.0 was built from git tag 0.20.0 and OpenSC 0.21.0 was built from git tag 0.21.0. p11-kit was setup to load opensc-pkcs11.so and ypkcs11.so modules as well as a softhsm module. (Both opensc-pkcs11 and ypkcs11 will show they can handle the token.)

Too simulate this issue, OPENSC_DRIVER=myeid was set so neither the PIV or OpenPGP drivers would be tried. But the ypkcs11 can handle the token.

opensc-debug.0.20.0.log
spy.0.20.0.txt
opensc-debug-0.21.0.log
spy.0.21.0.txt

The main difference in the spy logs starting on line 34 "4: C_GetSlotInfo" is:

• 0.20.0 C_GetSlotInfo returns CK_OK, and sets CKF_TOKEN_PRESENT. Then C_GetTokenInfo returns CKR_TOKEN_NOT_PRESENT.
• 0.21.0 C_GetSlotInfo returns CKR_FUNCTION_NOT_SUPPORTED and C_GetTokenInfo is never called.

C_GetSlotInfo should set the CKF_TOKEN_PRESENT or not, and can return only:
"CKR_ARGUMENTS_BAD, CKR_CRYPTOKI_NOT_INITIALIZED,
CKR_DEVICE_ERROR, CKR_FUNCTION_FAILED, CKR_GENERAL_ERROR, CKR_HOST_MEMORY,
CKR_OK, CKR_SLOT_ID_INVALID".

C_GetTokenInfo can only return:
"CKR_CRYPTOKI_NOT_INITIALIZED, CKR_DEVICE_ERROR, CKR_DEVICE_MEMORY,
CKR_DEVICE_REMOVED, CKR_FUNCTION_FAILED, CKR_GENERAL_ERROR,
CKR_HOST_MEMORY, CKR_OK, CKR_SLOT_ID_INVALID, CKR_TOKEN_NOT_PRESENT,
CKR_TOKEN_NOT_RECOGNIZED, CKR_ARGUMENTS_BAD."

0.20.0 follows the above pkcs11 standard. 0.21.0 does not.

So we should look at why 0.21.0 C_GetSlotInfo did not return CKR_OK with CKF_TOKEN_PRESENT.

[dengert]

Based on the above test case, Here is a simple fix to master
c-GetSlotInfo-diff.txt
It is not complete. There are 7 other places where return sc_to_cryptoki_error(rc, NULL); is called. Any one of these could have a similar problem. Use this patch as a starting point.

I really don't see the point in calling sc_to_cryptoki_error to do a conversion based on passing a string. It is another layer of complexity which caused the regression.

[frankmorgner]

I've rewritten #2200 to respect the caller's context for error code conversion. the default value for unknown conversions is CKR_GENERAL_ERROR as used elsewhere. Note that this will also return CKR_GENERAL_ERROR when calling C_GetSlotInfo with an unknown token, hence it will fix this issue.

Yes, there may be other (better) mechanisms to respect PKCS#11's whitelist of return values, but the context string is what has been been there for ages. Until there's something better available, we stick to that.

[EricV]

When you reach an agreement (hope soon), tell me what to test. In the mean time, it may break other people PKI (vpn, or else) setup.

[EricV]

As said in the above pull request itself, this also works for me. Thanks for working on it.