OpenSSL handshake failure when using hardware module

[erick-orozco]

Hello guys,

this most likely not an issue with OpenSC but some direction will be highly appreciated. Currently, I'm connecting to a PIVKEY hardware module, then getting pointers to the certificate and keys. Afterwards I use the openssl API to connect to a test server (pivkey.com/test/). I have two different versions of linux in which I'm running this program, to my surprise in one of them works and the other one doesn't. I double checked that both versions are using openSC 0.19.0, openSSL 1.0.2o, libp11 0.4.9. I'm missing some other module? Attached are the different logs where one of the them connects successfully and the other one doesn't.

Thanks for your help!

PD: the config files for openssl and opensc are the same too.
opensc_debug_handshake_failure.txt
opensc_debug_working.txt

[Jakuje]

Comparing the attached files, there is already difference in the response from the card on the first APDU:

Outgoing APDU (9 bytes):
00 CB 3F FF 03 5C 01 7E 08 ..?..\.~.
reader-pcsc.c:213:pcsc_internal_transmit: called
reader-pcsc.c:294:pcsc_transmit: 
Incoming APDU (2 bytes):
6D 00 m.
apdu.c:390:sc_single_transmit: returning with: 0 (Success)
apdu.c:543:sc_transmit: returning with: 0 (Success)
card.c:465:sc_unlock: called
card-piv.c:547:piv_general_io: DEE r=0 apdu.resplen=0 sw1=6d sw2=00iso7816.c:128:iso7816_check_sw: Instruction code not supported or invalid

while the "working" returns 6A 82. Anyway, the log ends unexpectedly so I would suspect something calling the OpenSC api gets some error. Did you try to get some rerbose logs from libp11?

[dengert]

00 CB 3F FF 03 5C 01 7E 08 is GET DATA to read the PIV Discovery object in an attempt to detect if the PIV applet is active. A return of 9000 with the discovery object that has the PIV AID shows the PIV is active. The 6A 82 says object not found. Meaning the active applet understood the GET DATA command but the applet does not have a Discovery object, which does not prove active applet is PIV. 6D 00 is most likely some other applet is active and does not support the GET DATA of the DER object 5C 01 7E

#1549 tries this first and if it fails try SELECT PIV AID then tries the Discovery object again. if it can not read the Discovery object with the PIV AID in it, it will set CI_DISCOVERY_USELESS. #1549 also sets some other CI_* flags if te PIVKEY card is found. One is CI_PIV_AID_LOSE_STATE which should not happen if the card correctly really supported 800-73. A lot of "PIV like" cards have this problem. if the the Discovery object can be used to test for the active applet the SELECT PIV AID can be avoided.

If you have #1549 (Which was rebased yesterday) you can run grep PIV_MATCH opensc.debug.log to see how the card type and CI_* flags are set.

[dengert]

The https://github.com/OpenSC/OpenSC/files/2641667/opensc_debug_handshake_failure.txt should be doing a C_Sign operation next. It may not have written out the buffers yet.

Try using OPENSC SPY to see PKCS#11 traffic.

Try running under a debugger like gdb or connecting gdb to the hung process to see where it is hung.

Try getting a dump of the process,

Try using a network trace like WireShark to see if the process ever connects to the server or hangs waiting for the server.

What do you mean " openssl API to connect to a test server" Maybe the problem is in how this is used.

If you suspect a missing module, use ldd to look at module library requirements.

Make sure you are using the same version of OpenSSL for all modules.

Using LD_LIBRARY_PATH= might help based on the above two tests.

[dengert]

Any other processes running that might try and access the card?

And a pcscd -d log might help if you think the problem is with OpenSC.

[frankmorgner]

Closing this issue due to inactivity. Please re-open the ticket if more input is available.