Looking/developing magstripe API

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Looking/developing magstripe API

Dmitry Eremin-Solenikov
Hello,

I have been looking for the API to access MagStripe readers for quite
some time. Are there any plans to add
magstripe extension to the PC/SC (or proprietary extension to
pcsc-lite)? It would be extremely useful to
receive such data from hybrid (ICC + stripe) readers.

--
With best wishes
Dmitry

_______________________________________________
Pcsclite-muscle mailing list
[hidden email]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle
Reply | Threaded
Open this post in threaded view
|

Re: Looking/developing magstripe API

Martin Paljak-4
What would be your usecase?

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.

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).



On Sat, 7 May 2016 at 12:31 Dmitry Eremin-Solenikov <[hidden email]> wrote:
Hello,

I have been looking for the API to access MagStripe readers for quite
some time. Are there any plans to add
magstripe extension to the PC/SC (or proprietary extension to
pcsc-lite)? It would be extremely useful to
receive such data from hybrid (ICC + stripe) readers.

--
With best wishes
Dmitry

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

_______________________________________________
Pcsclite-muscle mailing list
[hidden email]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle
Reply | Threaded
Open this post in threaded view
|

Re: Looking/developing magstripe API

Dmitry Eremin-Solenikov
Hello,

2016-05-08 8:05 GMT+03:00 Martin Paljak <[hidden email]>:
> 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.

> On Sat, 7 May 2016 at 12:31 Dmitry Eremin-Solenikov <[hidden email]>
> wrote:
>>
>> Hello,
>>
>> I have been looking for the API to access MagStripe readers for quite
>> some time. Are there any plans to add
>> magstripe extension to the PC/SC (or proprietary extension to
>> pcsc-lite)? It would be extremely useful to
>> receive such data from hybrid (ICC + stripe) readers.
>>
>> --
>> With best wishes
>> Dmitry
>>
>> _______________________________________________
>> Pcsclite-muscle mailing list
>> [hidden email]
>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle
>
>
> _______________________________________________
> Pcsclite-muscle mailing list
> [hidden email]
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle



--
With best wishes
Dmitry

_______________________________________________
Pcsclite-muscle mailing list
[hidden email]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle
Reply | Threaded
Open this post in threaded view
|

Re: Looking/developing magstripe API

Bruno Jesus
On Sun, May 8, 2016 at 5:41 PM, Dmitry Eremin-Solenikov
<[hidden email]> wrote:

> Hello,
>
> 2016-05-08 8:05 GMT+03:00 Martin Paljak <[hidden email]>:
>> 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

_______________________________________________
Pcsclite-muscle mailing list
[hidden email]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle
Reply | Threaded
Open this post in threaded view
|

Re: Looking/developing magstripe API

David Corcoran
In reply to this post by Dmitry Eremin-Solenikov
Hello,

I've seen hybrid readers in the past implement a custom SCardControl sequence that would allow manipulation of the mag stripe interface.  I'm not sure if anything was ever standardized though.
At least in that manner you can still operate within the context of the resource manager and enjoy the transaction features as well.

https://msdn.microsoft.com/en-us/library/windows/desktop/aa379474(v=vs.85).aspx

DC


Sent from my iPhone

On May 7, 2016, at 5:31 AM, Dmitry Eremin-Solenikov <[hidden email]> wrote:

Hello,

I have been looking for the API to access MagStripe readers for quite
some time. Are there any plans to add
magstripe extension to the PC/SC (or proprietary extension to
pcsc-lite)? It would be extremely useful to
receive such data from hybrid (ICC + stripe) readers.

--
With best wishes
Dmitry

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

_______________________________________________
Pcsclite-muscle mailing list
[hidden email]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle
Reply | Threaded
Open this post in threaded view
|

Re: Looking/developing magstripe API

Dmitry Eremin-Solenikov
Hello,

2016-05-08 14:11 GMT+03:00 David Corcoran <[hidden email]>:
> Hello,
>
> I've seen hybrid readers in the past implement a custom SCardControl
> sequence that would allow manipulation of the mag stripe interface.  I'm not
> sure if anything was ever standardized though.
> At least in that manner you can still operate within the context of the
> resource manager and enjoy the transaction features as well.
>
> https://msdn.microsoft.com/en-us/library/windows/desktop/aa379474(v=vs.85).aspx

