Here is the GBD output:

segfault.txt

for what its worth, if I force opensc to use the coolkey driver, i do not get a seg fault...

Which version of SC-HSM are you using? Could you write out the APDUs (debug = 3; in opensc.conf)?

To my knowledge, i am not running SC-HSM. The card is a SafeNet SC650.

At least OpenSC is thinking you're using a SC-HSM. Please send a debug log from something like OPENSC_DEBUG=3 pkcs11-tool --test --login.

OpenSCDebug.txt

FWIW, I had to specify the module explicitly...

card-sc-hsm.c issues SELECT AID for 00 A4 04 00 0B E8 2B 06 01 04 01 81 C3 1F 02 01 Le=00 with return 9000 sc_hsm_match_card`:

 239         sc_path_set(&path, SC_PATH_TYPE_DF_NAME, sc_hsm_aid.value, sc_hsm_aid.len, 0, 0);
 240         r = sc_hsm_select_file(card, &path, NULL);

But in sc_hsm_init

1611         sc_path_set(&path, SC_PATH_TYPE_DF_NAME, sc_hsm_aid.value, sc_hsm_aid.len, 0, 0);
1612         if (sc_hsm_select_file_ex(card, &path, 0, &file) == SC_SUCCESS
1613                         && file && file->prop_attr && file->prop_attr_len >= 5) {

where it does some additional checking of the response. Even that code is questionable.

The card may assume this was a valid select file, as there is no requirement to support AID and it did not ask for any response data.

I think the sc_match_card should request a response and check it closely to make sure this is a
SmartCard-HSM card.

More issues with the SELECT AID vs SELECT FILE to make sure we really have the correct card.

Forcing coolkey allows me to use pkcs11_inspect and see the cn and pwent data.

But, if I do pkcs11 --test --login, I get a pkcs11 function error: C_SignFinal failed: rv = CKR_ARGUMENTS_BAD(0x7).

I read on another forum that someone was getting the same error in 0.16 using slackware and they fixed it by increasing the max send and receive size to 511 and 512, respectively. I tried that and got the same error, I even tried increasing it to max size.

I am guess this is because OpenSC doesn't fully support the SafeNet SC650 card, even using coolkey libraries.

I fixed the segmentation fault in the pull request.

From the product sheet it looks like your token is a java card that can load other applets, in particular it is possible that it contains the SC-HSM applet. If that should not be the case, then you should report to SafeNet that your card erroneously reports the existence of the SC-HSM applet. You should ask what kind of PKI applet exists on your card so that forcing an internal card driver allows you using the token.

@thukk could you check if your issue is fixed with #1252?

I don't quite understand why the other card issues a SW1/SW2=9000 in response to a SELECT with unknown FID or AID. This is severe bug in the other card implementation.

However what puzzles me, is that the driver tries to select the sc-hsm applet even though the ATR does not match the ATR whitelist.

I have a feeling that the issue is caused by 3e7f7e6.

@CardContact the whitelist is a shortcut to avoid the selection (to be faster). If it doesn't match then sc_hsm_match_card still issues the SELECT.

With a card not in the match list, such as Yubikey the atr are matched twice.
../../../src/src/libopensc/card.c:234:sc_connect_card: trying driver 'sc-hsm'

../../../src/src/libopensc/card.c:273:sc_connect_card: trying driver 'sc-hsm'
On this one, the SELECT AID is done:
00 A4 04 00 0B E8 2B 06 01 04 01 81 C3 1F 02 01 00
Luckily the Yubico returns 6A 82

This is an example of another driver using the SELECT AID causing interference because the older Yubikey loses the login state.

So the bug looks like it is the user's card should not have returned 9000.