[PATCH/RFC] Integration of RFID stack into OpenCT / CardMan 5121

[Harald Welte]

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

[Harald Welte]

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

[Andreas Jellinghaus-2]

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

[Harald Welte]

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.

Yes, I was thinking about that, too.  All I need at the lower layer is
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).

You don't _have_ to implement the protocols on top of PC/SC.  That was
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