Thanks for the pointer to SCardControl.

Related question: would it be a suitable design, if I implement a
swipe magstripe
reader driver as a simple IFDHandler, not supporting any real ICC functions,
with SCardConnect always returning e.g. SCARD_W_UNRESPONSIVE_CARD,
and just reporting insert event after stripe was read by hw and eject
event after
the app reads the stripe data from the driver (via proprietary
SCardControl call).
Does that sound tooo crazy?

>
> DC
>
> Sent from my iPhone
>
> On May 7, 2016, at 5:31 AM, Dmitry Eremin-Solenikov <[hidden email]>
> wrote:
>
> Hello,
>
> I have been looking for the API to access MagStripe readers for quite
> some time. Are there any plans to add
> magstripe extension to the PC/SC (or proprietary extension to
> pcsc-lite)? It would be extremely useful to
> receive such data from hybrid (ICC + stripe) readers.



--
With best wishes
Dmitry

_______________________________________________
Pcsclite-muscle mailing list
[hidden email]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle
Reply | Threaded
Open this post in threaded view
|

Re: Looking/developing magstripe API

Ludovic Rousseau
2016-05-09 1:00 GMT+02:00 Dmitry Eremin-Solenikov <[hidden email]>:
Hello,

2016-05-08 14:11 GMT+03:00 David Corcoran <[hidden email]>:
> Hello,
>
> I've seen hybrid readers in the past implement a custom SCardControl
> sequence that would allow manipulation of the mag stripe interface.  I'm not
> sure if anything was ever standardized though.
> At least in that manner you can still operate within the context of the
> resource manager and enjoy the transaction features as well.
>
> https://msdn.microsoft.com/en-us/library/windows/desktop/aa379474(v=vs.85).aspx

Thanks for the pointer to SCardControl.

Related question: would it be a suitable design, if I implement a
swipe magstripe
reader driver as a simple IFDHandler, not supporting any real ICC functions,
with SCardConnect always returning e.g. SCARD_W_UNRESPONSIVE_CARD,
and just reporting insert event after stripe was read by hw and eject
event after
the app reads the stripe data from the driver (via proprietary
SCardControl call).
Does that sound tooo crazy?

That may work.
Your IFD will not return an error code for SCardConnect(). SCardConnect() is not a function if the IFDHandler. The IFDhandler API (for pcsc-lite) is defined in [1].

Why do you want to use PC/SC if your application needs to use specific code to use SCardControl() and then will not be a normal PC/SC application?
It may be simpler to define your own specific API to read a magstripe.

Bye

--
 Dr. Ludovic Rousseau

_______________________________________________
Pcsclite-muscle mailing list
[hidden email]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle
Reply | Threaded
Open this post in threaded view
|

Re: Looking/developing magstripe API

Dmitry Eremin-Solenikov
2016-05-09 10:47 GMT+03:00 Ludovic Rousseau <[hidden email]>:

> 2016-05-09 1:00 GMT+02:00 Dmitry Eremin-Solenikov <[hidden email]>:
>>
>> Hello,
>>
>> 2016-05-08 14:11 GMT+03:00 David Corcoran <[hidden email]>:
>> > Hello,
>> >
>> > I've seen hybrid readers in the past implement a custom SCardControl
>> > sequence that would allow manipulation of the mag stripe interface.  I'm
>> > not
>> > sure if anything was ever standardized though.
>> > At least in that manner you can still operate within the context of the
>> > resource manager and enjoy the transaction features as well.
>> >
>> >
>> > https://msdn.microsoft.com/en-us/library/windows/desktop/aa379474(v=vs.85).aspx
>
> Why do you want to use PC/SC if your application needs to use specific code
> to use SCardControl() and then will not be a normal PC/SC application?
> It may be simpler to define your own specific API to read a magstripe.


Surely, that is an option (and I'll probably end up with just writing
a lib to work
with magstripe readers). I was mostly concerned about hybrid ICC+stripe readers
(used one several years ago at work). I wanted to have an interface that would
work with both hybrid and stripe-only readers. However it seems that hybrids are
so rare in real world, that I should not care about them.

--
With best wishes
Dmitry

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