Re: ScardControl under Linux?

--===============2441931555735103158==
Content-Type: multipart/alternative; boundary="001a1145e7247a4fe7055c85310e"

--001a1145e7247a4fe7055c85310e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello Fran=C3=A7ois,

2017-10-27 12:03 GMT+02:00 Francois Grieu <[email protected]>:

> I am trying to issue a ScardControl to a Smart Card reader. The code work=
s
> 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 th=
e
> clock frequency to 8 MHz (after ATR and PPS negociation). It fails, and C=
LK
> 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 =3D
> 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 =3D 42 works reliabl=
y,
> //     and I have yet to see n =3D 43 fail.
> //   - A card's TA1 (if present) states a value of  f  that the card
> promises
> //     if usable; for example, TA1=3DB7h is a promises that the card acce=
pts
> //     f =3D 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=3D39), 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 glit=
ch
> //   violating said minimums.
> //
> // * ISO/IEC 7816-3 specs is ambiguous about if a card with TA1=3D00h 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 contro=
l
> 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] =3D { 0x1F, 42 }; // n =3D 42, f =3D 48=
/(48-n)
> =3D 8 MHz
>     uint8_t vBuf[4];    // placeholder for possible result (ignored)
>     vResult =3D 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

--=20
 Dr. Ludovic Rousseau

--001a1145e7247a4fe7055c85310e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hello Fran=C3=A7ois,<br><div><div class=3D"gmail_extra"><b=
r><div class=3D"gmail_quote">2017-10-27 12:03 GMT+02:00 Francois Grieu <spa=
n dir=3D"ltr">&lt;<a href=3D"mailto:[email protected]" target=3D"_blank">fgr=
[email protected]</a>&gt;</span>:<br><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex">I am trying to issue a ScardControl to a Smart Card reader. The cod=
e works under Windows (Identiv driver 4.65), but fails with 0x80100016 (SCA=
RD_E_NOT_TRANSACTED) under Linux Centos 6, pcscd 1.5.2<br>
<br>
Am I missing something obvious?<br>
<br>
If that matters: the reader is a Teo by Xiring/Ingenico SCR35xx (USB\VID_04=
E6&amp;PID_5410) recognizable by having a green-only led, when the Omnikey =
variant (USB\VID_076B&amp;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 remai=
ns as the default (I guess 4.8 MHz).<br>
<br>
The code goes:<br>
<br>
// SCM Microsystems Inc. SCR35xx (USB\VID_04E6&amp;PID_5410) control code t=
o change Clk<br>
//<br>
// To be issued only on this reader, after ATR and PPS negotiation, and aft=
er<br>
// deep considerations on the risks.<br>
//<br>
// Second parameter controls the clock frequency, according to=C2=A0 f =3D =
48/(48-n) MHz<br>
//=C2=A0=C2=A0 n : 36=C2=A0=C2=A0 37=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 38=
=C2=A0=C2=A0=C2=A0=C2=A0 39=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 4=C2=A0=C2=
=A0 41=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 42=C2=A0=C2=A0 43=C2=A0=C2=A0=C2=
=A0 44<br>
//=C2=A0=C2=A0 f :=C2=A0 4=C2=A0=C2=A0=C2=A0 4.364=C2=A0=C2=A0=C2=A0 4.8=C2=
=A0=C2=A0=C2=A0 5.333=C2=A0=C2=A0 6=C2=A0=C2=A0=C2=A0 6.857=C2=A0=C2=A0=C2=
=A0 8=C2=A0=C2=A0=C2=A0 9.6=C2=A0 12 MHz<br>
//<br>
// Many causes conspire to make use of this call risky:<br>
//<br>
// * For n&gt;36 and absent a declaration in the ATR, f is larger than the =
minimum<br>
//=C2=A0=C2=A0 for cards (5 MHz during ATR, 4 MHz after) specified by ISO/I=
EC 7816-3).<br>
//=C2=A0=C2=A0 However:<br>
//=C2=A0=C2=A0 - In my practice, the hardware of integrated circuits used f=
or Smart Cards<br>
//=C2=A0=C2=A0=C2=A0=C2=A0 manufactured after 2005 (resp. 1995) is explicit=
ly specified to at least<br>
//=C2=A0=C2=A0=C2=A0=C2=A0 8 MHz (resp. 5 MHz), and commonly 10 MHz.<br>
//=C2=A0=C2=A0 - Usually, their software also works to that frequency;<br>
//=C2=A0=C2=A0 - Commonly, it implements the turnaround delay specified by =
EMV when the<br>
//=C2=A0=C2=A0=C2=A0=C2=A0 direction of communication on I/O changes;<br>
//=C2=A0=C2=A0 - When that later condition applies at least, n =3D 42 works=
 reliably,<br>
