[Pcsclite-muscle] PCSC 10 - Class 2

[Michael StJohns]

Hi Ludovic -


I got a bit curious about how the VerifyPinStart/ModifyPinStart worked 
for two of the smart card readers I have - the Gemalto CT700 and the SCM 
SPR332v2.  I ended up downloading Wireshark with the USBPCap capture 
module and ran a few captures.


The answer for how they do _START_FINISH vs _DIRECT is remarkably 
similar, but different enough that it's probably not possible to do this 
in a single implementation without a lot of special casing.

The Gemalto uses the exact same sequence of USB commands for both 
_DIRECT and _START/_FINISH. Basically, the driver sends  the 
PC_TO_RDR_SECURE command (same in both cases), and the uses the URB_BULK 
command to poll the reader.   The reader returns a CCID data block 
(after the _SECURE command and after each poll).  If the pin entry isn't 
complete, it returns one of the codes from GET_KEY_PRESSED as an error 
code (and sets the more time needed bit) if a key has been pressed, or 
blocks until the key is pressed or timed out.  If the entry is complete, 
the device returns the appropriate SW1SW2 pair and sets the error code 
to successful.    Thinking about this model, the driver might simply 
poll on demand (GET_KEY_PRESSED) or repeatedly (_DIRECT) until the 
action completes.

The SCM does something similar to the Gemalto - but uses interrupts 
rather than polling to get the data back.    The PC_TO_RDR_SECURE data 
structures transferred to the reader are one byte longer than is defined 
in the CCID specification (at least the 2005 version).  The extra byte I 
recorded differed by a bit between _START and _DIRECT but may actually 
not have any impact on the protocol.   In any event, both _START and 
_DIRECT seem to use the exact same interrupt driven model to transfer 
key press information - URB_INTERRUPT - which carries 2 bytes of 
data.    (there's an _ESCAPE command that preceeds the _SECURE call, but 
I can't find documentation on its meaning...)   Unfortunately, the data 
provided by the interrupt does not map cleanly to  the values of 
GET_KEY_PRESSED.    When the PC gets an interrupt indicating that the 
verify process is complete, it calls URB_BULK to retrieve the SW1SW2.  
It looks like the driver just keeps track of what information it has 
handed to the calling process and does the right thing, either on a call 
by call basis (GET_KEY_PRESSED with _FINISH) or at the finish for _DIRECT.

I'm not sure if any of this is helpful, but thought you might find it 
interesting.

Later, Mike







On 2/4/2021 7:50 PM, Michael StJohns wrote:
> Hmm... I should have looked here first: 
> https://ludovicrousseau.blogspot.com/2011/10/  with respect your 
> library and its support for these command sequences.
>
> Thanks - Mike
>
>
> On 2/4/2021 5:50 PM, Michael StJohns wrote:
>> On 2/4/2021 4:23 PM, Ludovic Rousseau wrote:
>>> Le jeu. 4 févr. 2021 à 17:24, Michael StJohns <mstjohns at comcast.net> a
>>> écrit :> Hi -
>>>
>>> Hello,
>>>
>>>> I'm looking for guidance that appears to be missing from the PCSC part
>>>> 10 - specifically how ModifyPinStart/ModifyPinFinish/GetKeyPressed
>>>> behave in the face of the normal, old pin/new pin/new pin again 
>>>> pattern
>>>> for changing a pin.   It's not directly tied to pcsc-lite, but I 
>>>> figured
>>>> since Ludovic had a hand in writing the specs....
>>> I never played with the ModifyPinStart/ModifyPinFinish/GetKeyPressed 
>>> features.
>>>
>>> I guess you are using Windows? Or at least _not_ my CCID driver. Exact?
>>>
>>> Bye
>>>
>> Hi Ludovic -
>>
>> I'm actually using Java as the high level language with the desire to 
>> make this work over both Windows and Linuxm  so both. On the linux 
>> side I may or may not have been using your CCID driver for a given 
>> reader - to be honest I've lost track of what last worked when I was 
>> on Linux.  I've had mostly good luck with normal PCSC interactions on 
>> both platforms with with the occasional exception where a reader 
>> works in extended APDU mode on Windows, but not on Linux.
>>
>> I've also had reasonable luck finding a generic VerifyPin/ModifyPin 
>> structure that works across at least a few Pinpad readers with LCDs.  
>> Now I'm branching out to verify similar operating models for Pinpad 
>> readers without LCDs hence the question about 
>> ModifyPinStart/Finish/KeyPressed/Abort.
>>
>> I'm guessing how thing should work - so next step is to write a test 
>> program and see for sure.
>>
>> Thanks - Mike
>>
>>
>>
>>
>>
>> _______________________________________________
>> pcsclite-muscle mailing list
>> pcsclite-muscle at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/pcsclite-muscle
>
>
>
> _______________________________________________
> pcsclite-muscle mailing list
> pcsclite-muscle at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/pcsclite-muscle