Re: Looking/developing magstripe API

On Sun, May 8, 2016 at 5:41 PM, Dmitry Eremin-Solenikov
<[email protected]> wrote:
> Hello,
>
> 2016-05-08 8:05 GMT+03:00 Martin Paljak <[email protected]>:
>> What would be your usecase?
>
> I'm toying with the set of tools working with EMV cards
> (github.com/lumag/emv-tools).
>
>> First of all, do you know of any mainstream enduser devices that provide
>> simultaneous reading of both the chip and magstripe, via the same interface?
>> I expect such devices exist in the ATM OEM industry, but have no idea about
>> the interfaces they provide.
>
> Not at this moment. I had a hybrid desktop card reader several years ago, but
> I've never checked what was the actual interface between the host and
> the reader.
>
>> How would that work? There are no existing standard drivers (except for
>> serial interfaces) for magstripe readers I know of. There is no API in the
>> winscard interface for this (introducing arbitrary SCardReadMagstripe would
>> be as useful as some HSM companies having "standard PKCS#11 modules" with
>> extra C_* functions not described by spec nor implemented in interoperable
>> software).
>
> Yes, that is the point for my original question. Right now I'm using the USB
> reader using HID interface (either proprietary or keyboard class). I of course
> can include all drivers into my tool, however that seems counterproductive.
>
> I'd go for writing a shared library or shared resource daemon (like PC/SC),
> if there was no question about hybrid or shared in any other way readers.

The problem I see is that swipe magstripe readers work in a different
way to smart cards. In smart cards you either insert (contact card) or
touch/lay (contactless card) on the reader. By doing this you can go
all the way with the smart card API: list reader, connect, transmit,
disconnect.

In a swipe mag stripe reader you just swipe the card and that's it.
You no longer have the card, only the data in the tracks (1, 2 or 3
tracks AFAIR). You could have a swallow mag stripe reader too, like in
ATM machines from some countries, and in that way it could be more
similar to the standard smart card API.

I faced this problem in a previous job, our requirements were to read
the track 1 (where the bank card number is stored) in a transparent
way to the smart card API. We had 2 different approaches:

1 - Put the card number in a custom ATR. By doing this it was just
need a connect call to the API and then it was done since all we
needed was the card number. Each card digit was encoded in nibbles to
save space.

2 - The second approach was a bit more complex. We designed a custom
fixed ATR for "magnetic cards". And then added a virtual 00C00000xx
(GET RESPONSE) APDU to receive the card data. So when the application
detected that ATR it issued the GET RESPONSE command and had the card
number.

So I would go to making a custom CCID library for pcsclite that talks
to the mag reader by waiting data and then decoding it and making this
"virtual smart card" to the standard smart card API.

I hope it helps, best regards,
Bruno