Derive dwMaxAPDUDataSize from dwMaxCCIDMessageLength

[frankmorgner]

Currently, the value of MaxAPDUDataSize (PCSCv2_PART10_PROPERTY_dwMaxAPDUDataSize) is either 0 (only short APDUs) or 0x10000 (ccid_descriptor -> dwFeatures & CCID_CLASS_EXTENDED_APDU). However, the actual value is present in the USB descriptor as dwMaxCCIDMessageLength:

Please propagate the actual value correctly to the PC/SC application, thanks.

[LudovicRousseau]

• dwMaxAPDUDataSize is at the APDU level
• dwMaxCCIDMessageLength is at the CCID level

The CCID driver is using chaining to split a big APDU using shorter CCID messages.

Why do you need to know the dwMaxCCIDMessageLength value?

[frankmorgner]

It's a typical problem in OpenSC (see OpenSC/OpenSC#942, for example) to know how many bytes we can transmit to the card.

I'm not talking about the message size between the driver and the reader. I'm talking about the length of APDUs, the reader is able to transmit to the card. Here, your CCID chaining won't help. Hmm, reading the CCID standard it isn't really clear whether dwMaxCCIDMessageLength is really meant to be on the CCID level (only).

[LudovicRousseau]

dwMaxCCIDMessageLength is used at the CCID level only.

I suspect that @gdsotirov is using the HID Omnikey proprietary driver. I need his results first.

[gdsotirov]

@LudovicRousseau You suspect correctly :-)

[LudovicRousseau]

I also suspect that the HID Omnikey proprietary driver does not implement dwMaxAPDUDataSize so OpenSC is using the defaults values i.e. short APDU only.

The problem is not in my CCID driver. This driver is not used in OpenSC/OpenSC#942

[gdsotirov]

@LudovicRousseau In fact, now that you point this out, I checked and apparently I stopped using your driver about 6 years ago (after suggestion from my certificate provider to use the proprietary driver). I remember the problem was that my bank switched to 2048 bit keys and they didn't worked with libccid at the time. The last version I seem to have used was 1.4.0 from 2010-08-04, but I guess 2048 bit keys are supported by libccid nowadays? If you confirm, then I'll give your driver a try as early as this weekend, because I'll have to prepare new packages for Slackware.

[LudovicRousseau]

@gdsotirov I need the pcscd logs to provide a correct answer.

[gdsotirov]

OK. I'll provide them as soon as possible.

[gdsotirov]

@LudovicRousseau Here's the log from PCSC daemon after plugging my device OmniKey CardMan 6121 reader and using the proprietary driver (see gdsotirov/pcscd.log).

[LudovicRousseau]

You are using this CardMan 6121 https://pcsclite.alioth.debian.org/ccid/shouldwork.html#0x076B0x6622
The reader is declared as "Short APDU level exchange" so my CCID driver respect that and extended APDU are not supported.

But you are using the ifdokccid_linux_x86_64-v4.2.8.bundle driver. I guess this driver has special code to allow extended APDU with this reader.

You can try the following patch with my CCID driver. This may add support of extended APDU to your reader:

