[Pcsclite-muscle] issues with OmniKey 3121 and InCard cards

[Umberto Rustichelli]

On 05/08/2018 04:50 PM, Ludovic Rousseau wrote:
> Hello,
>
> 2018-05-08 15:41 GMT+02:00 Umberto Rustichelli<umberto.rustichelli at gt50.org>:
>> Respectable, my knowledge of the SW stack to use smart cards is very
>> limited, so please forgive me if I'm missing something here... I need to
>> understand what is the possible problem here.
>>
>> Recently my company received a batch of cards,
>>
>> most with ATR
>> 3b:ff:96:00:ff:81:31:fe:55:00:6b:02:09:04:03:01:01:01:43:4e:53:10:31:80:14
>>
>> some with ATR
>> 3b:ff:18:00:00:81:31:fe:55:00:6b:02:09:04:03:01:01:01:43:4e:53:10:31:80:65
>>
>> They are supposed to be used with the proprietary driver libbi4ixpki.so, I
>> have three versions of it.
>>
>> The combination work fine with some readers but I have issue with two
>> products, one being the reader OmniKey 3121, the main issue being that I
>> cannot generate a key pair on the tokens (both ATR).
>>
>> Software in use: Slackware current (but the issue has been replicated with
>> Slackware 14.1 and RHEL 6, too), pcsc-lite-1.8.23, ccid-1.4.29,
>> opensc-0.18.0-rc2 and the PKCS#11 module libbi4ixpki.so (all versions in my
>> possession).
>>
>> With some libbi4ixpki.so drivers and depending on the ATR, I may also see
>> "pcscd: commands.c:2280:SetParameters Card absent or mute" during some
>> operations, but the main issue remains the key generation (2048 bit) where I
>> see, after login has been performed, so the issue manifests during
>> C_GenerateKeyPair:
>>
>> May  8 11:54:24 longrun pcscd: commands.c:2280:SetParameters Card absent or
>> mute
>> May  8 11:54:26 longrun pcscd: commands.c:1771:CmdXfrBlockTPDU_T0() Command
>> too long (290 bytes) for max: 261 bytes
>> May  8 11:54:26 longrun pcscd: ifdwrapper.c:543:IFDTransmit() Card not
>> transacted: 612
>> May  8 11:54:26 longrun pcscd: winscard.c:1620:SCardTransmit() Card not
>> transacted: 0x80100016
>>
>> What can I do to fix this? Can I tweak pcsc or ccid or opensc to deal with
>> this, or is it an issue with the proprietary driver? Or is it a bug? In
>> ccid? PCSC-lite?
>>
>> By the question you surely understand I have little knowledge of the
>> architecture (and also of runtime configuration). Any clue?
>>
>> Thanks - Umberto
> My best guess is that for 2048-bits keys (256 bytes) the PKCS#11
> library uses extended APDU commands.
> Some readers (~35%) do not support extended APDU.
> Seehttps://ludovicrousseau.blogspot.fr/2011/05/extended-apdu-status-per-reader.html
> for more details.
>
> The solution is to use only readers that support extended APDU.
> You can get a list athttps://ccid.apdu.fr/ccid_extended_apdu.html

Thanks a lot, Ludovic.

I'm sorry but likely I misunderstood commit 
3b29cc5afbbe27bb5421d334623bbd07c574bbf8 (see later), I thought it meant 
that a fix was applied because the reader supports Extended APDU it in 
spite of not declaring it. But the phrase may also point to what 
preceded, not followed, the "also support Extended APDU".

   Umberto Rustichelli

THE OLD COMMIT EXCERPT:

commit 3b29cc5afbbe27bb5421d334623bbd07c574bbf8
Author: Ludovic Rousseau <ludovic.rousseau at free.fr>
Date:   Sat Aug 19 23:20:09 2017 +0200

     Fix non-pinpad HID global devices
     [...]
     The USB descriptor is bogus.
     The readers also support Extended APDU even if they declare Short 
APDU.
     Bogus readers are:
     - OMNIKEY Generic
     - OMNIKEY 3121 or 3021 or 1021
     - [...]