Description of problem: When working with 2048b keys on the card, we need to send large APDU of more than 256B when attempting to decrypt/sign some data. This is problem with this reader, which does not support long APDU (according to pcsc-lite-ccid?). Version-Release number of selected component (if applicable): pcsc-lite-ccid-1.4.26-1.fc26.x86_64 pcsc-lite-1.8.20-1.fc25.x86_64 How reproducible: always Steps to Reproduce: 1. Try to decrypt some data with 2048b key in the OMNIKEY CARDMAN 3121 reader in OpenSC Actual results: OpenSC detects the maximal supported length of driver as 255 (or so), which does not fit. OpenSC is trying to split the APDU into chained, which is not supported either and it fails. Expected results: The reader has non-standard support for long APDU and it works fine in RHEL (RHEL bug #1071399 -- private). See attached patch from CentOS, which should resolve this problem [1]. Excuse possible inaccuracies. I will attach related logs if needed. It is also possible that the detection is wrong on OpenSC side which detects it, but some change in pcscs-lite-ccid is most probably needed too. Additional info: [1] https://git.centos.org/blob/rpms!pcsc-lite-ccid/4615a1a283618f5357901347aae48c6724572959/SOURCES!ccid-1.4.10-omnikey-3121.patch
Debug logs from pcscd from the affected reader: 00000005 winscard_svc.c:672:ContextThread() TRANSMIT rv=0x0 for client 21 00000043 winscard_svc.c:359:ContextThread() Received command: TRANSMIT from client 21 00000017 readerfactory.c:852:RFReaderInfoById() RefReader() count was: 1 00000011 winscard.c:1605:SCardTransmit() Send Protocol: T=0 00000025 APDU: 00 A4 04 00 00 01 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000006 ifdhandler.c:1303:IFDHTransmitToICC() usb:076b/3021:libudev:0:/dev/bus/usb/002/111 (lun: 0) 00000004 commands.c:1802:CmdXfrBlockTPDU_T0() T=0: 266 bytes 00000003 commands.c:1818:CmdXfrBlockTPDU_T0() Command too long (266 bytes) for max: 261 bytes 00000003 SW: 00000003 ifdwrapper.c:548:IFDTransmit() Card not transacted: 612 00000003 winscard.c:1630:SCardTransmit() Card not transacted: 0x80100016 00000003 winscard.c:1650:SCardTransmit() UnrefReader() count was: 2 We can see only few lines from ccid (command.c), which happens just before going into the CCID_Transmit() doing this workaround. We see also the wrong maximum length of APDU. Out of the curiosity I just tried to build pcsc-lite-ccid package from RHEL7 sources but I am getting the same failures, so most probably this will depend on some change in other package. Any more ideas what I can try? Bob, can you share your pcscd debug log from RHEL machine using the long APDU? sudo LIBCCID_ifdLogLevel=0x000F /usr/sbin/pcscd -adf --color
So for some reason there, the protocol is using T=0 instead of T=1. With the patch, the Omnikey should be able to support T=1. I'm pretty sure that patch is in RHEL-7. bob
Created attachment 1257196 [details] proposed patch resolving the issue That would make sense. In T0 we are limited to ~260B of data. Now as I am looking into the patch I was working with, I noticed I missed some of the chunks that did not apply properly. Also I was using a PIV Test card (Gemalto) without support of T1 (which we discussed earlier, but I forgot). Non-gemalto cards should work this way (for future reference). Also withdrawing the statement from the previous comment. The package in RHEL7 works seamlessly. Looking into the code further, I noticed missing chunk removed in 2014: https://anonscm.debian.org/cgit/pcsclite/CCID.git/commit/?id=a9d926a6b2c2edfc160e7fe5d908e7e3e6f60969 Adding these two options back for CARDMAN3121 makes it working again for me. Ludovic, would it make sense to resolve this in upstream somehow similar way? Is there something more I should test?
I am not sure to understand: You wrote: "The package in RHEL7 works seamlessly." and "Adding these two options back for CARDMAN3121 makes it working again for me." So the problem is fixed with the patch provided in RHEL7. Exact? What are the "two options" you are referring to?
Sorry for confusion. I meant the linked patch + basically reverting the commit linked from the comment #3 resolves this problem in Fedora. In RHEL7 there is older version of ccid and therefore only the patch (linked from the comment #0) resolves the problem (already applied in RHEL package). By the "options" I meant "dwFeatures" modification in the referenced upstream commit. But as Bob mentioned before, the patch is more like hack to non-standard behavior so I will understand if it will not be suitable upstream. But it should work in Fedora, since we probably want to support that.
Well, even through the reader is old, not CCID compliant and needs hacks to work with long APDUs, it is still very popular (we are having around there several of these). I built the packages for Fedora 26 and Rawhide.