//=C2=A0=C2=A0=C2=A0=C2=A0 and I have yet to see n =3D 43 fail.<br>
//=C2=A0=C2=A0 - A card&#39;s TA1 (if present) states a value of=C2=A0 f=C2=
=A0 that the card promises<br>
//=C2=A0=C2=A0=C2=A0=C2=A0 if usable; for example, TA1=3DB7h is a promises =
that the card accepts<br>
//=C2=A0=C2=A0=C2=A0=C2=A0 f =3D 10 MHz. If it then accepts a PPS to<br>
//=C2=A0=C2=A0 - a card can advertise<br>
//<br>
// * Propagation delays and capacitance conspire to deform clock.<br>
//<br>
// * For n odd and n&gt;40 (perhaps n=3D39), the duty cycles is out of<br>
//=C2=A0=C2=A0 ISO/IEC 7816-3 specs ( 40% to 60% ); however, in practice, c=
ards are<br>
//=C2=A0=C2=A0 quite tolerant on that if neither the maximum frequency nor =
minimum low<br>
//=C2=A0=C2=A0 and high time are violated.<br>
//<br>
// * There is no insurance that when the clock switches, there is no glitch=
<br>
//=C2=A0=C2=A0 violating said minimums.<br>
//<br>
// * ISO/IEC 7816-3 specs is ambiguous about if a card with TA1=3D00h or no=
 TA1<br>
//=C2=A0=C2=A0 must accept Clk about 4 MHz beyond the ATR; however, it is s=
afe to assume<br>
//=C2=A0=C2=A0 that any card made after 1995 does.<br>
//<br>
// * The values to use for the SCR35xx are undocumented AFAIK; the control =
code<br>
//=C2=A0=C2=A0 is documented for another SCM reader, search CCID_ESC_CLK_FR=
EQUENCY, or<br>
//=C2=A0=C2=A0 <a href=3D"http://www.epsys.no/downloads/pdf/RM_MAXX_lite.pd=
f" rel=3D"noreferrer" target=3D"_blank">http://www.epsys.no/downloads/<wbr>=
pdf/RM_MAXX_lite.pdf</a><br>
//<br>
=C2=A0=C2=A0=C2=A0 const uint8_t rControlCode[2] =3D { 0x1F, 42 }; // n =3D=
 42, f =3D 48/(48-n) =3D 8 MHz<br>
=C2=A0=C2=A0=C2=A0 uint8_t vBuf[4];=C2=A0=C2=A0=C2=A0 // placeholder for po=
ssible result (ignored)<br>
=C2=A0=C2=A0=C2=A0 vResult =3D SCardControl (<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 gReaderTable[Nb].gCardHandle,<br=
>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SCARD_CTL_CODE( 0xDAC ),<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 rControlCode,<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sizeof(rControlCode),<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 vBuf,<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sizeof(vBuf),<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 &amp;dwState<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 );<span class=3D"gmail-HOEnZb"><=
/span></blockquote><div><br></div><div>My CCID driver does not know this SC=
ARD_CTL_CODE( 0xDAC ) code.</div><div>Maybe you can use a Xiring or Omnikey=
 (proprietary) driver with support of this control code.</div><div><br></di=
v><div>Bye<br clear=3D"all"></div></div><br>-- <br><div class=3D"gmail_sign=
ature">=C2=A0Dr. Ludovic Rousseau</div>
</div></div></div>

--001a1145e7247a4fe7055c85310e--


--===============2441931555735103158==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Pcsclite-muscle mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle
--===============2441931555735103158==--