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 _______________________________________________ Pcsclite-muscle mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle
