Hide Forgot
Description of problem: I am unable to see data on an Alt Token card using opensc. [root@vm1 ~]# p11tool --provider /usr/lib64/opensc-pkcs11.so --list-all-certs No matching objects found Version-Release number of selected component (if applicable): opensc-0.16.0-5.20170227git777e2a3.el7.x86_64 How reproducible: consistently reproducible with my card. Steps to Reproduce: 1. yum -y install opensc gnutls-utils pcsc-lite 2. systemctl start pcscd.service pcscd.socket 3. connect reader and insert Alt-Token card 4. p11tool --provider /usr/lib64/opensc-pkcs11.so --list-all-certs Actual results: [root@vm1 ~]# p11tool --provider /usr/lib64/opensc-pkcs11.so --list-all-certs No matching objects found Expected results: I expected to see the listing of certs on the card. Additional info: It should be noted that I'm seeing similar results with coolkey so I'm not sure of the actual source of the problem. [root@vm1 ~]# p11tool --provider /usr/lib64/libcoolkeypk11.so --list-all-certs warning: no token URL was provided for this operation; the available tokens are:
This card behaves somehow weirdly and does not response to the instructions to retrieve CCC nor from VM nor from filesystem (according to the section 6.2.1 from CAC specification [1]). I would appreciate some more information about the card from the vendor. The changes so far for this and the bug #1301817 are available in my branch on github [2]. [1] http://www.cardwerk.com/smartcards/smartcard_standard_ISO7816-4_5_basic_organizations.aspx [2] https://github.com/Jakuje/OpenSC/commits/cac-improvements
AFAIK, the updated document that is related to this issue is the [1] (10 years old ... sigh ...). It has a different flow chart and counts also with the CACv2 cards without CCC. If I will get access to the card from Scott, I will have a look into that. So far I put together an idea how it can look like [2]. But clearly I will need to test it, because the chart is very vague. [1] http://www.cac.mil/Portals/53/Documents/ref1.c.i-CAC_End-Point_Implementation_Guide_v1-22.pdf [2] https://github.com/Jakuje/OpenSC/commit/3e7794b
Created attachment 1317476 [details] proposed patch/hack I put together a patch that allows me to pass testsuite with OpenSC (for both standard CAC cards and this ALT token). But this solution has several assumptions and one rough edge that I would like to avoid/resolve before submitting the change upstream and shipping it in RHEL: * The AID of ACA object is hard-coded to a value different than in the implementation guide [1] * The list of PKI objects is hardcoded (from CAC1), even though it could be picked from the ACA in ideal case (this would involve a lot of new code and parsing of ACRs). * The ACA applet needs to be selected before calling VERIFY APDU (I didn't see this requirement anywhere in the specifications) I am still waiting if I will get some update from DoD about this. [1] http://www.cac.mil/Portals/53/Documents/ref1.c.i-CAC_End-Point_Implementation_Guide_v1-22.pdf
Verified. Version :: opensc-0.16.0-6.20170227git777e2a3.el7.x86_64 Results :: [root@rhel7-1 ~]# p11tool --provider /usr/lib64/opensc-pkcs11.so --list-all-certs Object 0: URL: pkcs11:model=PKCS%2315%20emulated;manufacturer=Common%20Access%20Card;serial=00000000;token=<string removed>;id=%00%02;object=CAC%20Email%20Signature%20Certificate;type=cert Type: X.509 Certificate Label: CAC Email Signature Certificate ID: 00:02 I was unable to see anything before this patched version so this looks fixed to me.
It looks like the pam_pkcs11 is still using the coolkey. Can you try to remove the coolkey from the nss db, check that the opensc is correctly selected in pam_pkcs11.conf and also the DB is added to the opensc section as described in the following article: https://access.redhat.com/articles/3034441
Hemant, thank you for the debug logs. The working card is connected through the PIV interface so the comparison is not very useful. But it looks there is a problem with parsing the certificate data from that card. I have got that data from the debug log, so I investigate what went wrong. There is a bug in parsing multi-byte length tags in SimpleTLV function. After fixing that, I am able to correctly parse your data. I will build you a test package and I hope we will be able to fix it also in the next update. The upstream PR: https://github.com/OpenSC/OpenSC/pull/1231 Can you verify your card is read correctly with the following scratch build? https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=14854543
The OpenSC is not installed in the system where the above steps were ran! That is good start when you want to test OpenSC. Please, tell the customer how to configure the pam_pkcs11 to use OpenSC: * Install OpenSC and verify it is the version I referred in the previous comment * Edit pam_pkcs11.conf: * set use_pkcs11_module = opensc * add the following option to the opensc block nss_dir = /etc/pki/nssdb; * Add OpenSC to NSS DB: pkcs11switch opensc * Try again ... If it will not work, try to modify the opensc.conf with card_drivers = cac, internal;
The p11tool is in gnutls-utils package. But it is not needed to make it working. > When inserting the HID Alt token from within the GUI (after logging on with > username/password), the Smart Card Manager launches automatically. It indicates > that the smart card is not formatted (see attached screen shots). This is not > the case, however. We can use the same card on Windows without issue. The ESC (Smart Card Manager) is still using Coolkey, so it will not work there either. Yes, this is the same identification as the card we were testing with.
Please, make sure the OpenSC version installed is the same as the "Fixed in" in this bug. Then, provide a debug log as I requested from others in comment #13: rpm -q opensc OPENSC_DEBUG=9 pkcs11-tool -O --module /usr/lib64/pkcs11/opensc-pkcs11.so
Thank you for providing more information. It sounds like a problem with the DELL keboard/reader as described in the bug #1547117 The debug log, I requested will be generated only if you pass the environment variable on the same line as the command: $ OPENSC_DEBUG=9 pkcs11-tool -O --login &> pkcs11-tool-O--login.log Can you attach this log as an attachment? I was not able to get this log from the other reporter so I hope I will be more successful here.
Can you give it a try with different card reader than the Dell keyboard? This really looks like related to the reader, not to the card itself Anyway, the important part of the log is here: sec.c:159:sc_pin_cmd: called reader-pcsc.c:1862:pcsc_pin_cmd: called reader-pcsc.c:199:pcsc_internal_transmit: called reader-pcsc.c:1905:pcsc_pin_cmd: PC/SC v2 pinpad block (32 bytes): 1E 1E 02 08 00 08 04 02 00 00 00 00 00 00 00 0D ................ 00 00 00 00 20 00 00 08 FF FF FF FF FF FF FF FF .... ........... reader-pcsc.c:199:pcsc_internal_transmit: called reader-pcsc.c:1951:pcsc_pin_cmd: PIN command failed: -1109 (Input operation cancelled by user) iso7816.c:1130:iso7816_pin_cmd: APDU transmit failed: -1109 (Input operation cancelled by user) sec.c:206:sc_pin_cmd: returning with: -1109 (Input operation cancelled by user) pkcs15-pin.c:394:_sc_pkcs15_verify_pin: PIN cmd result -1109 card.c:445:sc_unlock: called reader-pcsc.c:627:pcsc_unlock: called pkcs15-pin.c:397:_sc_pkcs15_verify_pin: returning with: -1109 (Input operation cancelled by user) pkcs15-pin.c:306:sc_pkcs15_verify_pin: returning with: -1109 (Input operation cancelled by user) framework-pkcs15.c:1551:pkcs15_login: PKCS15 verify PIN returned -1109 misc.c:61:sc_to_cryptoki_error_common: libopensc return value: -1109 (Input operation cancelled by user) pkcs11-session.c:300:C_Login: fLogin() rv 80 The OpenSC sends a request for a pin to the keyboard, but it answers it was canceled by the user. Did you provide the PIN on pin pad? Unfortunately, we do not see PC/SC answer here. Can you provide the debug log from pcscd with the instructions from [1]: systemctl stop pcscd; sudo LIBCCID_ifdLogLevel=0x000F pcscd --foreground --debug --apdu --color | tee log.txt [1] https://access.redhat.com/articles/3034441
Well ... this command will work with pinpad readers (dell keyboard). If the other reader will be without pinpad, the pin will be asked on command-line. In that case, use only the stderr redirection 2> to collect the debug logs, otherwise OpenSC will fail to display the prompt. From the log, the OpenSC asked the reader to login to the card (on pinpad) and ~25 seconds later failed as "canceled by user" (the log with timestamps): 0x7fb9f4a45740 15:09:26.422 [opensc-pkcs11] reader-pcsc.c:199:pcsc_internal_transmit: called 0x7fb9f4a45740 15:09:53.773 [opensc-pkcs11] reader-pcsc.c:1951:pcsc_pin_cmd: PIN command failed: -1109 (Input operation cancelled by user) I am not sure how the keyboard signalizes the PIN prompt, but if you did not write a pin, this might be the issue.
*** Bug 1546938 has been marked as a duplicate of this bug. ***
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:0987
Mirek, this does not seem to be included in release notes. Is there something we can do to update the release notes about OpenSC changes? This one is pretty important so it would be great if we could announce it.