Bug 2176973

Summary:	evaluate CardOS support ( upstream 2591 )
Product:	Red Hat Enterprise Linux 8	Reporter:	Marc Sauton <msauton>
Component:	opensc	Assignee:	Jakub Jelen <jjelen>
Status:	CLOSED MIGRATED	QA Contact:	BaseOS QE Security Team <qe-baseos-security>
Severity:	medium	Docs Contact:	Mirek Jahoda <mjahoda>
Priority:	medium
Version:	8.7	CC:	jjelen, ldelouw, lkuprova, mjahoda, pjasbuti, ssorce
Target Milestone:	rc	Keywords:	MigratedToJIRA, Triaged
Target Release:	---	Flags:	pm-rhel: mirror+
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Known Issue
Doc Text:	.OpenSC might not detect CardOS V5.3 card objects correctly The OpenSC toolkit does not correctly read cache from different PKCS #15 file offsets used in some CardOS V5.3 cards. Consequently, OpenSC might not be able to list card objects and prevent using them from different applications. To work around the problem, turn off file caching by setting the `use_file_caching = false` option in the `/etc/opensc.conf` file.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2023-09-15 15:34:58 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Marc Sauton 2023-03-09 20:04:46 UTC

Description of problem:

evaluate RHEL-8 CardOS support for
https://github.com/OpenSC/OpenSC/issues/2591
https://github.com/OpenSC/OpenSC/issues/2591#issuecomment-1267311419
"
...snip...
The keys/certificates are instead in the path 3F 00 -> 20 00 and 20 01, which already points to DF D2 76 00 00 98 C0 00 00 and similar. In the trace, it is visible that the proprietary driver goes this path by default. I did not worked enough with the PKCS#15 cards to be able to put something working together or point you to the right direction what needs to be changed in OpenSC to make this working, but I think we will need some fallback in sc_pkcs15emu_cardos_init() when sc_pkcs15_bind_internal() fail to read the information from standard path. Probably by manually creating the DF structures to aid the standard PKCS#15 code to find the final keys/certificates. I have the annotated APDUs from the trace if you want to pursuit this challenge of getting your card working with OpenSC. I will probably not have much more time to do that now.
"
 
pkcs11-tool fails to list the card objects.

note: coolkey is reported to work on RHEL-7 for a "CardOS V5.3, 2014 from Charismathics GmbH"


Version-Release number of selected component (if applicable):
RHEL-8
opensc-0.20.0-4.el8.x86_64

opensc-tool -lan
    Detected readers (pcsc)
    Nr.  Card  Features  Name
    0    Yes             Gemalto PC Twin Reader (E86696AE) 00 00
    1    No              Cherry KC 1000 SC [KC 1000 SC] 01 00
    2    No              Alcor Micro AU9560 02 00
    Using reader with a card: Gemalto PC Twin Reader (E86696AE) 00 00
    3b:d2:18:00:81:31:fe:58:c9:03:16
    Atos CardOS


How reproducible:
N/A, no such card available at this moment

Steps to Reproduce:
1. N/A
2.
3.

Actual results:
no card objects listed by pkcs11-tool

Expected results:
yes

Additional info:

pkcs11-tool -O -l --module /usr/lib64/opensc-pkcs11.so
Using slot 0 with a present token (0x0)
Logging in to "test Card (Card PIN)".
Please enter User PIN:
Private Key Object; RSA
  label:      Digital Signature
  ID:         11
  Usage:      sign, unwrap
  Access:     none
Private Key Object; RSA
  label:      Encryption
  ID:         5d
  Usage:      decrypt, unwrap
  Access:     none
Data object 3389054704
  label:          'ProfileId'
  application:    ''
  app_id:         <empty>
  flags:          <empty>

Comment 10 Jakub Jelen 2023-09-07 11:43:16 UTC

Follow-up investigation shows in the debug log that the the issue is not a serial number, but the fact that the separate certificates are stored in single PKCS#15 object (for test card #1 in 3f0050154574) on different offsets and it looks like the file cache is not aware of the offsets so it overrides the single cache file with different content from different certificates causing invalid ASN.1 objects as a result.

Investigating the issue further, it shows that the same issue happens also with the Fedora version (opensc 0.23.0) as well as the current master version.

Simple fix for this is attached to the following upstream pr opened for comments:

https://github.com/OpenSC/OpenSC/pull/2858

I see the customer case is still alive so I can provide a test build if the customer would like to test the fix. The workaround of disabling file cache makes the accessing card significantly slower (especially because of the amount of keys/certificates VW stores on the cards) so I would encourage to fix this for good in RHEL8 (and 9) and let the customer drop the workaround.

(first run without file cache)
real	0m1.691s
(second run with file cache)
real	0m0.185s

Comment 12 Jakub Jelen 2023-09-07 12:07:08 UTC

One more thing, after installing the update, make sure to clear the cache by removing the files in the ~/.cache/opensc/ which might keep some broken cache files.

Comment 13 Phil Jasbutis 2023-09-08 10:32:57 UTC

Well done! Customer confirmed that the test build for RHEL 8 does fix the caching issue.

Follow-up question:

Since admins are typically not allowed to modify or delete files in user home directories, where cache files
are located by default, is there a way for admins to trigger a cache invalidation?


Thanks,
Phil

Comment 14 Jakub Jelen 2023-09-09 07:59:47 UTC

Thanks for checking! Looks like there is still some follow-up discussion in the upstream about the best solution as my initially proposed one has some concerns that it does not cover all the corner cases so I will likely send one more test build during next week.

If the users have the opensc.conf on production systems with file cache disabled (and never had it enabled on that system), there should not be any cache to delete. This was mostly for the testing machines where the customer would be verifying the fix.

Comment 21 RHEL Program Management 2023-09-15 15:29:54 UTC

Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

Comment 22 RHEL Program Management 2023-09-15 15:34:58 UTC

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.