Hi Bud,
I decided to take my time to answer this one. Sorry for the delay then.
Your proposal sounds interesting but it is beyond the intent of my
original request. IMHO, openct lacks a complete regression test batch
for ensuring that the driver layer performs as it should (I also find
annoying that it doesn't call the close() function). That is, that all
the communication primitives between the driver, the card reader and the
card work flawlessly WITHOUT taking into consideration the actual card
capabilities (gosh I really hate that smart cards do not implement a
UNIX-like echo server by default).
Sort of the difference between Transmission (the reader driver) and
Communication (the card driver).
Adding a client-server testing mecanism for cards would definitely be a
useful tool when developing card drivers but I think it would be less so
when debugging card reader drivers, again IMHO.
On top of that I would make the difference between mass-marketed smart
cards like Cryptoflexes, STARCOSes and alike and national ID cards which
are issued "per individual request" basis. In the case of the former,
the client-server approach you propose would be replaced by manufacturer
kindness and a UPS or DHL parcel at a much lower cost in terms of time
and development effort. In the case of the latter, using your proposal
would be against the law in some european countries, though it has deep
consequences I don't intend to judge here and of course it doesn't take
away the hack value of the proposal.
Hoping someone finds all the above constructive.
Cheers,
JC!
The difficulty to get test cards seems to be a real and recurring
problem. Being one of the test-card-richest persons at least for eIDs,
I thought already in the past to find a way to sharing this over the
web somehow.
So far I have mostly thought of server testing, using some call-back
mechanism to book ssl with client-cert-auth calls with the various
cards. Martin has even sent me some code for that--but I have never
gotten around to doing this.
I believe a similar thing could be done for accessing the card--with
some kind of a tcp-connected proxy card reader. The PIV sw emulator
used some standard protocol over a socket (TLP xxx ?) and probably did
something similar.
In case that this is a good idea and doesn't require much effort, if
there was some "test card publication utility" for people who have test
cards, and either an index (on the wiki) or better a central dispatcher
for participating remote sites, then I'd install that on my end and
promote its use at least in the eID domain...
let me know what you think
-b
On Sat, 13 May 2006 22:08:51 +0300
Juan Carlos Borrás <[EMAIL PROTECTED]> wrote:
> Dear all,
> Even though I am able to retrieve ATRs using the wbeiuu I wonder if
> someone could provide me with a complete assortment of test cases in
> order to check driver robustness, stability and (let's face it)
> correctness of my code.
>
> I've got plenty of smart cards for testing, but I'm gonna play it safe
> and discard for such purposes the credit card, the university card, the
> sat-tv provider card and a few others, just in case I meant "if
> (buf==dat)" but I wrote "if (buf=dat)".
>
> That leaves me with a spoiled SIM card and a CryptoFlex 64k.
>
> Now I would like someone, please, to provide me with a set of test cases
> of the form:
>
> 1) To retrieve the contact list of the SIM card
> opensc-tool|openct-tool this, this, and that.
> 2) To retrieve this funny parameter of the Gemplus card.
> opensc-tool|openct-tool this, this, and that.
> 3) To make the Cryptoflex to generate DTMF tones ;-):
> with such and such application send this and that APDU.
>
> >From all the information provided I'll make a "Testing your Driver"
> section on the wiki pages.
>
> Cheers,
> JC!
>
> _______________________________________________
> opensc-devel mailing list
> opensc-devel@lists.opensc-project.org
> http://www.opensc-project.org/mailman/listinfo/opensc-devel
--
Ing. Bud P. Bruegger, Ph.D. +39-0564-488577 (voice), -21139 (fax)
Servizio Elaborazione Dati e-mail: [EMAIL PROTECTED]
Comune di Grosseto jabber: [EMAIL PROTECTED]
Via Ginori, 43 http://www.comune.grosseto.it/
58100 Grosseto (Tuscany, Italy)
http://www.comune.grosseto.it/interopEID/
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
