Carles,
So, if I understand you correctly, I need to do the following:
1) Choose a smart card vendor
2) Get their manual on what APDUs I need to send the card for key and signature
generation
3) Write OCF CardServices implementing the OCF interfaces for those on-card
functions
4) Write a CardServiceFactory implementation for that card
5) Write my application that uses those card services for that particular brand
of card
What I think Karl and I want is the following:
1) Choose a smart card vendor
2) Forget their manual, I want some example Java code that shows *one way* of
using the on-card features from OCF
3) Write my application around the vendor's choice
4) Be happy with my ignorance of APDUs
I understand in JavaCard that I communicate with my applet via APDUs. I am
interested in JavaCard, but not for my current project (providing secure ID
cards for our server product), where I only need to use the Signature and
KeyGeneration services.
Does this make sense? As I said before, I'm new to smart card programming
(although I've read a couple of books, this is my first time programming with
them).
-Chris
Carles Barrobes wrote:
> Hi Karl, Chris and Tom,
>
> > i have the same problem. it seems that there is really no other vendor
> > supplying usable CardServices for its smart cards than IBM. i have heard
> > that GemPlus is working on CardServices for its GPK8000 card, but i
> > haven't
> > seen any yet.
> > the support for CardServices of the vendors is really bad. without
> > CardServices OCF isn't worth the half it could be. and i'm not interested
> > to
> > write all CardServices for my own since there are almost always the
> > standard
> > card services defined in OCF. and these are up to the vendor to make. even
> > if you write them using JavaCard you can not use them on every JavaCard
> > since every JavaCard has a different capabilities.
> >
> Actually, if you are considering a card-based signature solution you have 2
> options:
>
> a] Get a proprietary vendor OS-based solution (in this case a specific
> signature card f.e. G&D's Starcos SPK 2.3) and try to obtain a signature
> CardService for that card. (This will not be a JavaCard). Many manufacturers
> provide this type of cards - some of them are working on this type of OCF
> solution.
>
> b] If you want it to be a Javacard-based solution you have 2 choices:
> 1) You want to develop your own applet
> 2) You want to obtain a manufacturer's applet (plus card service)
>
> In the case 1), no manufacturer will be able to provide you with a
> CardService, as the APDU interface to the signer applet will be defined by
> you. As an advantage, you will have to write the CardService only once no
> matter how many Javacards you wish to support, as long as the APDU interface
> to your applet remains the same. The Javacard applet implementation may
> differ, alas, due to immature standarisation (although this should get much
> better with all manufacturers properly supporting Javacard 2.1). Therefore
> some porting of the Javacard applet may be needed, but the CardService
> *doesn't change*!!!
>
> In the case 2), I really don't thing this is happening yet, but things may
> change when card vendors (or third parties) decide to develop and sell their
> "pure Java" (Javacard-applet/OCF-service) solutions.
>
> > >
> > > I guess this really isn't a question for OCF (as it provides a framework
> > for
> > > writing card and terminal independent applications), but more for vendor
> > > support of OCF.
> >
> > yes it sould be. but it seems to me that most vendors think: we support
> > JavaCard now - so write your CardServices for your own dear developer.
> > i really consider to write a SignatureService using JavaCard and for
> > example
> > iButton. but i saw that not all functionality is accessible from JavaCard
> > applets. e.g. a random number generator, prim testing, key generation, ...
> > but these functions seem to be accessible from outside sending APDUs to
> > the
> > iButton.
> >
> No manufacturer will write CardServices for your own applet, unless under
> some customer order.
> In the future, manufacturers might want to provide you with both applet +
> cardservice.
>
> Don't forget CardService comes together with APDU interface to your
> application. If the latter is fixed in different ports of your applet, the
> CardService need never change. CardService is tied to application provider,
> which is not necessarily the same as card provider, especially in the
> Javacard world.
>
> Cheers,
> C A R L E S
> ---
> Carles Barrob�s i Meix
> Marketing & Development
> GyD Ib�rica - Giesecke & Devrient
> Ind�stria 5
> E-08970 St. Joan Desp�
> Tel +34 - 93 480 8303 Fax +34 - 93 477 1142
> mailto:[EMAIL PROTECTED] http://www.gyd.com/
>
> ---
> > Visit the OpenCard web site at http://www.opencard.org/ for more
> > information on OpenCard---binaries, source code, documents.
> > This list is being archived at http://www.opencard.org/archive/opencard/
>
> ! To unsubscribe from the [EMAIL PROTECTED] mailing list send an email
> ! to
> ! [EMAIL PROTECTED]
> ! containing the word
> ! unsubscribe
> ! in the body.
---
> Visit the OpenCard web site at http://www.opencard.org/ for more
> information on OpenCard---binaries, source code, documents.
> This list is being archived at http://www.opencard.org/archive/opencard/
! To unsubscribe from the [EMAIL PROTECTED] mailing list send an email
! to
! [EMAIL PROTECTED]
! containing the word
! unsubscribe
! in the body.