+++ src/ccid.c  2017-01-18 20:15:32.000000000 +0100
@@ -475,6 +476,12 @@ int ccid_open_hack_post(unsigned int rea
            ccid_descriptor->dwFeatures |= CCID_CLASS_EXTENDED_APDU;
            break;
 
+       case 0x076B6622:
+           /* Firmware uses chaining */
+           ccid_descriptor->dwFeatures &= ~CCID_CLASS_EXCHANGE_MASK;
+           ccid_descriptor->dwFeatures |= CCID_CLASS_EXTENDED_APDU;
+           break;
+
 #if 0
        /* SCM SCR331-DI contactless */
        case SCR331DI:

[LudovicRousseau]

@gdsotirov, have you tried to use my CCID driver with the patch above?
Does it solve the problem for you?

[gdsotirov]

I haven't had the time, but I'll try to check it this weekend and I'll report back.

[gdsotirov]

OK. I've managed to rebuild also pcsc-tools (and even made LudovicRousseau/pcsc-tools/pull/5), which gives me:

# pcsc_scan
PC/SC device scanner
V 1.4.27 (c) 2001-2011, Ludovic Rousseau <[email protected]>
Compiled with PC/SC lite version: 1.8.18
Using reader plug'n play mechanism
Scanning present readers...
0: OMNIKEY AG CardMan 6121 00 00

Sun Jan 29 16:15:52 2017
Reader 0: OMNIKEY AG CardMan 6121 00 00
  Card state: Card inserted, Shared Mode, 
  ATR: 3B F2 18 00 02 C1 0A 31 FE 58 C8 08 74

ATR: 3B F2 18 00 02 C1 0A 31 FE 58 C8 08 74
+ TS = 3B --> Direct Convention
+ T0 = F2, Y(1): 1111, K: 2 (historical bytes)
  TA(1) = 18 --> Fi=372, Di=12, 31 cycles/ETU
    129032 bits/s at 4 MHz, fMax for Fi = 5 MHz => 161290 bits/s
  TB(1) = 00 --> VPP is not electrically connected
  TC(1) = 02 --> Extra guard time: 2
  TD(1) = C1 --> Y(i+1) = 1100, Protocol T = 1 
-----
  TC(2) = 0A --> Work waiting time: 960 x 10 x (Fi/F)
  TD(2) = 31 --> Y(i+1) = 0011, Protocol T = 1 
-----
  TA(3) = FE --> IFSC: 254
  TB(3) = 58 --> Block Waiting Integer: 5 - Character Waiting Integer: 8
+ Historical bytes: C8 08
  Category indicator byte: C8 (proprietary format)
+ TCK = 74 (correct checksum)

Possibly identified card (using /usr/share/pcsc/smartcard_list.txt):
3B F2 18 00 02 C1 0A 31 FE 58 C8 08 74
        Siemens CardOS V4.3B
        D-Trust multicard 2.1 (may only be the testcard for it)

I started by removing the proprietary CCID driver, installed CCID 1.4.26, restarted PCSC daemon and got this as result:

# pkcs11-tool --module /usr/lib64/onepin-opensc-pkcs11.so -t -l
error: PKCS11 function C_GetSlotInfo failed: rv = CKR_GENERAL_ERROR (0x5)

Aborting.

Then, I applied the patch suggested by @LudovicRousseau in his comment from 2017-01-18 and I got a slightly different result (note that PIN is correctly entered):

# pkcs11-tool --module /usr/lib64/onepin-opensc-pkcs11.so -t -l
Using slot 0 with a present token (0x0)
Logging in to "".
Please enter User PIN: 
error: PKCS11 function C_Login failed: rv = CKR_USER_PIN_NOT_INITIALIZED (0x102)

Aborting.

What's the next step?

[LudovicRousseau]

@gdsotirov Good to know that my patch has an effect.
Can you generate a pcscd log as described in https://pcsclite.alioth.debian.org/ccid.html#support

[gdsotirov]

Sorry, for not providing the log before and sorry for the delay. The new log is new_pcscd.log and after connecting the reader the messages started repeating, so I killed the daemon after few seconds.

[LudovicRousseau]

@gdsotirov the patch does not work to add support of extended APDU.
Your log shows:

00000002 APDU: 00 B0 00 00 00 01 10 
00000003 ifdhandler.c:1303:IFDHTransmitToICC() usb:076b/6622:libudev:0:/dev/bus/usb/005/041 (lun: 0)
00000001 commands.c:1620:CmdXfrBlockAPDU_extended() T=0 (extended): 7 bytes
00000004 -> 000000 6F 07 00 00 00 00 0F 00 00 00 00 B0 00 00 00 01 10 
00000501 <- 000000 80 00 00 00 00 00 0F 40 F6 00 
00000006 commands.c:1520:CCID_Receive Protocol not supported
00000002 SW: 
00000001 ifdwrapper.c:548:IFDTransmit() Card not transacted: 612
00000002 winscard.c:1630:SCardTransmit() Card not transacted: 0x80100016

The reader does not understand the extended APDU 00 B0 00 00 00 01 10.
This is not really surprising.

You are condemned to use the proprietary driver. Sorry.

[LudovicRousseau]

As I wrote in #27 (comment)
"The problem is not in my CCID driver. This driver is not used in OpenSC/OpenSC#942"