Hi!
A couple of months ago, I started implementing "librfid" (https://svn.gnumonks.org/trunk/librfid/), a GPL licensed ISO-14443 (and later probably 15694, Mifare and others) software stack. The only device it supports as of now is the Omnikey CardMan 5121 (since it was the cheapest available RFID reader I could find). Unfortunately (as usual), Omnikey is not very friendly to the Free Software community and just provide some binary-only x86 driver for it. I've re-engineered the low-level bits of it, and implemented the RFID protocol stack based on the publicly available standard documents. With that device, the whole protocol logic is running on the host PC, not in the firmware of the reader. This is very much unlike most other RFID readers on the market (whihc tend to appear as a contact-based smartcard reader to the host). The "problem" is how to interface such devices with OpenCT. First of all, why use OpenCT at all? Because the 5121 supports contact based and contactless operation. It's already supported by the OpenCT ifd-ccid driver. OTOTH, legacy applications (especially for dual interface cards), will probably want to use the same API for both contact-based and contactless cards. Therefore, interfacing contactless cards via OpenCt seems desirable. There's a fundamental "impedance mismatch" between the contact-based and the contactless world. One fundamental problem, just as example: A contacless reader can have any number of (virtual) slots, since by using CID (card_id), the ISO 14443 protocol allows a reader to simultaneously talk to multiple PICC's (cards/tags). In many ways, the RFID stack is more like a TCP/IP stack, dealing with ACK's, retransmissions, ... The RFID protocol stack is in itself quite complex, and requires many timers, etc. So fully building it into OpenCT also doesn't really sound like a good idea. I've come up with the following kludge: 1) export the PC_TO_RDR_ESCAPE based interface to the RFID Reader ASIC (Philips RC632) as a virtual slot (always the last slot number 2 of the cm5121). This virtual slot supports only one special protocol: The "ESCAPE" protocol. 2) The RFID software stack opens this virtual slot to talk to the RFID Reader ASIC using the OpenCT API (CT_Card_Transact). 3) The RFID software stack implements the various protocols and protocol layers 4) The RFID software stack registers a number of slots as ifd-handler with OpenCT. The slots provide access to protocols like T=CL. My implementation has so far proceeded to some point within '3'. I do not yet have the ifd_handler part done yet. Since my time is limited, I currently don't have a timeframe for this. I'm concurrently also working on libmrtd (https://svn.gnumonks.org/trunk/libmtrd/), a library to access ICAO MRTD compliant electronic Passports. It uses the PC/SC API - not because I like it buy this way libmrtd will run on many different readers/stacks, including the omnikey proprietary one (which might be good for debugging). Please let me know of any issues you see with this approach. Attached is the patch implementing part "1" of the outline above. -- - Harald Welte <[hidden email]> http://gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) _______________________________________________ opensc-devel mailing list [hidden email] http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel |
I'm a bit surprised that five days after my posting on this subject
nobody has replied so far. I would really appreciate some comments (like: "go ahead", "you're nuts", "why not do it like this:...", ...). Thanks! -- - Harald Welte <[hidden email]> http://gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) _______________________________________________ opensc-devel mailing list [hidden email] http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel |
In reply to this post by Harald Welte
Hi Harald,
sorry for not answering earlier. maybe "now news is good news"? :) honestly, I wrote a few t=1 drivers, but don't know much else, neither t=0 nor pcsc nor rfid well, so I hope everyone else will comment on your posting. so here are those few things I'm thinking about: > A couple of months ago, I started implementing "librfid" > (https://svn.gnumonks.org/trunk/librfid/), a GPL licensed ISO-14443 (and > later probably 15694, Mifare and others) software stack. GPL'ed? for a library? so no non-GPL'ed use at all? or would it be ok to have some interface (like the pkcs#11) and allow any app to use that interface? or even lower: openct has kind of a client/server model and the client lib is BSD licensed. so any app can use the client lib to access the BSD/LGPL server. would that be still ok with adding your code, or would you - "mysql style" - argue the license also affects the client? > The RFID protocol stack is in itself quite complex, and requires many > timers, etc. So fully building it into OpenCT also doesn't really sound > like a good idea. how else would an application use it? for example how would opensc use a wireless smart card using your reader / stack? > 2) The RFID software stack opens this virtual slot to talk to the RFID > Reader ASIC using the OpenCT API (CT_Card_Transact). > > 3) The RFID software stack implements the various protocols and protocol > layers > > 4) The RFID software stack registers a number of slots as ifd-handler > with OpenCT. The slots provide access to protocols like T=CL. hmm, so the user would see one reader it can't use (escape protocol). you could as well link in all you need from src/ifd/ and thus not need that extra indirection - whatever is easier for you. would you create new readers on demand as the reader finds new cards within range, or would you create a number of virtual readers and fill those slots with cards? are you planing for a complex single threaded rfid stack, a multi threaded or one with several processes? openct code currently is written with the assumption of once process pre reader and thus quite simple, but thus might lack feature you want. > I'm concurrently also working on libmrtd > (https://svn.gnumonks.org/trunk/libmtrd/), a library to access ICAO MRTD > compliant electronic Passports. It uses the PC/SC API - not because I > like it buy this way libmrtd will run on many different readers/stacks, > including the omnikey proprietary one (which might be good for > debugging). so that omnikey driver is a simple ifdhandler driver and you need to implement the rfid protocols on top of pcsc? learned something new again. (looks to me like they changed the concept/stacking, but it wasn't a good idea to have every driver reimplement basic protocols anyway). that patch looks fine with me. shall I apply? Regards, Andreas _______________________________________________ opensc-devel mailing list [hidden email] http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel |
On Mon, Sep 12, 2005 at 12:32:13AM +0200, Andreas Jellinghaus wrote:
> Hi Harald, > > sorry for not answering earlier. > maybe "now news is good news"? :) yes, I though that. > honestly, I wrote a few t=1 drivers, but don't know > much else, neither t=0 nor pcsc nor rfid well, so > I hope everyone else will comment on your posting. no problem. > so here are those few things I'm thinking about: > > > A couple of months ago, I started implementing "librfid" > > (https://svn.gnumonks.org/trunk/librfid/), a GPL licensed ISO-14443 (and > > later probably 15694, Mifare and others) software stack. > > GPL'ed? for a library? so no non-GPL'ed use at all? That was my initial idea. We do the same for our libraries in the netfilter project. Maybe we could work out an "openct exception". > or would it be ok to have some interface (like the pkcs#11) > and allow any app to use that interface? I'm not quite sure. For the time being, I'd rather keep it GPL (until somebody asks me with a specific usage case where it won't work). It's not in a 'production ready' state anyway. Since I'm the only copyright holder of librfid, I can change it later on. > or even lower: openct has kind of a client/server model and the client > lib is BSD licensed. so any app can use the client lib to access the > BSD/LGPL server. would that be still ok with adding your code, or > would you - "mysql style" - argue the license also affects the client? Independent of what I argue, I think that such an argument (in the OpenCT case) would not stand any legal chances. So don't let's go there. > > The RFID protocol stack is in itself quite complex, and requires many > > timers, etc. So fully building it into OpenCT also doesn't really sound > > like a good idea. > > how else would an application use it? for example how would opensc > use a wireless smart card using your reader / stack? it would open the "second" reader device (the one with one slot per RFID card in proximity). The "first" reader device is the usb-ccid of the cardman. However, there are other users than iso7816-4-like processor cards (such as simple passive rfid tags)... and they don't want to use PC/SC as an api (and there is no standard on how to access such cards over PC/SC either). > > 2) The RFID software stack opens this virtual slot to talk to the RFID > > Reader ASIC using the OpenCT API (CT_Card_Transact). > > > > 3) The RFID software stack implements the various protocols and protocol > > layers > > > > 4) The RFID software stack registers a number of slots as ifd-handler > > with OpenCT. The slots provide access to protocols like T=CL. > > hmm, so the user would see one reader it can't use (escape protocol). > you could as well link in all you need from src/ifd/ and thus > not need that extra indirection - whatever is easier for you. access to the PC_TO_RDR_ESCAPE function. The abstraction was mainly intended to 1) allow librfid to reside on different lower levels ('transports'). At the moment only OpenCT ifd-ccid is implemented, but support for other ccid drivers (or even a simplistic built-in transport that ignores the contact based part) are possible. 2) allow librfid applications to use different API's. This is what I'm doing at the moment, since the ifdhanler/openct/pcsc Interface on top of librfid is missing. This is good for development, and likely to continue to be useful. There are a number of RFID applications other than processor smartcards, so PC/SC is not really suitable for those. > would you create new readers on demand as the reader finds new cards > within range, or would you create a number of virtual readers and > fill those slots with cards? I'm not sure on that part yet. The Omnikey proprietary code (as well as all other readers I know at the moment) basically only supports one card/slot/reader at a given time. I think due to the complexity involved in multi-card operation, I'm initially also only supporting one card (slot). Later on, probably one reader with a fixed number of slots. I think it's stupid to dynamically add/remove readers. All that is created are 'slots'. I don't think we can add/remove them dynamically at this time, but well, that's distant future anyway. > are you planing for a complex single threaded rfid stack, a multi > threaded or one with several processes? openct code currently is > written with the assumption of once process pre reader and thus > quite simple, but thus might lack feature you want. I hate multithreaded userspace programs, so my rfid code is very unlikely to get multithreaded. > > I'm concurrently also working on libmrtd > > (https://svn.gnumonks.org/trunk/libmtrd/), a library to access ICAO MRTD > > compliant electronic Passports. It uses the PC/SC API - not because I > > like it buy this way libmrtd will run on many different readers/stacks, > > including the omnikey proprietary one (which might be good for > > debugging). > > so that omnikey driver is a simple ifdhandler driver and you need to > implement the rfid protocols on top of pcsc? learned something new again. > (looks to me like they changed the concept/stacking, but it wasn't a good idea > to have every driver reimplement basic protocols anyway). my deliberate design decision to have a clean level of abstraction. Obviously ou can hack the ifd-ccid.c driver to include the full RFID stack. Omnikey provides a pcsc ifdhandler that is basically both a CCID driver and a full RFID stack for numerous protocols. They don't have any layering. > that patch looks fine with me. shall I apply? That would be fine, since it'd remove the requirement to use a patched openct version. Maybe we should first be sure that this layered design is the way to go. Even though I invented it, I'm not sure that it really is "the right thing"... -- - Harald Welte <[hidden email]> http://gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) _______________________________________________ opensc-devel mailing list [hidden email] http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel |
Free forum by Nabble | Edit this page |