David, I have the following: -An application that uses gpkcs11 with a software token -A Reflex 72 reader -A Cryptoflex 16 K card -Reflex 72 driver downloaded from MUSCLE -PC/SC Lite architecture software downloaded from MUSCLE
I want my application to use the Cryptoflex card instead of a software token. Could I fairly easily get this to work by downloading 1. the specific MuscleCard dynamic plug-in (Cryptoflex bundle - slbCryptoflex.bundle), 2. the MuscleCard Client Side API loader, and 3. the gpkcs11 library that supports MuscleCard? >From the MUSCLE messages I've read it looks like 1 and 2 are available now or will be available this week. Is this correct? Would I even need 2 if I'm using a Cryptoflex (non-java) card? Any ideas on when soon would be for MuscleCard support of the gpkcs11 application? I'm currently working with gpkcs11 and making changes to have it make PC/SC calls to talk to the card instead of the software token. I've made some progress but from what I've read about Musclecard it may be a good idea for me to stop what I'm doing and go down the Musclecard path instead. Thanks, Shelby David Corcoran wrote: > > Hello, > > Sometime next week I will release the first dynamic loading Musclecard > framework. The goal of this is to have card abstraction for keys, pins, > and object storage with no interaction or knowledge of the specific > hardware from the application. > > This framework is similar to ssp-lite except instead of using > configuration files, it uses bundles stored in: > > /usr/local/pcsc/services > > thus requiring no configuration from the user. > > For example you might have: slbCryptoflex.bundle or mscMuscleCard.bundle > which will be the first 2 bundles released. The framework, which is > identical to the MuscleCard client side API looks for a matching card in > the bundles and binds the functions automatically - I demo this using > XCard II tool with 2 readers, one contains a JavaCard with the MuscleCard > applet and the other has a Cryptoflex - to the application they both look > the same. > > The initial Cryptoflex bundle (alpha) will be released with key generation > and object, and pin management enabled. A personalization tool will be > included to lay out the file structure so Cryptoflex can behave like a > Musclecard. This allows support for non-Java smartcards that are > supported by the Musclecard applet. > > Soon supported applications include: ssh/openssl, gpkcs-11, XCardII, and > others. > > It is possible for other cards to be supported through this interface such > as memory cards and other cryptographic cards such as the GPK cards as > long as they follow the same API and behavior scoped out by the MuscleCard > client side API document. > > The framework stack looks like this: > > Application > > MuscleCard Client Side API loader > > Specific MuscleCard dynamic plug-in > > PC/SC > > IFD Handler > > Reader Hardware > > Card > > Any questions ??? > > Dave > > *************************************************************** > Unix Smart Card Developers - M.U.S.C.L.E. > (Movement for the Use of Smart Cards in a Linux Environment) > http://www.linuxnet.com/ > To unsubscribe send an email to [EMAIL PROTECTED] with > unsubscribe sclinux > *************************************************************** -- Shelby A. Evans Senior Software Engineer Information Security Department BBN Technologies 9861 Broken Land Parkway, Suite 156 Columbia, MD 21046 Phone: 410-312-6993 Fax: 410-312-6931 e-mail: [EMAIL PROTECTED] *************************************************************** Unix Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/ To unsubscribe send an email to [EMAIL PROTECTED] with unsubscribe sclinux ***************************************************************
