Bug 1473418 - OpenSC unable to read Alt Token Card
OpenSC unable to read Alt Token Card
Status: VERIFIED
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: opensc (Show other bugs)
7.5
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Jakub Jelen
Asha Akkiangady
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-07-20 14:41 EDT by Scott Poore
Modified: 2018-01-03 06:24 EST (History)
6 users (show)

See Also:
Fixed In Version: opensc-0.16.0-7.20170227git777e2a3.el7
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
proposed patch/hack (2.41 KB, patch)
2017-08-24 03:53 EDT, Jakub Jelen
no flags Details | Diff

  None (edit)
Description Scott Poore 2017-07-20 14:41:52 EDT
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:
Comment 2 Jakub Jelen 2017-07-21 07:13:51 EDT
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
Comment 3 Jakub Jelen 2017-07-31 11:26:27 EDT
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
Comment 4 Jakub Jelen 2017-08-24 03:53 EDT
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
Comment 7 Scott Poore 2017-11-09 15:06:01 EST
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.
Comment 9 Jakub Jelen 2017-11-29 03:20:18 EST
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
Comment 17 Jakub Jelen 2018-01-02 05:18:14 EST
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

Note You need to log in before you can comment on or make changes to this bug.