Test cases required

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

Test cases required

Juan Carlos Borrás
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
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Test cases required

Andreas Jellinghaus-2
Am Samstag, 13. Mai 2006 21:08 schrieb Juan Carlos Borrás:
> 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.

with opensc you can run the whole test suite:
compile opensc yourself and cd to src/test/regression/
which has a dozend scripts. first try to get any of them
to work (e.g. "./crypto0001"), once all of them work,
you can run them all at once ("./run-all"). note however
you need blank cards to do that, and the scripts are
dangerous (e.g. removing cards during such a run
I killed at least one card :).

I usualy test with a cryptoflex 32k first, and if it works,
with other cards I have (cryptoflex 16k, gemplus gpk 16k,
etc.)


also if you have a card that works with opensc (e.g. pkcs#15
format or some emulation we support like fineid), then you can
simply run pkcs11-tool --test (maybe add --login and maybe --slot).
that tool only runs a number of tests, e.g. reading certs, signing
some random bytes and so on. you shouln't be able to kill you card
with that (except of couse locking your pin).

> That leaves me with a spoiled SIM card and a CryptoFlex 64k.

wow, I didn't know there were 64k cryptoflex cards out there.
it is not listed in the online store.

maybe you have a cyberflex card? i.e. javacard?
sorry, that card is not supported. (only the older version were,
as they had a filesystem. with the new one you would need to
install an applet first to get anything done, and then opensc
would need to support that applet (and we plan to support
the musclecard applet, but right now we don't)).

> 1) To retrieve the contact list of the SIM card
> opensc-tool|openct-tool this, this, and that.

sorry, I have no clue about sim cards. but you can
try the "libchipcard", I think it has tools for that included
and uses opensc to get our reader layer and thus
openct, pcsc-lite and ct-api readers.

>From all the information provided I'll make a "Testing your Driver"
> section on the wiki pages.

very good idea!

Regards, Andreas
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Test cases required

Juan Carlos Borrás
In reply to this post by Juan Carlos Borrás

Actually, it is a cryptoflex 32k.
My bad.
Tons of thanks for the rest of the info.
Cheers,
JC!

> Am Samstag, 13. Mai 2006 21:08 schrieb Juan Carlos Borrás:
> > 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.
>
> with opensc you can run the whole test suite:
> compile opensc yourself and cd to src/test/regression/
> which has a dozend scripts. first try to get any of them
> to work (e.g. "./crypto0001"), once all of them work,
> you can run them all at once ("./run-all"). note however
> you need blank cards to do that, and the scripts are
> dangerous (e.g. removing cards during such a run
> I killed at least one card :).
>
> I usualy test with a cryptoflex 32k first, and if it works,
> with other cards I have (cryptoflex 16k, gemplus gpk 16k,
> etc.)
>
>
> also if you have a card that works with opensc (e.g. pkcs#15
> format or some emulation we support like fineid), then you can
> simply run pkcs11-tool --test (maybe add --login and maybe --slot).
> that tool only runs a number of tests, e.g. reading certs, signing
> some random bytes and so on. you shouln't be able to kill you card
> with that (except of couse locking your pin).
>
> > That leaves me with a spoiled SIM card and a CryptoFlex 64k.
>
> wow, I didn't know there were 64k cryptoflex cards out there.
> it is not listed in the online store.
>
> maybe you have a cyberflex card? i.e. javacard?
> sorry, that card is not supported. (only the older version were,
> as they had a filesystem. with the new one you would need to
> install an applet first to get anything done, and then opensc
> would need to support that applet (and we plan to support
> the musclecard applet, but right now we don't)).
>
> > 1) To retrieve the contact list of the SIM card
> > opensc-tool|openct-tool this, this, and that.
>
> sorry, I have no clue about sim cards. but you can
> try the "libchipcard", I think it has tools for that included
> and uses opensc to get our reader layer and thus
> openct, pcsc-lite and ct-api readers.
>
> >From all the information provided I'll make a "Testing your Driver"
> > section on the wiki pages.
>
> very good idea!
>
> Regards, Andreas

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: virtual test card utility?

Bud P. Bruegger
In reply to this post by Juan Carlos Borrás
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 <[hidden email]> 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
> [hidden email]
> 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:  [hidden email]
Comune di Grosseto               jabber:  [hidden email]
Via Ginori, 43                   http://www.comune.grosseto.it/
58100 Grosseto (Tuscany, Italy)
http://www.comune.grosseto.it/interopEID/
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: virtual test card utility?

Juan Carlos Borrás
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 <[hidden email]> 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
> > [hidden email]
> > 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:  [hidden email]
> Comune di Grosseto               jabber:  [hidden email]
> Via Ginori, 43                   http://www.comune.grosseto.it/
> 58100 Grosseto (Tuscany, Italy)
> http://www.comune.grosseto.it/interopEID/

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: virtual test card utility?

Bud P. Bruegger
Hi Juan Carlos,

On Fri, 2 Jun 2006 11:19:57 +0300 (EEST)
Juan Carlos Borrás <[hidden email]> wrote:

[snip]

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

Agreed, I thought exclusively of card drivers and assuming that in
order to set up a regression suite, this "remote" approach would
overcome the problem that some test cards (eIDs) are difficult to get...

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

I would not think there was a legal issue if one uses test cards.  A
personal eID would probably be more difficult.  The problem here is
that not all countries sell test eIDs in online stores like Belgium
does.  

PS. is there any way to get a Spanish test card?  Any proposal who to
ask?

> Hoping someone finds all the above constructive.
> Cheers,
> JC!

many thanks for answering

best cheers
-b

>
> > 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 <[hidden email]> 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
> > > [hidden email]
> > > 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:  [hidden email]
> > Comune di Grosseto               jabber:  [hidden email]
> > Via Ginori, 43                   http://www.comune.grosseto.it/
> > 58100 Grosseto (Tuscany, Italy)
> > http://www.comune.grosseto.it/interopEID/


--
Ing. Bud P. Bruegger, Ph.D.      +39-0564-488577 (voice),  -21139 (fax)
Servizio Elaborazione Dati       e-mail:  [hidden email]
Comune di Grosseto               jabber:  [hidden email]
Via Ginori, 43                   http://www.comune.grosseto.it/
58100 Grosseto (Tuscany, Italy)
http://www.comune.grosseto.it/interopEID/
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: virtual test card utility?

Juan Carlos Borrás
On Mon, 2006-06-05 at 11:35 +0200, Bud P. Bruegger wrote:

[snip]

>
> PS. is there any way to get a Spanish test card?  Any proposal who to
> ask?
>

I think there are some fellows on this mailing list working for some
company called C3PO (no kidding) that develops smart card solutions and
sell among other things a crypto card that implements the Spanish
National Digital Certification Authority smart card norm (a la GnuPG
card sold by g10code implements the GnuPG card norm) or something like
that. If willing and listening they will tell you more about them. I'm
in the blue for that.

I also read somewhere on the OpenSC wiki about a "OpenCeres" initiative
that sounded to me like a card driver for the Spanish eID card. Google
doesn't return a meaninful thing though.

As for national eID cards, I heard once a senior representative for the
music copyright management industry speaking about a mandatory ID card
for browsing the net (again, no kidding) as I also read on the official
website of the Spanish eID initiative that it would be excellent for
accessing copyright protected content... therefore I just think that
they are a bad idea and I don't even plan to get one.

Of course the latter paragraph is a topic for another mailing list.

Cheers,
JC!

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: virtual test card utility?

Andreas Jellinghaus-2
Am Montag, 5. Juni 2006 16:48 schrieb Juan Carlos Borrás:
> I also read somewhere on the OpenSC wiki about a "OpenCeres" initiative
> that sounded to me like a card driver for the Spanish eID card. Google
> doesn't return a meaninful thing though.

see
http://www.opensc-project.org/opensc/wiki/SpanishEid
http://opensc-ceres.software-libre.org/

as far as I rememver: ceres has patched opensc for support of their format,
and hispalinux has the source and binaries. but their extension is not under
LGPL license thus we can't include it in opensc.

no idea if anyone maintains that code and keeps it up to date with opensc.
if anyone has a contact in that direction, it would be real helpful to get the
source under LGPL so we can include it and prevent it from sitting somewhere
and rotting.

cc: to juan antonia martinez who knows the situation best I think.

Regards, Andreas
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: virtual test card utility?

Juan Carlos Borrás
In reply to this post by Bud P. Bruegger
Out of curiosity I've been trying to browse that web site for months
with no luck. Today for the first time I don't get a DNS error. It says
in spanish language that the package is released under LGPL but I'm
unable to download the sources.

Not that I have one of those cards (nor a card reader yet ;-)) with me
but since you mentioned the licence issues I thought I could take a
look.

Cheers,
JC!


> Am Montag, 5. Juni 2006 16:48 schrieb Juan Carlos Borrás:
> > I also read somewhere on the OpenSC wiki about a "OpenCeres" initiative
> > that sounded to me like a card driver for the Spanish eID card. Google
> > doesn't return a meaninful thing though.
>
> see
> http://www.opensc-project.org/opensc/wiki/SpanishEid
> http://opensc-ceres.software-libre.org/
>
> as far as I rememver: ceres has patched opensc for support of their format,
> and hispalinux has the source and binaries. but their extension is not under
> LGPL license thus we can't include it in opensc.
>
> no idea if anyone maintains that code and keeps it up to date with opensc.
> if anyone has a contact in that direction, it would be real helpful to
get the
> source under LGPL so we can include it and prevent it from sitting somewhere
> and rotting.
>
> cc: to juan antonia martinez who knows the situation best I think.
>
> Regards, Andreas

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: virtual test card utility?

Jonsy (teleline)
El lun, 05-06-2006 a las 22:51 +0300, Juan Carlos Borrás escribió:
> Out of curiosity I've been trying to browse that web site for months
> with no luck. Today for the first time I don't get a DNS error. It says
> in spanish language that the package is released under LGPL but I'm
> unable to download the sources.

Get it from
http://www.dit.upm.es/~jantonio/opensc-ceres

0.8.1-8 has no read permission; don't try to download
0.8.1-6 requires pcsc-lite-1.2.0
0.8.1-7 requires pcsc-lite-1.2.9 or greater

ceres-libs contains propietary drivers provided in binary form
I apologize the fact that you can get problems on dll'ng on
newer Linux versions. I cannot provide source code for these
libraries ( yes, it's stupid, but I have no chance )

AFAIK Ceres support have been moved to C3PO S.L. (www.c3po.es)
a spanish smartcard reader manufacturer. Contact them to get
newer versions

Juan Antonio


_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: virtual test card utility?

Bud P. Bruegger
On Tue, 06 Jun 2006 09:07:25 +0200
Jonsito <[hidden email]> wrote:

> ceres-libs contains propietary drivers provided in binary form
> I apologize the fact that you can get problems on dll'ng on
> newer Linux versions. I cannot provide source code for these
> libraries ( yes, it's stupid, but I have no chance )

I've always wondered whether this violates the LGPL license of OpenSC
or not.  In the case of Italy, I've interpreted the license such that
it is not possible to add closed card support.  And BTW I have just
these days gotten the (so far verbal) ok of our Ministry to add support
for our cards.  Some followup is probably necessary before doing
it--but the big job seems done..

cheers
-b

--
Ing. Bud P. Bruegger, Ph.D.      +39-0564-488577 (voice),  -21139 (fax)
Servizio Elaborazione Dati       e-mail:  [hidden email]
Comune di Grosseto               jabber:  [hidden email]
Via Ginori, 43                   http://www.comune.grosseto.it/
58100 Grosseto (Tuscany, Italy)
http://www.comune.grosseto.it/interopEID/
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: virtual test card utility?

Albert Solana
In reply to this post by Juan Carlos Borrás
El dl 05 de 06 del 2006 a les 17:48 +0300, en/na Juan Carlos Borrás va
escriure:

>  
> > PS. is there any way to get a Spanish test card?  Any proposal who to
> > ask?
> >
>
> I think there are some fellows on this mailing list working for some
> company called C3PO (no kidding) that develops smart card solutions and
> sell among other things a crypto card that implements the Spanish
> National Digital Certification Authority smart card norm (a la GnuPG
> card sold by g10code implements the GnuPG card norm) or something like
> that. If willing and listening they will tell you more about them. I'm
> in the blue for that.

We, C3PO, are a Spanish smart card reader manufacturer, which also sell
smart cards. One of the smart cards we distribute is the FNMT
Cryptographic smart card [1], called Criptonita. In order to use it,
there is the Opensc-Ceres project[2].

However, we are not selling nor distributing in any way the Spanish
National Digital Identification Card.

Best regards,

[1] http://www.c3po.es/criptonita.html?new_lang=en
[2] http://opensc-ceres.software-libre.org/
--
Albert Solana Berengué
[hidden email]
C3PO, S.L.
http://www.c3po.es
C/Bertran, 113 - 08023 Barcelona
Tel. 93 417 99 55 - Fax. 93 253 12 80

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: virtual test card utility?

Albert Solana
In reply to this post by Jonsy (teleline)
El dt 06 de 06 del 2006 a les 09:07 +0200, en/na Jonsito va escriure:
[...]
>
> AFAIK Ceres support have been moved to C3PO S.L. (www.c3po.es)
> a spanish smartcard reader manufacturer. Contact them to get
> newer versions
>

Our Ceres support is based only on helping to install and configure our
smart card readers on any operating system. However, we also give
assistence when the user uses a Ceres smart Card and gets some trouble
on that.

But, anyway, we does not give the official Ceres support.

Best regards,
--
Albert Solana Berengué
[hidden email]
C3PO, S.L.
http://www.c3po.es
C/Bertran, 113 - 08023 Barcelona
Tel. 93 417 99 55 - Fax. 93 253 12 80

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: virtual test card utility?

Andreas Jellinghaus-2
Am Dienstag, 6. Juni 2006 12:00 schrieb Albert Solana:
> But, anyway, we does not give the official Ceres support.

are the apdu commands of the card and the structures of
the eid card documented or could we get that information?
and maybe a test card?

if so we should be able to create an open source driver for opensc.
linux users would be happy because it simply works, and given
enough information we can handle the support from our users,
and would only rarely need to ask you for some developer level
information if something is changed or a new problem is found.

Regards, Andreas
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: virtual test card utility?

Andreas Jellinghaus-2
In reply to this post by Bud P. Bruegger
Am Dienstag, 6. Juni 2006 09:43 schrieb Bud P. Bruegger:
> I've always wondered whether this violates the LGPL license of OpenSC
> or not.  In the case of Italy, I've interpreted the license such that
> it is not possible to add closed card support.

I think it is possible in some situations. basically the new work must have
enough basis to be copyrightable and independend from opensc.

taking a skeleton driver and modifying some apdu and constants and a generic
foo/bar replacement would be neither copyrightable nor independend.

also we have (or had?) that generic load external driver interface so opensc
was initially designed to allow binary only drivers. these days I think the
belpic way is better - copy opensc, rename opensc to foobar and add your
driver. open source everything except card-newdriver.c, but include the
*.o file (and specify which linux/compiler/... you used).

of course we prefer open source / code under LGPL.  :)
 
> And BTW I have just these days gotten the (so far verbal) ok of our
> Ministry to add support for our cards.  Some followup is probably
> necessary before doing it--but the big job seems done..

wow, congratulations! these are good news!

Regards, Andreas
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: virtual test card utility?

Albert Solana
In reply to this post by Andreas Jellinghaus-2
El dt 06 de 06 del 2006 a les 17:05 +0200, en/na Andreas Jellinghaus va
escriure:
> Am Dienstag, 6. Juni 2006 12:00 schrieb Albert Solana:
> > But, anyway, we does not give the official Ceres support.
>
> are the apdu commands of the card and the structures of
> the eid card documented or could we get that information?
> and maybe a test card?

In order to get that information, you should contact to the National
Manufacturer of Ceres, called "Fabrica Nacional de Moneda y
Timbre" (FNMT).

A general e-mail account where you could send that is [hidden email]

Regards,
--
Albert Solana Berengué
[hidden email]
C3PO, S.L.
http://www.c3po.es
C/Bertran, 113 - 08023 Barcelona
Tel. 93 417 99 55 - Fax. 93 253 12 80

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: virtual test card utility?

Nils Larsch
In reply to this post by Andreas Jellinghaus-2
Andreas Jellinghaus wrote:
> Am Dienstag, 6. Juni 2006 09:43 schrieb Bud P. Bruegger:
>> I've always wondered whether this violates the LGPL license of OpenSC
>> or not.  

I don't think this is a problem (a card driver is or could be implemented
as a separate library)

...
> also we have (or had?) that generic load external driver interface so opensc

it should still work (although I must admit I didn't test it for quite some
time)

> was initially designed to allow binary only drivers. these days I think the
> belpic way is better - copy opensc, rename opensc to foobar and add your
> driver. open source everything except card-newdriver.c, but include the
> *.o file (and specify which linux/compiler/... you used).

sorry but why is this approach better than supplying a binary driver ?
I think this is even worse as this will create unnecessary forks ...

Cheers,
Nils
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: virtual test card utility?

Bud P. Bruegger
On Sat, 17 Jun 2006 00:07:56 +0200
Nils Larsch <[hidden email]> wrote:

> > was initially designed to allow binary only drivers. these days I think the
> > belpic way is better - copy opensc, rename opensc to foobar and add your
> > driver. open source everything except card-newdriver.c, but include the
> > *.o file (and specify which linux/compiler/... you used).
>
> sorry but why is this approach better than supplying a binary driver ?
> I think this is even worse as this will create unnecessary forks ...

With or sithout fork, I believe that binary modules are very difficult
to maintain.  Look for example at the eID landscape where OpenSC is
the ideal vehicle to support multiple eIDs in a single middleware for
multiple platforms.  

Even if you complile only for a single platform, keeping up a binary
module with the evolution of OpenSC is not guaranteed and (due to the
difficulty to get test cards) is likely to remain untested.  

But even if you manage to get this working, things will surely break
when you want to complile for different platforms, maybe some nice
embedded device running linux on an embedded processor...

So in my book, open source drivers are the only reasonable solution--at
least for eIDs that should be used universally wherever one needs
strong authentication..  

This is also why I think that a regression test for all supported cards
would be a nice thing to have..

best cheers
-b

--
Ing. Bud P. Bruegger, Ph.D.      +39-0564-488577 (voice),  -21139 (fax)
Servizio Elaborazione Dati       e-mail:  [hidden email]
Comune di Grosseto               jabber:  [hidden email]
Via Ginori, 43                   http://www.comune.grosseto.it/
58100 Grosseto (Tuscany, Italy)
http://www.comune.grosseto.it/interopEID/
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel