[Pcsclite-muscle] ScardControl under Linux?

[Ludovic Rousseau]

Hello Fran?ois,

2017-10-27 12:03 GMT+02:00 Francois Grieu <fgrieu at gmail.com>:

> I am trying to issue a ScardControl to a Smart Card reader. The code works
> under Windows (Identiv driver 4.65), but fails with 0x80100016
> (SCARD_E_NOT_TRANSACTED) under Linux Centos 6, pcscd 1.5.2
>
> Am I missing something obvious?
>
> If that matters: the reader is a Teo by Xiring/Ingenico SCR35xx
> (USB\VID_04E6&PID_5410) recognizable by having a green-only led, when the
> Omnikey variant (USB\VID_076B&PID_A022) has a led that briefly goes from
> green to red on card insertion. The ScardControl is intended to adjust the
> clock frequency to 8 MHz (after ATR and PPS negociation). It fails, and CLK
> remains as the default (I guess 4.8 MHz).
>
> The code goes:
>
> // SCM Microsystems Inc. SCR35xx (USB\VID_04E6&PID_5410) control code to
> change Clk
> //
> // To be issued only on this reader, after ATR and PPS negotiation, and
> after
> // deep considerations on the risks.
> //
> // Second parameter controls the clock frequency, according to  f =
> 48/(48-n) MHz
> //   n : 36   37       38     39       4   41       42   43    44
> //   f :  4    4.364    4.8    5.333   6    6.857    8    9.6  12 MHz
> //
> // Many causes conspire to make use of this call risky:
> //
> // * For n>36 and absent a declaration in the ATR, f is larger than the
> minimum
> //   for cards (5 MHz during ATR, 4 MHz after) specified by ISO/IEC
> 7816-3).
> //   However:
> //   - In my practice, the hardware of integrated circuits used for Smart
> Cards
> //     manufactured after 2005 (resp. 1995) is explicitly specified to at
> least
> //     8 MHz (resp. 5 MHz), and commonly 10 MHz.
> //   - Usually, their software also works to that frequency;
> //   - Commonly, it implements the turnaround delay specified by EMV when
> the
> //     direction of communication on I/O changes;
> //   - When that later condition applies at least, n = 42 works reliably,
> //     and I have yet to see n = 43 fail.
> //   - A card's TA1 (if present) states a value of  f  that the card
> promises
> //     if usable; for example, TA1=B7h is a promises that the card accepts
> //     f = 10 MHz. If it then accepts a PPS to
> //   - a card can advertise
> //
> // * Propagation delays and capacitance conspire to deform clock.
> //
> // * For n odd and n>40 (perhaps n=39), the duty cycles is out of
> //   ISO/IEC 7816-3 specs ( 40% to 60% ); however, in practice, cards are
> //   quite tolerant on that if neither the maximum frequency nor minimum
> low
> //   and high time are violated.
> //
> // * There is no insurance that when the clock switches, there is no glitch
> //   violating said minimums.
> //
> // * ISO/IEC 7816-3 specs is ambiguous about if a card with TA1=00h or no
> TA1
> //   must accept Clk about 4 MHz beyond the ATR; however, it is safe to
> assume
> //   that any card made after 1995 does.
> //
> // * The values to use for the SCR35xx are undocumented AFAIK; the control
> code
> //   is documented for another SCM reader, search CCID_ESC_CLK_FREQUENCY,
> or
> //   http://www.epsys.no/downloads/pdf/RM_MAXX_lite.pdf
> //
>     const uint8_t rControlCode[2] = { 0x1F, 42 }; // n = 42, f = 48/(48-n)
> = 8 MHz
>     uint8_t vBuf[4];    // placeholder for possible result (ignored)
>     vResult = SCardControl (
>         gReaderTable[Nb].gCardHandle,
>         SCARD_CTL_CODE( 0xDAC ),
>         rControlCode,
>         sizeof(rControlCode),
>         vBuf,
>         sizeof(vBuf),
>         &dwState
>         );


My CCID driver does not know this SCARD_CTL_CODE( 0xDAC ) code.
Maybe you can use a Xiring or Omnikey (proprietary) driver with support of
this control code.

Bye

-- 
 Dr. Ludovic Rousseau
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pcsclite-muscle/attachments/20171027/d5800ff6/attachment-0001.html>